On Thu, Mar 21, 2019 at 11:03 AM MG <mg...@arscreat.com> wrote: > > 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
I believe in this 2016 article Cedric had explained in good detail why this is not a mere matter of Jetbrains putting more weight behind anything: http://melix.github.io/blog/2016/05/gradle-kotlin.html On Thu, Mar 21, 2019 at 6:35 AM Sergio del Amo Caballero <sergio.del...@softamo.com> wrote: > - Gradle Groovy DSL helps Groovy adoption and thus survival. > same as Geb DSL on top of Selenium helps Groovy adoption and thus survival. While that is obviously true, the question is not as simple. The groovy community must make a recommendation to all gradle projects in the world about whether to use Gradle-Groovy-DSL or Gradle-Kotlin-DSL. And for developers to take the groovy community seriously, this recommendation should be based on a *technical* argument. Merely begging: "Please use Groovy for your builds to help Groovy survive" is not an argument to be taken very seriously. So far I have only seen the argument that a developer basis already using Groovy for the production/test sources will benefit from their Groovy knowledge when maintaining the build files. This can counter-balance the strength of Gradle-Kotlin-DSL in the area of IDE support (It's a personal choice). But if that is the only argument we have for Gradle-Kotlin-DSL over Gradle-Groovy-DSL, then this implies that any project in the world not using Groovy for test/production is better off using Gradle-Kotlin-DSL. Cedric however took a much stronger position, saying that as an expert in Groovy and Gradle (and supposedly newcomer to Kotlin), he recommends Gradle-Kotlin-DSL for the Groovy project. This would imply that all other gradle projects in the world (including those where the developers are familiar with Groovy and unfamiliar with Kotlin) should switch to Gradle-Kotlin-DSL at the earliest convenience. And so far in this discussion, I have not seen anyone saying that they tried both, Gradle-Kotlin-DSL and Gradle-Groovy-DSL, and still preferred Gradle-Groovy-DSL after their investigation. And that's a very weak stance, supporting a recommendation only out of political reasons and ignorance of a different technology. So are there any other arguments to recommend to Gradle projects to use Gradle-Groovy-DSL over Gradle-Kotlin-DSL? What's the main sales pitch here?
