Wednesday, February 10, 2010

My Groovy can beat up your Scala

This blog entry is inspired by a blog post I read recently bashing Groovy in favor of Scala. I will opportunistically join in the brawl, contributing my 2 cups of kerosene to the flames by coming out in favor of Groovy.  If you are not interested in the language wars, or if you take this sort of thing way too seriously, feel free to skip this post.

I like Groovy. At my last job, I used Groovy almost exclusively as a "better Java", on top of the typical Spring/Hibernate  stack. I did not use Grails at all, except briefly on a minor project. Even though I had a grand time with Groovy, I never thought of Groovy as the heir to the Java language. A new language will eventually replace Java, I figured, but it would not be Groovy. Whatever the merits or demerits of dynamic typing, I thought, the Java community, platform and class libraries were geared towards static typing. Also, Groovy was too slow. Recent developments have made me question my assumptions.

There has been a lot of buzz around Groovy++. This is a compatible variant of Groovy -- not a fork -- that gives you the option of static typing with type inferencing. There have been posts pointing out that Groovy++ performance can be comparable to Java. The performance differences aren't completely erased right now. Static typing doesn't eliminate Groovy's tendency to default to nonintegral divisions and implicit conversions to BigDecimal, which while arguably friendlier behavior, carry a performance penalty. But still. Now Groovy can offer the performance and compile time checking of static typed languages while also offering its concise, expressive syntax and the ability to go dynamic.

Until now, I has assumed that Scala would be the natural "" language to replace Java. After all, like Java it is a fast, statically typed language that is nevertheless very concise and expressive. Scala and Groovy are the only two languages I know of that can fully integrate into the Java ecosystem. The contract is bidirectional: Java, Scala and Groovy classes are all classes at the bytecode level. You can inherit from each other. This goes for other Java language signatures. Other JVM languages (like JavaScript) tend to be selfish: they will happily consume Java classes but you can't easily get to them from Java without some jumping through hoops. Anyway, with the recent attention to Groovy++, I would say that Scala's main differentiator over Groovy has been erased. No wonder that Scala fan I linked to earlier got all defensive.

 I would say that Groovy now has the advantage. Why? Allow me to present exhibit A:


class Invoice {
   int id;
   List items;
   PeriodType periodType;

