I'd say Ceylon is the interesting project here - it keeps the JVM but drops the standard library.

(I'm a big fan of Scala - its sheer power is second to none - but it definitely has its ugly parts and many of them can't be fixed as long as it's to remain compatible with the Java standard library)

I've always been reticent to learn these offshoot dialects of languages unless I really needed to. I'd much prefer it if they were treated as syntax experiments, and good ideas from them filtered back into the main language.

It's a mistake to think of one "main" language. There's a limit to what can be fed back into the Java language. Other languages like Clojure and Scala have more than enough going for them and stand on their own merits. I'm seeing increasing numbers of teams relegate Java code to legacy status in favor of newer JVM languages.

The problem is the rate things get filtered back to Java. I started using Groovy when I kept waiting and waiting for new language features. In 2003.

Groovy wasn't production-ready in any way, shape, or form until 2005 when the parser was rewritten in Antlr 2, and even then it took years to clean up bugs particularly those related to the MOP which was added in 2006. The Java 5 features weren't even begun to be added to Groovy until early 2006, and they're still buggy. The only significant addition to Groovy since then has been a @CompileStatic tag in Groovy 2.0 in June 2012, which its main user Grails 2.2 didn't dare bundle until 6 months later, but didn't actually use the static compilation. Grails 2.4, still in development, is the first to actually use any of the static features of Groovy, but with a strong caution in the doco: "Care must be taken when deciding to statically compile [Grails] code." http://grails.org/doc/2.4.0.M1/guide/introduction.html#whats...

> groovy is backwards compatible with java as well, in most cases java code is valid groovy code.

Whenever I read that meme I get damn suspicious about why java code isn't valid groovy code in all cases. Why only most cases? It all sounds like a recipe for spending half a day debugging simple scenarios where things don't run as intended.

To be taken seriously (or as seriously as a language called Groovy can be taken), embrace and extend Java fully, don't embrace only 99% of it before extending. That's what Microsoft tried with J++ and lost a lot of trust with developers that took them a decade to win back.

Its mostly things where the java code contains groovy identifiers, but here is a pretty good list: http://stackoverflow.com/questions/687601/valid-java-code-th...

Groovy isn't attempting to fix Java, it's entirely different. (And it sacrifices type safety--even what of it you get with Java--and performance to do so.)

> And it sacrifices type safety

Groovy is optionally typed, you can have as much safety as you wish.

> and performance to do so

If you use static types, you can use @CompileStatic to get most of the performance back.

Groovy's main user Grails 2.2 didn't dare bundle Groovy 2's @CompileStatic until 6 months after its release in June 2012, but didn't actually use the static compilation. Grails 2.4, still in development, is the first to actually use any of the static features of Groovy, but has this strong caution in the doco: "Care must be taken when deciding to statically compile code." http://grails.org/doc/2.4.0.M1/guide/introduction.html#whats...

Optional typing adds a ton of sand to the gears when you actually are writing code. @CompileStatic requires you to spend entirely too long thinking about what's actually legal to annotate and generally sucks rocks to read and write.

So, okay, you're technically correct, which is every nerd's favorite kind of correct, but writing it that way sucks. Groovy isn't a bad scripting language (or wouldn't be if discobot ever got done), but it's unserious as a Java competitor where Java is good.