(Also posted as a comment on the blog:) Groovy would have won the "Java.next" title by now if they weren't so stubborn about being a dynamic language. If they invested half the effort they've put into "IDE-time" static type inference/type checking in Eclipse/IntelliJ (so that programmers can still get the warm fuzzies of auto completion) into building static type inference/checking into the language itself, I think they'd have seen much wider adoption.<p>This is basically what the guy behind groovy++ has done, but, from what I've heard, they basically told him several years ago that they had no interest in taking the language in a static direction.<p>This sucks because, in IMO, 90%+ of the calls in a Groovy program can be statically dispatched just like regular Java. Sure, duck typing is useful in a few places, but those few places shouldn't mean my entire program has to be dynamic.<p>Groovy has an awesome syntax, awesome compile-time AST transformations, etc.--but a dynamic language, in enterprise environments at least, will not be Java.next. Scala is maturing, and Groovy's window of opportunity is quickly closing (or already gone).