4 ms·
> The JVM is a highly-optimized, cross-platform, garbage-collected environment on which people have built much more progressive languages that lack the syntacti
by vorg 8y ago
> The JVM is a highly-optimized, cross-platform, garbage-collected environment on which people have built much more progressive languages that lack the syntactic baggage of Java: Scala, Groovy, Clojure, Kotlin.
Apache Groovy has inherited all of the syntax of Java. When Jeremy Rayner built the Antlr 2 based syntax for Groovy back in 2005, he began with the syntax for Java, then added the Groovy-specific grammar to it. The latest version of Groovy still uses that syntax, so if Java has syntactic baggage, then Groovy has it too.
I'm picking Groovy will still have that baggage-laden syntax for a while yet. 2 yrs ago, Daniel Sun built an Antlr 4 based replacement grammar, but the Groovy project managers at Apache are taking their sweet time in rolling it along. They even had its optional preview removed from the version 2.6 beta of Groovy.
- _bxg1 8y agoI wasn't aware of Groovy's roots, but that doesn't diminish the point. It elected to take on Java's baggage; the JVM didn't impose it.
- spricket 8y agoNo idea that Groovy was designed by the guy of Antlr fame... Pretty humbling TBH. Check out Kotlin though. It's seriously great and doesn't share lost of the performance penalties of Groovy
- zmmmmm 8y ago> doesn't share lost of the performance penalties of Groovy That's a bit of a myth these days. Groovy may even be more performant than Kotlin when used with static compilation.
- olavgg 8y agoGroovy with static compilation is very fast and memory efficient. In most cases it is equal to Java. Though you are supposed to use Java and Groovy together for maximum performance and developer productivity. Groovy is not a replacement for Java, but rather an extension
- ptx 8y agoWhat makes Groovy unsuitable as a replacement for Java, if the performance is now comparable?
- zmmmmm 8y agoFor the masses, imho, all round Groovy just isn't polished enough and is too complex. We are bringing someone up to speed now and there is an enormous amount to teach. There are a range of pitfalls that you have to alert them to. Mind you, a lot of other Java replacements are like that (eg. Scala). Particularly though, the static compilation is just not comprehensive enough. It tries to do type inference but it's limited and invariably you end up having to add type casts in ugly places to convince it that expressions are valid. Occasionally it actually flat out refuses to compile something valid and you have to find a different way to do it. Sometimes it compiles with one version of groovy and then is broken in the next. It works great though to selectively add to hotspots of code and in other places to speed them up and define them better. Having said that, we are essentially using Groovy as a java replacement and for our team I think the above costs are well worth it. This is partly because we have a heterogenous application that is partly dynamic in its nature and Groovy's dynamic scripting ability is amazing for this. The fact we can code our whole back end in the same language makes it super easy and well integrated.
- dmux 8y agoThe new parser is available in the Groovy 3 alphas.
- vorg 8y agoThe Apache project managers removed the new parser from the Groovy 2.6 betas over 6 months ago after officially canceling it and saying Groovy 3 would be the next release. But no real work has been done on Groovy 3 since then. I'm guessing they really intend releasing version 2.6 some time in the future. Perhaps they'll say "Groovy 3 is still far off and Groovy needs another release, so let's resurrect Groovy 2.6". Don't expect to see Groovy 3 move beyond alpha version anytime soon.