I was watching this talk and I am baffled by the premise, also repeated elsewhere, that the Kotlin DSL is such an improvement over the Groovy DSL. I have tried multiple times to find examples of what it is in the Kotlin DSL that I cannot get with the Groovy DSL, but all my attempts have failed. Now, I may certainly be missing something as I never actually found a reason to use the Kotlin DSL actively.

I am that Gradle Fellow that still maintains that the Groovy DSL has nothing to lose over the Kotlin DSL. And there is a reason why I keep on writing Gradle plugins in Groovy. Here is main reasoning in short. • People who think like Java developers prefer a Kotlin DSL • People who think like platform engineers prefer a Groovy DSL. • Both are related to the way these two groups of people work. • The Groovy DSL is still faster to compile than the Kotlin DSL. • The Groovy DSL still looks slicker to read that a Kotlin DSL. The latter has made quite a bit of improvement since the early days, but it is not yet on par. • It is easier to write Gradle plugins that are compatible over a larger range of Gradle releases with Groovy than with either Java or Kotlin. • Groovy DSL does lack a bit behind in JetBrains with auto-completion, but in most cases it does not matter. There is an organisation relationship between Gradle (the company) and JetBrains. Whether anyone wants to openly admit it or not, it is implicit that there will be bias towards making Kotlin to be better than Groovy for plugins. In reality they are effectively the same and it is the user who can really decide which works better for them.

@ysb33r Thank you for doing that work! Yes, the business bias thingy is what my gut feeling tells me as well. What a waste.

I am Kotlin DSL fan by heart and am not affiliated with either companies, and I am even a Groovy Committer since recently. What you use for writing plugins is imho not relevant for this topic, but I would always use the lowest Java version supported by the lowest Gradle version I want to support when writing a public plugin that should be as compatible as possible, but that is a whole different holy war. In regards to writing build script, I always use Kotlin DSL unless there are very strong reasons not to. The three biggest pro-points from my view are: You immediately get type-safe build scripts which saved my ass many times. You get actually helpful error messages if you mess up the syntax, whereas with Groovy DSL you often get "something in this 500 lines closure has a type, comment in and out random things to find out what". And you get amazingly better IDE support when using a good IDE like IntelliJ IDEA or Android Studio, which you can never get with Groovy DSL as the IDE can simply not know what might be there or what types things have, besides built-in things that are supported explicitly.

And you get amazingly better IDE support when using a good IDE like IntelliJ IDEA or Android Studio, which you can never get with Groovy DSL

Interesting, this is what I have not been able to reproduce. Could you show me some common Gradle build script usages where I cannot get type support with Groovy?

Plenty. Just to have one example out of countless:

testing {
    suites {
        integTest(JvmTestSuite) {
            useSpock('2.5-groovy-6.0')

            dependencies {
                implementation('org.apache.groovy:groovy:6+')
            }
        }
    }
}

No IntelliSense or docs or anything for

useSpock

or

implementation

, and for

dependencies

it only provides because it assumes it is the one on

project

, not on the test suite.

Would this work?

testing {
    suites {
        register('integTest', JvmTestSuite) {
            useSpock('2.5-groovy-6.0')
            dependencies {
                implementation 'org.apache.groovy:groovy:6+'
            }
        }
    }
}

No. Also if it would that's not really the point. The other version is the form from the official documentation, so what people would use and then have bad IDE support. Your version does not behave any better. If you additionally import the class explicitly (which is not necessary for execution), then your version behaves better in the IDE, as well as this version if you add the import:

testing {
    suites {
        integTest(JvmTestSuite) { JvmTestSuite foo ->
            foo.useSpock('2.5-groovy-6.0')

            foo.dependencies {
                implementation('org.apache.groovy:groovy:6+')
            }
        }
    }
}

Without the import this last version even shows a red error in the IDE while it works at runtime. Groovy simply is a highly dynamic duck-typed language for which an IDE can only partly provide IntelliSense, and if something goes wrong you only see the error at execution time and only if the problematic part is actually executed. Kotlin on the other hand is a statically typed language that would fail on compilation already and for which the IDE can provide proper assistance because the types must be known and cannot come in dynamically. Of course you can always write things in a way to help the IDE, like writing a method with strong typed parameters and then in there do the logic and so on, but this is then non-idiomatic in itself already, also is harder to maintain, and you actually should not have to do it just to get better support by the IDE. 🤷‍♂️

