Definitely Scala. I've worked with Groovy/Grails, which is nice in a lot of ways (mainly ways that are borrowed from Ruby/Rails), but I think the language is hindered by being overly Java-compatible. That makes it easy to learn, but limits the language's capabilities. I'd be very happy if some of the syntactic sugar of Groovy were simply made a part of the Java language (e.g. default scope is getter/setter, lists and maps have their own syntax); that would cut down on the ridiculous amount of Java boilerplate. I'm not as big a fan of the dynamic aspects of Groovy, which can make debugging painful. In Grails, if something goes wrong, it's not uncommon to see a 30-line stacktrace that gives you no clue as to where the error actually occurred, because the error-prone code was added dynamically.
As to Scala: It's extremely elegant, and the community has its act together as far as positioning the language to go mainstream. I'm expecting the 2.8.0 release to be a major step forward, thanks in part to a completely rewritten Eclipse plugin. That kind of tool support will be crucial in getting the language to critical mass. One thing that worries me, though, is that Scala projects tend to be built using Maven, which is awfully complex. Perhaps something like JavaGems may prove to be more important to the future JVM ecosystem than any single language.
SBT, the Simple Build Tool, is a pretty good step in the right direction for building Scala projects, and I imagine it would work pretty well for plain Java code too.
It's been mentioned on the mailing list that Lift, for instance, will eventually move from Maven to SBT when it's functionally complete.
The whole Java world is full of that kind of crap that makes it impossible to do anything in a simple way from memory only. (I'm a Django person myself and also like Rails.)
I think Scala has the potential to appeal to the widest range of programmers. There is something for everyone there, but without alienating any one demographic. (You can write a completely OO app, or you can write a completely "functional" app, or you can mix-n-match. And it does better than other languages that claim you can do both.)
Although I will probably stick with Perl and Haskell for myself, I'm looking forward to a world where Scala and F# are the "enterprise" languages.
> I think Scala has the potential to appeal to the widest range of programmers. There is something for everyone there, but without alienating any one demographic.
I'm eager to get stuck into a Scala/Lift application, have a few ideas, the enormous amount of positive press I see intrigues me as one currently firmly (and admittedly pretty happily) entrenched in the Groovy/Grails camp.
I migrated from working pretty exclusively with Groovy/Grails to Scala/Lift over the course of a year or so, and have no regrets at all.
One of the interesting things I found is that it's remarkably easy to port plain Groovy code to Scala with only minor changes. Once you get over the (somewhat steep) learning curve of the Scala type system I've personally found that I'm about as productive as with Groovy, but end up seeing far fewer runtime errors.
It's not that easy to move existing Grails applications to Lift, however, since the frameworks are so fundamentally different. I've found the best bang for the buck is in moving as much Groovy code as possible to libraries outside of Grails, and subsequently rewriting them in Scala as needed.
You're right that Scala is very complicated, insofar as there are a huge number of features and a lot of code is unreadable if you don't know them. It's a stark contrast to the "runnable pseudocode" of Python. But I think there's a tradeoff between language complexity and project complexity.
The wide feature set of Scala wasn't just assembled at random; it's there because there are use cases in which each of those features makes a task really simple. If you've got a team of smart programmers, then overcoming the language barrier will take a lot less effort in the long run than producing and maintaining tons of bloated code in a less complicated language.
Not an artificial language, I do not think so (backward compatibility etc). A language could breed a simpler/cleaner language, that happens, but it is a different language.
Natural languages are a different story. English has arguably become substantially simpler over centuries (hardly cleaner, however).
I would like to think clojure, but am old enough not to get my hopes up about "a lisp" approaching the mainstream. So that means scala (self preservation?)
Haha, that makes me think of 'voting' for clojure as voting for Nader.
Funny, since I wrote my blog in clojure/compojure and found it easy going compared to Rails (which, to be fair, I had attempted to learn before having any real programming experience). That was my first experience with "a lisp", and it went well. Unfortunately, I think self-imposed cynicism about lisp is a big part of what keeps it from going mainstream.
EDIT: however, I respect that experiencing lisp not going mainstream for years would kill pretty much anyone's optimism :)
scala and clojure, it seems clojure is simple and more adapted to concurrent world.
scala is complicated, but it got better IDE support than clojure at this time. Some of clojure's community seems prefer Emacs/Vim more than Netbeans/Eclipse, and they really need a good support from netbeans/eclipse.
ESME is an Apache incubator project that's based on Lift, and I believe was originally started by the Lift founder. Recent licensing drama aside it seems to have a pretty dedicated team of developers and good momentum.
As to Scala: It's extremely elegant, and the community has its act together as far as positioning the language to go mainstream. I'm expecting the 2.8.0 release to be a major step forward, thanks in part to a completely rewritten Eclipse plugin. That kind of tool support will be crucial in getting the language to critical mass. One thing that worries me, though, is that Scala projects tend to be built using Maven, which is awfully complex. Perhaps something like JavaGems may prove to be more important to the future JVM ecosystem than any single language.