   public List getFunnyItems() { 
       List funnyItems = new ArrayList();
       for (Iterator i = items.iterator(); i.hasNext(); ) {
           Item item =;
           if (item.isFunny())
       return items; 

So, um, what is exhibit A?

Is it Java code?

Is it Groovy code?

Answer: yes. Can you tell the difference? It compiles fine on both.

And that's the point. I started my last job not knowing any Groovy. I learned it easily on the job, simply because it felt like such a natural extension to Java, allowing me to gradually be as Groovy as I wanted to be. The syntax is only different from Java when it had to be different. Scala's syntax, by contrast, hurts my eyes. It seems to strive to be gratuitously different from Java. I've watched an hour-plus presentation on Scala that could barely get beyond introducing its syntax because it was so blasted different. The heir to Java cannot limit its adopters to an elite few who like functional programming and hurting their eyes. Its appeal must be mainstream.

Now on to exhibit B:

Those academics are good at inventing cool languages that nobody wants to use. Academia is littered with dead languages. It is the commercially backed languages (like, ahem, Java) that get adoption. From the job trends chart above, I think it's pretty clear that Groovy is the leader in adoption.

So in short, Groovy offers:
  • Static typing with type inferencing for performance and compile time type checking.
  • Dynamic typing when you want it for maximum expressiveness.
  • A familiar syntax for easy adoption by Java programmers. 
  • Good adoption, tool support and corporate backing from SpringSource/VMWare.
Scala only offers 1 out of 4.

Now don't take this too seriously. I think Scala is a fine language, and I'd love to get a gig where I can use it full time. But I would also not rush to crown any language -- let alone Scala -- as the heir apparent to the Java language. It's far too premature. As a reality check, let me offer exhibit C:

Next to Ruby, Scala and Groovy are line noise. And all 3 of those languages become line noise if you graph Java on top of them. The bottom line is that in spite of the first derivative of the new languages' curves, they are still too far behind Java to topple the king. At their current rate, I wouldn't extrapolate their adoption to reach Java's level in a human lifetime. A lot can happen in the meantime, and the ultimate replacement for Java might be a new language you've never heard of before. Ultimately, no one blogger can call a "closure" to the debate like that Scala fan tried to: it's up to the industry to decide through adoption.

For what it's worth, I think "Groovy++" is a terrible name. At least they are not calling it "Groovier". Gack.

Update Feb 13th: a comment below mentioned the TIOBE index, an interesting wrinkle which I address in a new blog entry.


  1. Haah.. I thoroughly enjoyed reading every bit of information in your post as I did on the other post - the one that fired you up to write this one.. Language wars are never ending!

  2. The number of job postings says nothing about the quality.
    As you know not ever the best wins.

  3. lol, you managed to write java in groovy! so qool!!!!!!!! (throws away javac and scrambles to download groovyc)

  4. The most savage controversies are those about matters as to which there is no good evidence either way. - Bertrand Russell

  5. At the end of the day you are probably better off if you have multiple languages under your belt. Learning something new sounds more fun than writing long critiques on why X is better than Y.

  6. Sweet mother, there's a Groovy++? Do they really want people thinking of C++ when they think of this?

  7. There is one thing we can all be grateful for: there won't ever be a Scala++.

  8. You should also include Job statistics for "Java". I also believe that Groovy catches so on fast because programmers are lazy. Java programmers are no exception from that. Since they need to write a lot of code they want to write less.
    Groovy is a lot less verbose but it also does you not give the same power as scala does.
    I think there are areas where Groovy is fine, same for scala.
    For me personally scala is a very fine choice and i leave with pointing towards there:

  9. there is a golden rule for language wars: pick your charts carefully.

    (no wonder you did not include TIOBE: scala is entering 20 while groovy is at 40 )

  10. I agree that adaption and popularity are the true metrics for a language; there's also a matter of picking right charts, like someone noted before.

    But I don't think that being given all the flexibility in the world is a good think. Object oriented programming has been successful also because it allows you to impose limitations (like visibility). So much for dynamic typing for me.

    Java syntax has its limitations and I don't think that you need to bash Scala for having its own. Yes, Scala's syntax is more academic, but I find it pretty consistent and easy to use.

    Well, nice post anyway; to conclude, I guess it pays off to know both Scala and Groovy!

  11. Why does Scala not have break/continue...
    That alone makes Scala too annoying for me...

    1. Because break and continue run contrary to the nature of functional programming. The argument is that use of things such as "break" and "continue" belong to a paradigm of performance things that ought to be determined by the compiler, not the developer. This is one of the key distinctions I notice between functional and imperative programming styles. The fundamental difference here is that imperative programming is concerned with issuing a sequence of commands whereas functional programming is concerned with expressing laws and relationships that resolve to imperative statements at the machine level (opcodes).

  12. public List getFunnyItems() {
    items.findAll(it.funny == true)

    Geez, think like a groovy programmer dude.

  13. Thanks for pointing out the TIOBE index. See the end of the article for the update with a link to my thoughts about the disparity between the two rankings. In short, I show that the TIOBE ranking is highly problematic.

    netmask: it doesn't matter if it's Ruby or JRuby: it's essentially the same language. What I wanted to demonstrate is that it's silly to fight over whether Groovy or Scala will replace Java when they both are niche languages with too little adoption to matter in the foreseeable future.

  14. I expect one can easily create a Scala--. Just invent a type, say 'Dynamic' and a compiler plugin that converts method calls on such variables to dynamic invocations, like what is done in structural types.

  15. On the 4 points you say Groovy offers, you mention static typing. I'd like to throw some food for thought:

  16. metaphysicaldeveloper, you misunderstood my post. Groovy is indeed a dynamically typed language. But Groovy++ is statically typed, and that is what I was referring to when I mentioned the static typing option.