Re: Groovy Or JRuby

A strong reason to prefer Ruby is the fact that it lives in multiple implementations.

Fowler is alluding to the fact that Groovy runs on the JVM only, whereas “Ruby can run directly on mainstream operating systems with a C runtime, and is starting to run on .NET’s CLR”. I don’t see this as a strong advantage for Ruby at all, for two main reasons:

If you need portability across mainstream operating systems, you already have it with the JVM (to a similar enough extent as with Ruby).

If you need tight integration with a platform, I don’t think either the JVM or CRuby implementation has a clear advantage.

When you start a project, you need to decide what tradeoff to make between portability and depth of platform integration. If you favour portability, you can just take the JVM then choose whichever language you please. If you favour depth of integration, your platform will often dictate the language. If you want both, implement the portable part on the JVM and go native for the rest.

10 Responses to “Re: Groovy Or JRuby”

An aspect of having multiple implementations that Martin didn’t seem to get into is that having multiple implementations forces a language or platform to “grow up”. Ruby has gone through its share of growing pains, especially in the areas of performance and internationalization (multibyte character support). Performance is significantly better in many cases in JRuby over the 1.8 implementation of Ruby in C, meaning lots of folks are considering JRuby as a deployment option. Ruby 1.9, however, has stripped out a number of features that limit performance and ended up passing JRuby for a number of cases. And while JRuby provides access to Java’s excellent Unicode support, Ruby 1.9 will provide encoding-agnostic changes to String handling to support internationalization across a wide range of characters. And the cycle continues.

Part of what has made Java such a successful and powerful platform is the fact that there are so many different implementations. Competition drives all parties to do better, and as a result the JVM in its many forms is an amazing piece of software.

It’s unlikely that there will ever be a competing implementation of Groovy, since it has so many very specific features tied to Java and the Java platform, and having several implementations for the JVM would be unlikely to produce much diversity. It may mean that Groovy remains the only language of its type and will flourish in that niche, or it could mean, if things go unchecked, that Groovy devolves into a mishmash of poorly-integrated features, since there’s no alternative implementation to show “a better way.” I have every confidence the core Groovy team can keep this from happening but it’s a bit like they’re chiseling away at a statue nobody’s ever seen before or setting out on a voyage to who-knows-where. Steering those waters without a map is going to be a lot harder without other implementations’ examples to follow or avoid.

Thanks for stopping by. Indeed competitive pressure can be a good thing. Certainly I think this is a more concrete point than Fowler’s. Funnily enough it seems competition is waning these days in the JVM space.

However competition does not just have to be against an implementation of the same language. At the moment the dynamic languages are pushing each other along, after all. Re: Groovy not having an existing implementation to compare to: this is the normal case for any new language after all!

Personally I don’t have anything invested in Groovy or Ruby – I just thought Fowler’s point was odd. To me the portability of the JVM trumps the ability to run on different Ruby implementations.

Fowler’s point may be valid in one sense: Folks averse to anything “Java” related may be more likely to consider JRuby because there is a non-Java version and because it has a very non-Java syntax. And they can start on either C Ruby or JRuby and move to the other, so there’s some comfort level for both ends. With Groovy you’re pretty much bound to using the JVM in all cases, and there’s no option for running the same code on a native implementation or on .NET for example. With 2 or more native Ruby implementations, 2 JVM Ruby implementations (XRuby is the other), and 2 .NET Ruby implementations (Ruby.NET, IronRuby) there’s a lot more choice. For some reason, that makes risk-averse managers a little less worried.

Groovy runs fine on .Net through IKVM, and then integrates with the .Net libraries. But it’s not strictly speaking another implementation for another platform. Anyway, I don’t see as a limitation, nor do I think it would prevent from doing a good job implementing Groovy.

[…]Martin Fowler makes an interesting claim in GroovyOrJRuby: A strong reason to prefer Ruby is the fact that it lives in multiple implementations. Fowler is alluding to the fact that Groovy runs on the JVM only, whereas â€œRuby can run directly on …

Guillaume: I knew you’d mention IKVM, but to my knowledge nobody’s running anything real on IKVM and I can’t imagine the performance would be as good as either normal JVM execution of Java code or normal CLR execution of CLI. But I absolutely believe having multiple implementations would be beneficial; wouldn’t performance be more of a focus if there were an alternative implementation called “Gravy” that ran ten times as fast? Competition is a good thing, and Groovy would benefit from having a direct competitor implementation.

I think you’re missing the point of Fowler’s argument. Yes you can run a JVM almost any kind of machine. But that’s not quite the same thing as saying you can run a JVM on almost any platform, depending on your definition of platform. It will be great to be able to write .NET apps in Ruby. Not sure how IKVM will pan out. At my company we have a mixture of shell scripts, Java/JVM apps and .NET apps. Right now I can write shell scripts and Java apps in Ruby. I can’t write .NET apps in Ruby; we have to use C# or VB. Being able to use Ruby on all three ‘platforms’ will be beneficial.

Another thing Fowler didn’t point out is that writing Groovy apps on the .NET platform wouldn’t make much sense for VB or C# programmers. Groovy has a lot of things inherited from Java that ease the transition for Java developers, but they’d look like warts to C# developers. Groovy makes sense for Java developers writing for the Java platform, but not elsewhere. That’s why I think Groovy will remain a niche or transitional language.

Another Steve

Leave a Reply

Name (required)

Mail (will not be published) (required)

Website

Where Am I?

A little madness is the blog of Daniel Ostermeier and Jason Sankey. We are the founders of zutubi, a company based in Sydney, Australia that makes software for software developers.

Our flagship product is Pulse, an easy to use yet powerful and adaptable continuous integration server. We'd love you to try it free today!