Over the past couple of years, the cringe-worthy Groovy has been making bridges between the world of Java and dynamic languages. Groovy's premise is that a program doesn't need to be compiled in order to run on a JVM, and instead provides a just-in-time interpreter that can evaluate scripts in a different dialect.
For whatever reason, the JVM's ability to run any byte-code produced content hasn't been given much attention over the years. Sure, languages like NetREXX have had translators that can spit out bytecode since the early days of Java, but they've been very much hangers-on to the existing Java infrastructure.
Of course, Sun haven't helped here. The strong link that's been forged between the JVM and its associated Java libraries borders on the excessive; the smallest download for a JVM these days runs to tens of megabytes. What you really need if you want to promote multiple languages is to separate out the VM from the 'core' libraries, get rid of the special treatment of the java- prefixed classes (so that you can add the core libraries in afterwards) and move forward, much like Microsoft are doing with the CLR/DLR and Silverlight.
Groovy turned the tables somewhat. Instead of needing the full suite of Java libraries, you can run Groovy on a cut-down JVM. The interpreter/compiler effectively translates Groovy code into byte-code (either on the fly or ahead of time) and allows you to write programs in a different environment. This allowed for greater experimentation and ideas — such as the ability to pass executable code as a data type — as well as introducing items which should have been present in Java since 2000 like 'map' and 'filter'. Other scripting languages have tried to benefit from the JVM, like BeanShell, but haven't had as wide a consumer base as Groovy has.
There are also languages like JRuby and JPython, which are implemented on top of the JVM, but their success is more to do with the existing language. In any case, some Python purists complain that the JPython isn't true to Python since the latter (currently) deals with ASCII whereas JPython uses Unicode – perhaps this debate will end with Python 3000 as it introduces the new Unicode type for all string data. There are also some missing features; JRuby doesn't support the full Ruby semantics due to missing support from the JVM.
Groovy is still small-fry in the languages business; despite a few vocal bloggers and authors, it's not used nearly as much as Python or Ruby in the enterprise (and arguably the latter only because of Rails). What it has shown is that if an idea works from another language, nick it — this gives existing developers an easier migration path to using a Groovy-based system than if they had to learn items from scratch. Witness Grails and GSP as two borrowed features from other languages, not to mention the functional-style programming of passing functions as data and the standard functional operators. (Actually, languages do evolve by borrowing memes from others; Java nicked the name and the spacing of JSPs from ASPs; and arguably, Java's byte-code was nicked from Smalltalk a decade earlier. Languages evolve, in much the same way that life does, by borrowing features that work. That is, unless you live in Kentucky, in which case He invented Groovy and Lo, It Was Good.)
As a result, Groovy is somewhat like the Borg from Star Trek. It's a collective of ideas, shoved together, to provide something that achieves its goals and has the intent of taking over the universe. Even if you think the idea is good in principle, you don't want to get caught up with it.
The new kid on the block is Scala. Actually, it's not that new; it's been going since 2002, so it surpasses Groovy in terms of history. But it's relatively unknown; and partially, that's because Groovy was conceived by open-source proponents who hacked the first few releases together (running with a longer beta than all but the most Google-esque apps, including a complete re-write to retrofit an evolved grammar), whereas Scala has been developed by some of the finest academic minds. The distinction is clearly visible in the design of the language and attention to typing rules and inference, as well as the quality and type of documentation. This is one area where Groovy holds a light up to Scala; Groovy's website is much more focussed on getting tasks done with the language and documenting the libraries, whereas Scala's website is much more organised as a collection of academic papers (including some entirely in PDF) with somewhat more detail than the average programmer will want to look at.
In fact, compared with other dynamic languages, Scala's general availability and organisation of documentation is quite poor. That's not to say there isn't any, but pretty much any other language's site has a brief discussion of syntax, examples of inheritance and overloading, and a beginner's guide or set of tutorials. Scala doesn't really have any of these things; at least, not in a coherent form. Some PDFs contain this information (alas, not especially useful for Google searches) and other links to remote sites have opinion pieces that mention Scala (including this one). But there's some pretty basic information missing if you want to get to grips with the language; for example, the _ operator is a wildcard, which is used in both pattern matching (e.g.
case _ => ...) and imports (e.g.
import scala._). Nor does any documentation on the actors library (using keywords like
react) mention that in order to use these, you need to
import scala.actors.Actor._; because they're just functions defined in the Actor class. And Scala hasn't yet hit a critical mass where there's plentiful books available on the subject.
With all that said, I still think that Scala is the next Groovy. The language itself has a number of powerful features – the actors framework is only comparable to Erlang, and the XML processing is probably second only to F# or LINQ – but for a Java-based language, integrating it with existing Java systems is what it does best. Other advantages over non-functional languages include a strong typing system (but with type inference so that you don't have to define everything), as well as top and bottom values. Combined with natural currying (combining functions together and creating partial functions and partially applied functions, the future looks good. The other competitor in this space is Haskell, which is a more pure functional language. You should definitely keep an eye on both of these languages in the future.