We’re writing a large production system in Java, and I’m considering whether or not we can write some of the components in one of the JVM-based dynamic languages. Groovy appears to be the best choice from the Java interoperability standpoint. But is the Groovy implementation reliable enough to use in production (I would assume so), and is the Groovy language specification itself stable enough so that we aren’t going to have to revise our production code substantially in a year or two? What are your experiences?
Summary (5/30/09): Good comments, the sense I get is that you should be cautious in adopting Groovy for mission-critical production use, it’s fine for ancillary usages like putting together test cases, and there’s a middle ground where it’s probably fine but do your homework first. Performance is an issue, which needs to be balanced against the increase in developer productivity. Bill and Ichorus have equally helpful answers based on Groovy use, so it was a coin toss.
Update (12/3/09): More recently I’ve been taking a serious look at Scala, another JVM language. It was designed and implemented by Martin Odersky, the original author of the current javac compiler and the co-designer of Java Generics. Scala is a strongly typed, but uses type inferencing to strip out a lot of boilerplate. It’s a nice blend of object-oriented and functional programming. James Gosling likes it. James Strachan, the author of Groovy, likes it too. And Odersky’s experience writing javac means Scala’s raw performance is not far from Java‘s, which is impressive.
Update (4/26/11): Take a look at Groovy++, a statically typed extension of Groovy, which has performance equivalent to Java. Looks very interesting.
Edit: Here almost four years later and Groovy has become much more solid.
I can wholeheartedly recommend it for production grade projects.
I’ve been using Groovy to support production applications for a while and for that purpose it is stable enough. As for actually having Groovy in bona fide production code; I don’t think I would do that. Groovy does too many surprising things. It has gotten much better in this regard over the past year or so, but every once in awhile I will run into a bug that is a bit difficult to track down because of the generated code (my issues seem to have revolved around scoping).
I have gotten away from Groovy (though the stuff that we use that is simple and solid is still around) and have used Python (jython implementation), which has been far more predictable in my opinion. Also, python trumps Groovy in readability.
You can write some very interesting code in Groovy with closures and operator overloading and whatnot.
These languages are used for convenience and speed on ancillary code…stuff that can be switched out on the fly if need be. None of it is in production. I don’t think I would put either in production unless it was as a stopgap to get something critical out of the door in a major hurry or as a proof of concept or prototype.
And in the case of putting it in actual production, it would have to be in the most dire of circumstances and I would assign someone to rewrite it in pure Java for the next release. I am 98% sure that either would be fine in production but that 2% is too much unnecessary risk.