Monday, December 15, 2008

Scala ends the Groovy fad


Looks like Groovy is going to loose its steam.

Two reasons: tooling and governance.

Tooling is a critical element as the code base and number of involved engineers increase. Refactoring in a single code base which involves a dynamic language and dozens or hundreds of engineers may lead to hairy situations. When you change a public library API in Java your tool will let you know where is the effected code, update the references for you and will let you know if a contract is getting broken. Tests should locate problems created by refactoring, but:

  • Groovy engineers (and not only them) are sometimes too cool to do a 100% code test coverage.
  • Even a 100% test coverage can not guarantee that there are no bugs, it can only confirm that the test code didn't find bugs.
Typical refactoring problem with Groovy might be changing Java code like:
public int getProductID();
to:
public ProductID getProductID();
class ProductID{
int id;
VendorID vendorID;
}

So if you have a method in your Groovy shopping chart that gets a productId and compares it to a local product id it will not break the code. I.e., no method names where changed and the compare with int and object will simply return false. If the method is rarely used and not tested, or tested only in a way that supposed to return false then you won't find it before your user, and they always find these things.
Prime large scale products can not afford this.

Most of the claims I heard for having dynamic typing is for cleaner and smaller code. Yes, you may have strong typing in Groovy if you wish, but then your back to ugly Java code. With the amazingly comfortable type inference in Scala, you enjoy both words.

The second reason is governance. Both Groovy and Scala are still in the youth where the Cathedral model is the only way for them to react fast and efficiently enough to feedback from the market. Unfortunately Groovy is JSRd. On its face it looks good, hey - what's wrong with Democracy? Well, it appears that its not the best way to run an engineering project and in some case it locks the product in infinite politics games and narrow interests of the few in charge.

9 comments:

Dustin Ted Whitney February 19, 2009 at 9:50 PM  

You can cut and paste java code into a Groovy file and compile it as Groovy. 100% of compiled Groovy code is compatiple with Java, and 100% of compiled Java is compatible with Groovy

It's easy-peasy to pick up and use Groovy, Grails is a fantastic web framework, and now SpringSource owns Groovy/Grails. I think the "Groovy Fad" is here to stay.

Your assumption is that both Scala and Groovy can't exist together. That's just plain wrong.

Eishay Smith February 19, 2009 at 10:14 PM  

Actually, I agree with you. The post is a rather teasing one. I did write some Groove code and was impressed by it at the time. The fact that it’s compatible with java syntax and is getting support it definitely in its favor.
But still, from the groovy code I saw running in production and the stories about other dynamic languages in heavy production scales, I don't think Groovy will be as popular as Scala.
Tough Scala is indeed harder to pick up then Groovy, it is definitely better suitable for high scale. The story of Scala replacing Ruby in Twitter can tell us something but it is just an anecdote. Looking inside the language and libraries (type safety+inference and actors for example) reviles lots of interesting features that have no match in Groovy. In addition Lift seems to be very young but still better then Grails.
Anyway, every tool has its use and its good to have all the tools around. But it seems to me that Groovy as a tool was an over inflated bubble and Scala will inherit much of the space it claimed. How knows, Scala might be the next fad :-)

Ricky Clarkson February 20, 2009 at 3:13 AM  

Groovy is only syntactically Java-compatible, but not semantically. 1/2 is 0 in Java, and 0.5 in Groovy, for example. int s = "hello"; is not a compile error. new Runnable() { public void run() { } }.run() confuses the hell out of Groovy.

I may be being unfair by using whatever version Ubuntu has of Groovy.

100% of compiled Scala code, compiled JRuby code, compiled anything-JVM code, is compatible with Java, and vice-versa, excepting odd bugs or more minor languages.

Your entire argument appears to be that Groovy is Java. Truth is Groovy is a step backwards from Java, as it's (mostly) untyped. Lambdas don't make up for that difference.

Anonymous February 21, 2009 at 2:44 AM  

I wish I could abandon Groovy and work with Scala, but the state of the Eclipse plugin makes me want to use Java only.

Although solutions sometimes could look more elegant in those languages, I just like the robustness and maturity of Java tooling. Spring, Hibernate, GWT and Maven is my future. Scala is hard to pick up, it looks at you and makes you feel dumb, because you cannot understand why sometimes like that even works.

Eishay Smith February 22, 2009 at 12:38 AM  

@Anonymous, tooling is definitely an issue. But since Scala is a statically typed language and for the most part its objects behaves like Jave objects, there is a good tooling potential. Compare commercial IDE support activity Groovy / Scala: http://bit.ly/bPu2M / http://bit.ly/MHsYM
From the list you mentioned I mainly use Spring. Spring is happy with Scala, actually Spring is not aware Scala objects are not POJOs.

Miles Sabin April 22, 2009 at 4:52 AM  

@Anonymous Try the 2.7.4 release candidate of the Scala IDE for Eclipse available here: http://www.scala-lang.org/node/1493. You'll find things much improved since 2.7.3.final.

As is usually the case with open source software if you want things to improve you need to pitch in and help out, at a minimum by filing bug reports ... if you don't tell me about your problems, the chances are I won't fix them.

Brian Burg April 22, 2009 at 5:04 AM  

I'm not going to step into the dynamic/static comment you made, but would like to point out that the tool support for Scala has plenty of *potential*. As it stands right now, neither language has stellar tools (compared to Java)- this is somewhat mitigated by Scala in that many popular Java frameworks can interoperate fairly painlessly with Scala code.

Anonymous August 24, 2009 at 12:03 AM  

Groovy syntax is similar to Java, but definitely not compatible, neither forward or backward. It runs in the JVM, implying that there is a common binary format. The binary format is completely decoupled from the source syntax. However, having a common binary format means Groovy interoperates seamlessly with Java.

Ricky Clarkson September 20, 2009 at 10:46 PM  

Pascal and FORTRAN have the same binary format. If they "interoperate seamlessly", then "interoperate seamlessly" means nothing.

Creative Commons License This work by Eishay Smith is licensed under a Creative Commons Attribution 3.0 Unported License.