Saturday, March 10, 2007

Ruby on Grails? Why the hell not?

I've spent some time this weekend looking over the Grails codebase. After a truly gigantic checkout (Grails bundles production JARs for all the libraries it integrates) and after swimming through a substantial, single-project sea of source files, I think I'm starting to follow it (though a tour by someone familiar with Grails internals would be nice). But there's something else I've learned in the process...

There's really no reason this couldn't use Ruby just as easily as Groovy.

Let's look at some really dumb numbers. Grails, as it turns out, is actually over 2/3 Java code, unlike Rails which is 100% Ruby. Grails contains around 436 Java source files for about 54kloc of code and 273 Groovy source files for about 23kloc of code. So Java outnumbers Groovy by a 2:1 ratio. And yes, Java's probably more verbose than Groovy in most cases. But my point stands, and I'll back it up with more...

Then there's the libraries. The Grails binary release weighs in at a whopping 26MB compressed and 49MB uncompressed (*wow*). But 31MB of that is third-party libraries completely independent of Groovy, things like Hibernate, XFire, Quartz, Apache Commons, and so on. Almost all of which (or perhaps all of which) are pure Java code. So the ratio is even more heavily toward Java.

These numbers and my exploration of the code base lead me to a surprising conclusion: Grails is not a "Groovy on Rails" by any means. It's a large number of popular, well-established Java libraries stitched together mostly by Java code with a thin layer at the front (20kloc is not much) of Groovy code for end-users to see and work with. And I guarantee you it's not the Groovy part that's most interesting here. Hell, you could write that part in Java if you followed enough "convention over configuration", and you certainly could write it in Ruby.

I decided to do this exploration after realizing there's nothing about Ruby or JRuby that couldn't be used to wire a bunch of Java libraries together--indeed, that's one of the biggest selling points of JRuby, the fact that you can write plain old Ruby code but call Java libraries almost seamlessly (with day-by-day improving integration points and performance numbers). So why not take Grails and do a port to Ruby? Groovy code isn't far off from Ruby in many ways, and everything you can do in Groovy you can do in Ruby (plus more), so the port should be pretty straightforward, right?

Then I find out that Grails is mostly Java code. And instead of being annoyed or repulsed by this revelation, I was intrigued. Why not make Grails work with Ruby as well? And really, why not make it work with any scripting language? Why limit that nicely-integrated back end by forcing everyone to use Groovy, regardless of preference? Have we learned nothing from a decade of "100% Pure Java"?

So I propose the following.
  • I believe it would be possible to completely isolate Grails' tastier bits from Groovy. I don't claim it would be easy, but Grails is fairly well interfacified, injectificated, and abstractilicious, so making that dividing line clear and bold is certainly possible (and heck, that's the point of dependency injection and component frameworks anyway, isn't it?). Really, I could start implementing a few of those interfaces right now with Ruby code, but that's not the right approach.
  • Grails' value is not in Groovy, but in the clean integration of established libraries behind the "Convention Over Configuration" mantra. There's nothing specifically Groovy (or Ruby) about that religion, and there's nothing Groovy does in Grails that another JVM language couldn't do just as easily. This is *truth*. And Grails would benefit tremendously by expanding to other languages. Being tied to Groovy alone will hold it back (just as a framework tied to any one language will be held back, Ruby included).
  • I also believe that if the Grails project doesn't make an official effort in this direction, others are likely to take up that mantle themselves. Though the debates will forever rage about which JVM dynlang should carry us into the future, the same facts that have guided programming for half a century still apply today: No one language will be enough to carry us forward; no languages will survive indefinitely; and the language you'll use in ten years you've probably not even heard of yet. Did anyone expect Java to be the most widely-used, widely-deployed language ten years ago? Well today, it is. It won't always be.
  • There's also a very interesting angle here for language enthusiasts. Nobody doubts that the Java platform is officially becoming multi-lingual, possibly a complete reversal from years past. But there are going to be growing pains here, and we're already feeling them on some projects at Sun. We have this wonderful platform with all these wonderful languages...and they all do things differently. We have a first stab at official "Scripting" support in JSR-223, but it only defines the integration point from Java to the language in question...only partially defining the integration points for those languages calling back to Java (a tricky problem) and defining *nothing* related to making those languages interoperate with each other. Again, Java becomes the integration point, and the bottleneck (as in "how do you pass a dynamic-typed object from one language to another by sending it through a statically typed language?"). The very exercise of making Grails (or any other framework) work equally well across multiple user-facing language interfaces will require better interoperability and more clearly-defined integration points for dynamic and static languages on the JVM.
  • The Phobos guys at Sun are already tackling many of these same problems while expanding their JavaScript-mostly Rails-inspired web framework to other JSR-223 languages (notably, Ruby). So anyone taking on the Grails effort would certainly not be alone, and there are some damn smart engineers at Sun interested in tackling these very same problems.
