Of those three (Kotlin, Scala, Groovy), Kotlin is by far the most pragmatic. Scala is nice, more powerful, but has a high cost when it comes to learning curve, complexity, and the library ecosystem. I'm not sure of the state of Groovy at this point after it got transferred to the apache foundation. Kotlin on the other hand strikes a nice balance in many areas.

Kotlin got a major push on Android, thanks to a stagnant Java 8 support.

With ChromeOS and Fuchsia on the game as well, it remains to be seen who will win Google's internal OS wars.

So far Android seems to be the one taking them all, though.

Outside Android I don't really see a major benefit switching whole teams away from Java, Eclipse/Netbeans and rewriting/wrapping libraries to be idiomatic Kotlin and such.

How do you define pragmatic? Apache Groovy is still under active development. We've actually started using it more for green-field development where I work.

What exactly does "Groovy" offer that another JVM based language doesn't? Am genuinely interested.

Not the parent, but I prefer Groovy over other JVM languages because:

- supports both dynamic and static typing - it works just as well for bash level scripting as it does for full application development. For example, you can use it exactly like an interpreted language (no compilation needed).

- seamless Java integration. I know many JVM languages say that, but Groovy actually makes it one of its core features. It has a lower impedance mismatch than any other JVM language I've tried (and I try them all).

- partly because of the dynamic typing, it is able to support the most concise, powerful options in its syntax of any of the JVM languages. So you get more done with fewer, simpler lines of code

- because of the static typing and low impedance mismatch with Java, it can achieve very high performance. I was not able to get Scala to perform as well, for example, because of type conversions needed to invoke underlying Java library calls (unless you abandon idiomatic Scala).

The seamless integration is amazing. For a lot of existing Java code, it's as simple as renaming the file to .groovy. In addition to your list, some of our most used features are

- The amazing SQL library - HTML builders (there are XML builders too) - Literal collections (lists and maps)

> For a lot of existing Java code, it's as simple as renaming the file to .groovy

This causes the program to run in dynamically-typed mode, much sloooower, so why do it? You'd have to add @Static annotations everywhere to get anything approaching Java-like speeds. One of the Apache Groovy project managers has long since wanted to make Groovy statically compiled by default, but that's never going to happen because they're running an unofficial go-as-slow-as-possible in the official upcoming upgrade to Groovy 3.