Java.next(): Groovy vs. Scala

Lately, due to the stagnation of Java and increasing popularity of other languages on the JVM, I’ve been taking a second look at these different languages: especially Scala and Groovy.

Groovy

I’ve long been a believer in Groovy as a natural step forward for Java developers, especially with the Grails framework. With the strong support of SpringSource, Groovy and Grails should continue to be successful, but it seems to be growing very slowly compared to other languages. Besides grails, groovy has a large ecosystem which bodes well for its future.

Adoption

Although not the only measure, adoption is an important measure since the more widely adopted a language is, the more jobs will be available with it, and the better its eco-system will be.

A great way to find out about language adoption is Ohloh. As you can see (if you follow that link), Scala overcame Groovy about two years ago (2010).

Performance

Performance is another important issue with languages. However, this can change very quickly as language developers or the JVM improves over time. Also, for most projects, runtime performance is not the biggest priority. Developer-time is often a higher priority so the ease-of-use and “eco-system” of the language is important.

If performance is a big issue, you’d probably choose Scala, although Groovy 2.0 now has optional static-compilation and so its performance can be close to Java. However, in real-life, performance is greatly effected by what framework and/or libraries you use and how easy (or hard) they make it to be performant.

Web Frameworks

Especially now with the introduction of the play framework 2.0, Scala is looking like a huge contender in the “highly-scalable” web world. Scala proponents claim it makes things like multi-threading and error handling, and thus scaling, easier, while still making small projects a breeze.  I’m still new to Scala, but I find it’s mix of functional and pure-OO-ness very appealing. 

Grails 2 has introduced some compelling features for scalability as well. For example, it supports the Servlet 3.0 async features, has a @Cachable annotation, support nosql back-ends, and has plugins for automatically gzipping and caching resources.

Wouldn’t it be nice if someone did a head-to-head comparison of Grails and Play? It turns out Matt Raible and James Ward did just that earlier this year. The main difference between the two comes from their differing goals. Grails was built to get up-and-running fast with a database-driven web-application and provide a huge ecosystem of plugins to speed-up development. Play’s primary goal is to create highly-scalable web-applications, so it puts more emphasis on the asynchronous framework (akka). Also, Scala is statically typed, whereas groovy is not by default.

Conclusion

As a Java developer I would spend time learning and using both of these languages. While Scala appears to have the performance, type-safety, and scalability edge, groovy is easier to learn, has a big ecosystem, and is in many ways more similar to Java (and with groovy 2.0 now has @StaticCompile and @TypeChecked). It will be interesting to see what happens after Java 8 comes out.

See Scala vs. Groovy vs. Clojure and this question for more language comparisons.

Tags: java groovy scala