3 ms·
Groovy is kind of dead (as a project) and obsolete (in terms of technology). Just have a look at their mailing lists. Or the issues they are currently struggli
by frowaway001 12y ago
Groovy is kind of dead (as a project) and obsolete (in terms of technology).
Just have a look at their mailing lists. Or the issues they are currently struggling with.
It seems that today's Groovy mainly exists for its owning company (which seems to change every now and then) to sell training.
But considering Google's taste for mediocre languages, Groovy would fit right in next to Dart and Go.
- vorg 12y ago> mediocre languages, Groovy would fit right in next to Dart and Go Groovy's dead for JVM scripting, and Grails is losing adoption share rapidly, but it's rebounding as the DSL in Gradle. I've yet to see a Gradle build script that actually drops out of the DSL to use Groovy to do any programming, though - perhaps Gradle's too good at what it does. Developers like Gradle because it has Maven-depth functionality with a JS/CSS-like syntax. Gradle would have more uptake if it enabled developers to plug in other dynamic JVM languages, e.g. JRuby, Jython, Clojure, Nashorn, JDart. Even Scala's dynamic mode might work. I've looked briefly at Gradle's source and Groovy seems to be entangled deeply in it - Gradle even manipulates Groovy's AST all over its source. I suspect Gradle was set up with the specific intention of promoting Groovy and making it difficult to work with other languages, despite the quote on gradle.org: "We happily support any community effort to create additional build script engines". Gradle needs to expose an API for its use like other products do if anyone is going to believe they're not going to change their source to prevent other build script languages being plugged in, just like Groovy 1.7 and 1.8 source changed to give Groovy++ and others the runaround around 2010 / 2011. But I suspect the same people behind that are ultimately behind Gradle.