groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <>
Subject Re: Binary compatibility fixed + Kotlin DSL
Date Thu, 21 Mar 2019 01:53:17 GMT
Hi Cédric,

I think that It should be obvious that there is a conflict of interests 
here, and that agreeing to you suggestion looks to be worse for Groovy 
than the very old saying by the original Groovy author about "never 
having done Groovy if he had known a certain other language existed" 
(all taken back later and no longer relevant - but still quoted in 
discussions many years later).

Maybe I am missing something, but it seems to me that Jetbrains could 
have put their weight behind Groovy, especially its static part, gaining 
all the benefits with regards to tool support / Intellisense they now 
claim for Kotlin (having worked with purely dynamic Groovy for years 
using IntelliJ IDEA, I also have at least some doubts about the whole 
"you cannot supply good Intellisense for Gradle DSL" mantra), also in 

Instead they decided to develop their own independent language, 
evidently very much inspired by Groovy, with imho some doubtful syntax & 
design decisions where it deviates (and of course missing the dynamic 
support and powerful annotations, as well as the big Groovy ecosystem). 
Having Jetbrains behind it and evidently being heavily invested in it, 
is not just another language on the block that joins the happy family of 
Java alternatives. Jetbrains is pushing their language aggressively 
(including but not restricted to on Wikipedia), and they have already 
scored at least twice: One with the deal with Google Android 
development, and second with Gradle adapting Kotlin as an alternative 
base for its DSL.

The same as Jetbrains must want to get rid of supporting a complex 
language like Groovy and replacing it with their own language if 
possible for purely economical reasons (Note that some Groovy 2.5 
features are still not supported in IntelliJ, months after release), 
Gradle Inc. must want to only support a single DSL code base. Evidently 
this is the Kotlin based one, otherwise why introduce it in the first 
place ? The problem is that it seems uptake of the new DSL has been 
slow, as people see no (or not enough) reason to switch from Groovy. So 
of course there are no current plans to scrap Groovy support in Gradle, 
since that would be suicide. You can try to convince me otherwisem but 
it would be very surprising to me, if that would not change, should a 
certain percentage of users shift.

I can't say how hard this would be on a technical level, and while it is 
unlikely, it could potentially still be nice if Groovy and Kotlin would 
join forces, with the static part of Groovy being merged with Kotlin, 
just with nice groovy Java/Groovy syntax, and without the uselessly 
restrictive things in Kotlin (that way people could actually choose what 
language variety to use). Then this whole discussion would dissapear, 
but since, as I said Jetbrains already decided against that option, and 
instead invested several years into developing their own language from 

Just my 50 Cents (from "Get Groovy or Die Trying"),

*Others here of course have much more insight than me into these 
matters, including you (but see under conflict of interests).

On 20/03/2019 22:41, Cédric Champeau wrote:
> Well I think I disagree with most of what you just said. And Gradle 
> Inc will not deprecate the groovy support anytime soon. I'm well 
> placed to know it's not even in discussion. The only thing that I see 
> could lead to such a decision would be that groovy doesn't run on 
> future versions of the JVM. Let's not take decisions on speculations, 
> but facts.
> Le mer. 20 mars 2019 à 22:35, Sergio del Amo Caballero 
> < <>> a écrit :
>     I don’t know what do you imply that I am trying to hide.
>     I think:
>     - Gradle Groovy DSL helps Groovy adoption and thus survival.
>     same as Geb DSL on top of Selenium helps Groovy adoption and thus
>     survival.
>     I think if everyone moves to Kotlin DSL, Gradle Inc will lose
>     interest in maintaining Groovy Gradle DSL and eventually deprecate
>     the Groovy Gradle DSL and remove it and hurt Groovy adoption and
>     thus survival .
>     I think that Apache Groovy build transitions towards Kotlin DSL is
>     a signal towards prompting that move.
>      About maintaining the build itself:
>     - If the only person touching the build is going to be someone
>     with Kotlin and Groovy knowledge, then I would say better to have
>     the DSL in the language they are more productive with it.
>     - If persons, who touch the build, don’t know Kotlin, I think that
>     it is another barrier. I assume that someone with no Kotlin
>     Knowledge but using the Kotlin DSL and assisted by the IDE support
>     is going to do a worst job than someone with a lot of Groovy
>     knowledge using the Groovy Gradle DSL.
>     Sergio del Amo
>     On 20 Mar 2019, at 21:50, Cédric Champeau
>     < <>> wrote:
>>     And do you honestly think that trying to hide that by not using
>>     the Kotlin DSL would change anything?
>>     Le mer. 20 mars 2019 à 21:45, Sergio Del Amo
>>     < <>> a
>>     écrit :
>>>         I do in fact see this as at least a minor threat.  If Groovy
>>>         itself can't even manage to use the Gradle Groovy DSL, what
>>>         hope remains for the survival of the Groovy DSL?
>>         Agree. I see a threat at least to Gradle Groovy DSL survival
>>         and probably to Groovy in general. One may reason: If the
>>         Groovy programming language build, which is manipulated by
>>         the people with more Groovy knowledge in the planet, moved to
>>         Kotlin DSL, why should anyone else keep using the Gradle
>>         Groovy DSL.
>>         Sergio
>>         On 20 Mar 2019, at 16:00, Milles, Eric (TR Tech, Content &
>>         Ops) <
>>         <>> wrote:
>>>         I tried to get some info from Gradle on adding Eclipse DSLD
>>>         for Gradle and they scoffed at me.  They said it was a
>>>         multi-person, multi-year effort so why even try. I was able
>>>         to get some very basic support without that much effort.  It
>>>         could be moved forward and probably ported to IntelliJ as
>>>         well if there was some interest and support.
>>>         With regards to the change to the Groovy build script.  I'm
>>>         not sure newcomers are diving into the build scripts and
>>>         making edits there.  My intuition is that they are running
>>>         "./gradlew build" or whatever the command is.  As long as
>>>         the scripts run successfully, I'd posit a newcomer is quite
>>>         happy.
>>>         I do in fact see this as at least a minor threat.  If Groovy
>>>         itself can't even manage to use the Gradle Groovy DSL, what
>>>         hope remains for the survival of the Groovy DSL?

View raw message