And I guess in the end it's a question of how visionary we all can be. Can the Grails team envision a future for Grails that doesn't require the use of Groovy? Are you (and am I) as a non-Groovy developer willing to help them get there? And in the end, isn't this what thought leaders on a multi-lingual platform are supposed to be doing?


So, enough of the inflammatory bull-baiting. I dare you to tell me why I'm wrong here. Even better, I dare you to look into it yourself. 75kloc of code, only a third of it Groovy. Established libraries you're sure to have used at some point. Clean integration, following the principals inspired and proven by Rails.

But fronted with your language of choice.

Make it so.


  1. This is actually a really cool idea. I don't have much experience with either rails or grails, but I am familiar enough with the two to know that they each have their respective strengths. Offering grails running on JRuby would only open the door to non-groovy enthusiasts (like myself).

  2. Why not? Supporting other dynamic languages would make grails stronger.

    It would also make a significant statement: the developers of groovy and grails do not suffer from the same hegemonic tendencies as other similar dynamic language projects. Imagine how the rails creator would response to this same question. Which raises an interesting question about defending groovy from the hegemony of other scripting languages...

    Would there be any reason to provide multiple language support for the build or other parts of the framework that are written in Groovy?

    Would there be any benefit to using Java less in Grails? The developers seem to have given a lot of thought to when they should use groovy over Java. In fact, it would be interesting to hear more about their criteria, because it is definitely easier to write Groovy code than Java. Is it for performance? Is it because it seems like the right thing to do?
    It's hard to say, I've written builders in Groovy and Java, and I'd like to think the choice is a matter of taste and context.

  3. I just had dinner with Charles a couple of weeks ago at a No Fluff, Just Stuff show in Milwaukee. Unless his thoughts have drastically changed in the interim, I don't think that he is "bull baiting" as he implies.

    As we talked, we both came to the same conclusion: JRuby is for folks who like the Ruby dialect. Groovy is for folks who like the Java dialect. Plain and simple. JRuby is less an effort to integrate Ruby with Java than a project that allows copy/paste source code compatibility with C/Ruby on the JVM with only minor exceptions. Groovy offers the same copy/paste compatibility with Java.

    If you have an existing Ruby on Rails app and you want to run it on the JVM, JRuby is a great choice. If you have experience with well established Java libraries like Spring and Hibernate, but are envious of the scaffolding and convention over configuration of your Rails brethren, Grails fits the bill.

    Grails is nowhere close to a straight port of Rails to another language. Inspired by: yes. Ported from: no. Grails (and Groovy) respect the idioms of the Java language. While a JRuby port of Grails is an interesting thought experiment, I think that it kinda misses the point. That doesn't mean you shouldn't try it, but I wouldn't hold out hope for widespread Java/Groovy community support any more than Ruby folks are dying for a Java version of Rails. Both frameworks are reflective of the strengths of their respective underlying languages.

    And speaking of respect, Charles' posts to the Groovy mailing lists have been exceedingly polite and well thought out. Certainly no one would be naive enough in this day and age to argue that programming languages are a zero sum game -- that one is inherently better than all the rest.

    Charles is doing great work for JRuby. But not all roads lead to Ruby. One man's JRuby is another man's Groovy. Or Jython. Or JavaScript. Or best of all -- any one of them, used in the right circumstances.

  4. Nice post Scott. I think that reflects the situation very well.

  5. It's great to see so many hints that I'll probably want to be using Java in some forms quite a bit in the coming decade. I had recently thought I'd avoid it for the most part in favor of Ruby and Objective C. The improvements to Java itself and the beans are almost as compelling as the proliferation of languages coming to the vm.

    I think Ruby on Grails will be a very strong move that helps to combine the momentum of Ruby with the mass of Java to bring more standardization around our theories about drying up the web. If Python and Helma and others end up fully compatible, so much the better. Unlike some here, I would generally suspect that all this noise would bring a lot more users to Groovy, in web context and others.