This message was deleted.

is there an argument against this? like. why should i use groovy? is it still that kts is "slower"? is there a world where kts is same speed as groovy, or is that just the nature of kotlin vs groovy?

as noted in the article the main drawback is script compilation time (when scripts are changed), at scale, which has seen considerable improvements (with more to come).

But it also depends on the concrete situation, sometimes it is even faster with Kotlin DSL

Some further announcements on this from Jetbrains and Google: • https://android-developers.googleblog.com/2023/04/kotlin-dsl-is-now-default-for-new-gradle-builds.html • https://blog.jetbrains.com/kotlin/2023/04/kotlin-dsl-is-the-default-for-new-gradle-builds/

@Chris Lee I feel this announcement ignore the native ecosystem which for them Kotlin syntax is foreign as opposed to Groovy (which is closer to C/C++). I think it’s a very important aspect to keep in mind if Gradle want to be a polyglot build system.

@daniel Groovy is in no way close to C/C++, nor more so than Kotlin. Groovy is a loosely typed OO language. For build scripts Kotlin offers a far better experience - type safety, IDE auto-completion, better error messages etc. There’s nothing forcing the use of Kotlin for Gradle build scripts - if one wishes to stick to historical norms, great, nothing is deprecated - you just won’t get all the extra goodness.

It is not really "close", I agree. But it is closer than Kotlin, I agree too. Doesn't make it in any way preferable imho though, I agree too. 😄

My point is trying to burry Groovy DSL (if that is the goal) in favour of Kotlin DSL is not a good move for the native ecosystem. Native users typically use Vim or the like so IDE auto-completion is not something they care. Type safety is actually more problematic as with Groovy you just have to be close-enough and everything generally works. Better error message is also doable in Groovy DSL but the focus have being put more onto Kotlin DSL 🤷 For the native ecosystem, Groovy is closer to C/C++ than Kotlin in terms of syntax. The leading scripting language in native is generally Python which has about a page worth of difference with Groovy making it more preferable for native users. Regardless, I just feel the messaging around Kotlin DSL vs Groovy DSL should not be a battle around which is better but a choice on which is easier for the ecosystem. If there are difference between both DSL, they should be addressed instead of pointing to the other DSL as being superior. I agree that some difference is just by-design and cannot be addressed.

As far as I know Groovy DSL is not going to be burried or deprecated or removed. It is just now more advertised by showing it first in the docs, being the default for

init

, and so on. But both DSLs should still be equally supported and probably will stay, at least in the forseeable future.

That is also what I'm understanding but it should be made clear in communication like this so it doesn't give the wrong message to less involved users in the community.

Isn't

Support for Groovy DSL will continue for existing projects or those who prefer to use it.

doing exactly that?

And: while Groovy is ‘closer’ to C/C++ than Kotlin, it’s far closer to Kotlin, so the gap to migrate shouldn’t be onerous.

It probably is not, but by doing so you are still further away even if just tiny. And if those people prefer to use Groovy, just let them, that's why there is a choice. 🙂