https://kotlinlang.org logo
Join Slack
Powered by
is there any official recommendation from gradle t...
# gradle
b
is there any official recommendation from gradle that folks favor the kotlin dsl over the groovy one? Is there any data that indicates which direction the overall community is moving? I’m going to attempt to make the case that we should standardize on kotlin dsl for all new projects and any sort of recommendation / community info would be helpful!
👀 1
v
I don't think there is an official recommendation. At least not that I'm aware of. But I'd always recommend the Kotlin DSL personally.
c
also not aware of an official recommendation. Always recommend the Kotlin DSL myself.
s
Does the Kotlin DSL have 1:1 parity with the Groovy DSL in case of features/functionality? If so, is it true that Kotlin DSL is slower and how much in comparison if true?
v
In some situations it is slower, in some it is faster.
Feature parity should be given, yes
c
yes, not aware of feature parity gaps, the underlying Gradle API is exposed to both DSLs.
v
And if not you could always use Groovy as a work-around for the part not working, but I don't remember having a need for it for a long time
While it of course always depends on actual test cases measured
Like with any performance numbers
b
yeah, afaik there’s no gap. the biggest painpoint i’ve run into is when working with janky 3rd party plugins that expect groovy closures, it’s not very ergonomic, but it works (i’m looking at you artifactory plugin, though thankfully it’s been a long time, so maybe it’s been improved)
v
Yeah, hopefully. But in those cases, you can also always have a small Groovy DSL script plugin that you apply with 
from
if 
closureOf
and alike do not work or are too ugly.
But by now at least the major plugins hopefully should be nicely compatible with both.
b
yeah, in our case we just stopped using the artifactory plugin as it was completely unnecessary (and was a giant PITA and source of confusion for folks even in groovy dsl builds) and just use the native gradle maven-publish.
heh, just realized i asked this in the kotlin slack, not the gradle slack as i meant to, so probably got a bit of a biased response, but i’ll take it 😄
s
thanks a lot guys for precious information, will keep it in mind.
t
afaik Gradle is working on improving KTS compilation time and currently tries different solutions to this problem. Probably you will see some of them in Gradle 8
10 Views
Open in Slack
PreviousNext
Powered by