Link Details

I don't see how a dynamically-typed by default language can be a successor to Java.

"Groovy ++ adds to Groovy static typing"

Static typing is an after-thought. The problem is the fundamental belief reflected in the design of Groovy that dynamic typing should be the norm.

Same for a functional and a kitchen sink language.

What do you mean by "functional and a kitchen sink language" -- could you cite examples?

The mentioned Clojure and Scala.

Love the Fox News style headline.

Groovy was easy to learn. Had high overhead so was rather slow. Couldn't be a complete replacement of Java. (Plus I'm in the static type camp and any so-called successor to Java needs to be static typed.)

Scala has a litany of coolness in terms of features and ideas. IOW, sounds great on paper. Daunting to learn to master, though. Have to wrap head around functional programming as that is really the bias of Scala (you'll always feel like a second class citizen in Scala unless you make effort to groc functional programming).

Google Go language has been a blast - haven't seen anything this productive to program in a long, long, long time. And to think am just using "stone knives and bear skins" tool set to program in Go. The goroutines and channels are what I've wanted for ages (but in a non weird language, i.e., not Erlang). Building applications with internal async messaging using constructs intrinsic in the language itself is the bees knees.

And now there's Groovy++. This time we have compile-time static typing. So that's checked off. Type inference so has concise syntax potential ala Go. They'll be adding an actor capability - so internally intrinsic async messaging. Runs on the JVM, so uses a runtime with well over a decade of maturity. Unlike Scala, Groovy doesn't have name mangling impedance with Java, so hence is smoothly inter-operable with Java. Java can even make painless use of Groovy-authored classes.

Groovy/Groovy++ - easy to learn, especially so for existing Java programmers
Scala - really need to learn functional programming - significant obstacle

The actor capability will be the key thing in the end. If Groovy++ does a reasonable job on this, then it may very well move to the front of the pack.

I think you might like Fantom ;-) Statically typed, familiar syntax, Java's mistakes fixed but without the radical nature of Scala/Clojure - http://fantom.org

Dont worry, in few months we will get Scala dotNet compiler

I don't appreciate the author's assessment of Clojure. I think the more important problems at hand are not exactly static typing in Groovy. The following might help:

1. Data should be immutable by default (I like val and var in Scala, I like Clojure's persistent/transient even more)
2. Sharing of mutable state should be made impossible, hence removing the need to lock
3. Immutable classes by default (Open-close principle)
4. Ahead of time (AOT) compilation, yet dynamic at language level (like Clojure)
5. Language-level autonomous actors like Erlang/BEAM on the top ofJVM (not sure if it will affect performance, JITability)

To replace Java we need a simpler language that can do more. Java is a kitchen sink language.

So, currently Groovy++ is ~50 times slower than Scala (or Java for that matter) and is incomprehensible mess internally (just look inside if you care). It's a hack in the effort of saving dying language that was in of itself a hack when it was designed.

Language design is hard. Very hard. It requires education, talent and experience. If you think Scala is complex - just imagine what would a static typing strap-on do to a dynamic language.

PHP folks didn't change the language - they changed runtime to have a fighting chance to continue use millions of lines of crap written in PHP. That was the right decision that unfortunately not available for Groovy - Java runtime is fast enough already, but the Groovy language is not and likely will never be.

Do you have some benchmarks? Mine show Groovy++ on par with/faster than Scala in many/most scenarios.

Not even close. You can't compare a real and advanced language like Scala to a bolted on utility like groovy. I like groovy to complement some java development, but definitely not to build full blown apps in.

The reason why people go for Dynamic languages is because real programming is not everyone's cup of tea

Here you go, thinking like a bunch of dumb nerds again. Am I really going to go to my manager and say "We need to use Groovy++" (lol at that name btw) and he won't even know anything about Groovy and wonder why we just skipped over it straight to ++. Not to mention it's basically a clever hack onto an already existing hack-ish language. It's a non-starter and if you thought about it for more than the 5 minutes you took to write this junk blog post, you'd understand why.

Actually managers from 200+ projects in my customer base have been happily understanding and approving of Groovy for years. They are more interested in the productivity gains and closeness to Java (hence low learning curve) than any nerd features. Less than 10 projects so far are using Scala, Haskell and Clojure combined.

Consider:
1. whether the implementation of the language is controlled by a standards authority v. is open-source and free for innovation (ie explicit v. implicit standards)
2. whether the language itself is open to innovation via DSLs etc
3. whether the language is sufficiently performant for your next project
4. whether the language can be extended by low-level libraries
5. whether the language has a wide range of utility libraries available
6. whether the language has a large supporting community of forums and developers

If any/all of these things are important to you, then Groovy is ahead of the game at the moment and will take some catching up now that we have optional static-typing as well. Its origins or what its source code looks like are irrelevant.