It did not seem to really address the issue of polyglot very much (given it is in the HN title) rather than just promoting the virtues of Java. One of the strengths of the JVM is the ecosystem of JVM languages that has evolved. You can stick with the JVM and get many of the benefits mentioned while still being polyglot. In particular you can throw in a dynamic language (Groovy, JRuby, Jython) alongside the Java core and get the benefits of a dynamic language for parts of the code where that is suitable, without losing many of the other benefits. Groovy, in particular, is 100% bidirectionally compatible with Java and has close enough syntax that a developer team well versed in Java will pick it up quickly. Perhaps Kotlin qualifies in this regard as well. To me the optimal setup is a strong Java core defining the APIs and core services, while the less core code can benefit from using more expressive dynamic languages. For example, the drudgery of writing unit tests is hugely alleviated by doing in something like Groovy rather than straight Java.
> Groovy, in particular, is 100% bidirectionally compatible with Java and has close enough syntax that a developer team well versed in Java will pick it up quickly.
Groovy's only close to the Java 1.7 syntax. Java 1.8 uses the -> symbol in a completely incompatible way to Groovy.
And the most common use case for Groovy, i.e. Gradle, only uses some DSL syntax which is totally unlike anything you've seen in Java. There's no overlap at all.
Groovy feels like it's dying as far as I can see - partly because you can write almost word-for-word the same code in Scala and not have to sacrifice type safety.
I think the problem is more that development has really slowed since they lost the sponsorship of the company that was funding development (which employed almost the entire dev team). It's not clear to me what the future of Groovy is. However it's about 1000x more accessible to Java developers than Scala is. Scala reinvents the whole type system and uses custom collections etc. That makes reverse interoperability (I write a class in Scala and then use it from Java) significantly more challenging than Groovy where Groovy code looks identical to native Java in most respects.
You can use Scala like that if you want to though - you can stick to the Java collections (even implement the scalaz typeclasses for them), or one effective technique is to write a Java interface and then have a Scala class implement it. Most Scala users do find it worth moving beyond Groovy-like code, but you don't have to.
> Groovy code looks identical to native Java in most respects
Maybe your definition of "most respects" doesn't include the Gradle DSL or Java 8 lambdas.
Nowadays I use Clojure for those quick'n'dirties testing Java code. A well-placed macro eliminates plenty of boiler-plate specific to the test at hand.