No

That's strange, it seems to work for me. What am I missing?

Also if it would that's not really the point.

Well, for me that was the point, because you said: "And you get amazingly better IDE support when using a good IDE like IntelliJ IDEA or Android Studio, which you can never get with Groovy DSL"

As I already said in my last message, if you also add an unnecessary and otherwise useless explicit import of

JvmTestSuite

, then your version behaves IDE-friendlier yes. The point why it is not the point is - as I said - that you can surely write your build scripts in a special way, so that the IDE can understand and support them better. But it only works for that special case when you do so and not for the normal case when you write idiomatic and recommended constructs. And even with that specially written code, the IDE does not really help you much in writing it in the first place. All in all I keep my statement that you will get amazingly better IDE support with Kotlin DSL that you can never get with Groovy DSL. Also for example take this:

testing {
   suites {
      test {
         targets.configureEach {
            testTask.configure {
               jacoco {
                  destinationFile = layout.buildDirectory.file("foo").get().asFile
               }
            }
         }
      }
   }
}

It is very cumbersome to write this in an IDE friendly way and the IDE and docs do not help you too much to do so. And even if you did, it will be ugly non-idiomatic and hard to read for a human.

Thank you for your input. Always good to get different views. For completeness sake, I think this would be the typed Groovy equivalent:

testing {
    suites {
        test {
            targets.configureEach { JvmTestSuiteTarget target ->
                target.testTask.configure { Test task ->
                    task.extensions.configure(JacocoTaskExtension) {
                        it.destinationFile =
                                project.layout.buildDirectory.file('foo').map { it.asFile }
                    }
                }
            }
        }
    }
}

There is for sure an issue in the Groovy DSL when things like

ExtensiblePolymorphicDomainObjectContainer

are involved and having to unnecessarily say

x.create('y', MyClass)

or

x.named('y', MyClass)

etc. is a pain.

I would not want to spend a single minute more than needed on a build tool. If I have to learn a full API to configure my projects I would rather write my own Groovy scripts. A build tool must be cheap. Gradle proved to be anything but cheap. I hope the declarative version works without requiring us to spend money maintaining Gradle scripts. The Kotlin thing is a market/commercial/politic affair. Groovy is still the only language that does what Java does not.

Lol. Whether you learn the Groovy DSL or the Kotlin DSL or use Ant or use Maven or use Bazel or write your build scripts manually in Bash or whatever, you always have to learn the respective language / dsl / syntax / whatever. If you are already capable of one of them and don't want to get the benefits you get from the different tool, by all means, use whatever tool works for you. If you don't do fancy things and follow conventions, then Gradle is cheap with its convention-over-configuration concept. And the time you spend on maintaining build logic is not the only thing to consider. One of Gradle's biggest strengths for example is avoiding unnecessary work and producing reliable results. Both save much time on the long run.

The Kotlin thing is a market/commercial/politic affair.

No, it is not, it is a usability and convenience affair. And if you don't want to use it, then don't and live with the consequences. 🤷‍♂️ I don't think the DCL will be any "cheaper", it will enforce declarative usage which you can already do now. It will enable tooling to be able to better process the build scripts. If you - as noted - to fancy things or do not stick to conventions, I think with DCL it might be "less cheap" to do such things as you are forced to do them in a DCL-compatible way then. But I didn't play much with DCL yet, so. 🤷‍♂️ But again, use whatever tool, language, DSL, whatever, that suits you best.

The reason why Gradle is expensive is not related to the DSL you choose, it's related to the fact that they have changed the API too much. I can understand that, but I still don't like it in a build tool. I feel things should be a lot easier, maybe a JVM specific build tool that supports only JVM languages could help, maybe not 😆

> I feel things should be a lot easier, maybe a JVM specific build tool that supports only JVM languages could help I am going to be sarky and say you already have that and it's called Maven. (Technically not true, but it is really painful at supporting anything else) For all the years I have worked with build pipelines, there has never been a perfect build tool. It is really a case of there only being two kinds of builds tools - the ones that people don't use and the ones they complain about.

You are true, Maven is a lot more stable. It has been affected by the XML virus though. If they release a YML version I would be the first one to suggest we all move there (I hate XML much more than Gradle 😁)

Yeah, it's stable. Or translated, there is not much progress or further significant improvement. 🙂