After reading The power of JRuby and the discussion that ensued I was inspired to write about why I chose Ruby and particularly JRuby as my company's primary development platform.
I didn't write this post as a knock on Groovy. If it wasn't for Groovy I doubt I'd be working in Ruby today. For me Groovy was my "gate-way drug" into the dynamic language realm. My reason for this post is to explain why someone might want to use Ruby on the JVM over Groovy.
After working with Groovy for quite a while I started dabbling in Ruby. At first I really didn't get it. Then I watched a presentation by Dave Thomas and the lights went on. A world of possibilities opened up for me, and they were easily in reach.
So, why JRuby?
Meta-programming in Ruby is extremely natural. The separation between programming and meta-programming in Ruby is minimal to non-existant. It's just a natural progression.
I particularly like the way the meta-programming facilities of Ruby combined with executable class definitions and open classes make a declarative style of programming simple to implement. We are using these capabilities to simplify our code, eliminating boilerplate and repetition everywhere we can. It's very easy in Ruby.
When I started into meta-programming in Groovy (ver. 1.5 or so) it was cumbersome. A mixture of meta-class implementations. Then there is the fact that what meta-class backs a class isn't consistent. Sometimes MetaClassImpl, sometimes ExpandoMetaClass. (cf: GROOVY-2925)
The straw that broke the camel's back for me was the calling of static methods from class static blocks. Being able to do this would get one as close as you could to executable class definitions. Problem is it doesn't work. (cf. a related issues: GROOVY-2955) This arose when I was working on a DSL to do declarative validation of Struts 2 actions.
This for me is the single largest difference between Groovy and Ruby and what won me over to the Ruby side.
Groovy by design uses the Java object model. A Groovy class is a Java class. Groovy classes are compiled. The definition of the class itself is static. This has great advantages if your primary desire is to inter-operate with Java code, but it makes other things harder.
Being able to use executable code in a class definition, as Ruby does, allows me to abstract away boiler plate code and patterns. Ultimately it can lead to full blown DSL like extensions to classes that save many key strokes and aid in comprehension. (Rails' ActiveRecord is a great example of this paradigm put to work. Quick tutorial on this methodology.)
I've also used executable class definitions to implement Java interfaces when the implementations have followed a convention and were repetitive. One array, an each loop, and voila implemented interface.
Groovy goes a long way toward bringing dynamic methods to Java and the JVM, but it lacks executable class definitions in the manner that Ruby has.
This is a great trick if you need it. I had an interface for a DAO. The finder's were named by convention. Very easy to convert into EJBQL, SQL, or what have you. In Groovy when your class implements a Java interface it must have all the methods present. In Ruby just include the Java interface and put the implementation in method_missing.
This is a shared feature of both Ruby and Groovy. Personally I find the Ruby implementation more natural though. Groovy uses meta-classes to achieve its open classes, whereas classes in Ruby are just open. Add a method to String and it's on String, not String's meta-class.
I find Ruby to be very consistent (leaving closures, lambda's and blocks aside, that one I'll give to Groovy). For me the API is tight and comprehensible. Once I worked with it for a while it just seemed natural.
Groovy has some consistency of its own. It's closures are far more consistent than Ruby's. But the library is Java. It's a great library, but overkill for what I do, and a lot to comprehend and keep in one's head.
Groovy has some inconsistencies though, and to my taste more than Ruby has. Most of these seem to stem from creating a dynamic language that transparently inter-operates with Java. An amazing accomplishment, but one that comes at a cost.
This is a totally subjective thing, but I prefer Ruby's syntax and style. I find it very easy on the eyes. I find I can identify the begin and end of blocks more easily. Not really a reason to change from Groovy to Ruby, but I like it.
This was the clincher for me. Porting Groovy code to Ruby is quite simple. Many of the coding idioms are the same or similar. Outside of meta-programming, which for me tends to be isolated, it goes very quickly. So, the change from Groovy to Ruby hasn't been hard.
JRuby also shares many other features with Groovy that make both of them compelling solutions for scripting Java:
When explaining Groovy to non-Groovy Java folks in the past I used to say, "Groovy is Java." Meaning that the syntax is very close, it uses the Java object model, and can transparently inter-operate with Java. Eventually that closeness to Java became Groovy's downfall for me.
By cleaving so closely to the Java model Groovy gains advantages in interoperation with Java, but suffers in its implementation of dynamic features. Those issues were large enough for us to make the jump.
In the end we chose JRuby as our main platform. Its consistency, and ground up design as a dynamic language unburdened by the Java platform make it a joy to work in. Scripting Java with it is great. Its meta-programming, executable class definitions and open classes are a winning combination.
So, if you're thinking about using a scripting language on the JVM give JRuby a try. You might just find it a compelling alternative to the other offerings.
Rev 1: Added "Scripting Java" heading.