The Charles Nutter Ruby on Grails story

Back in December Charles Nutter and I had a discussion at JavaPolis about collaborating and the potential to leverage Grails as a platform for multiple languages.

Now Charles has actually looked at the codebase, and would even like a further extended tour (Charles - give me a shout if you're interested, I'd be happy to). His conclusion? Lets make Ruby on Grails. I don't find it particularily suprising he has come to this conclusion. His estimates of Java-to-Groovy are actually way off. I would say if you take away the unit tests and sample apps, Grails is more like 85% Java. There are a few things that should be pointed out here:

• Not only is it very possible to support other languages, it is feasible now, thanks to the plugin system and Grails' well thought out, as Charles puts it, "interfacified, injectificated, and abstractilicious" design.
  
• The benefits of leveraging all of the existing dominant libraries in the Java eco-system (Spring, Hibernate, SiteMesh, Quartz) is becoming more clear. There is no doubt that the codebase and libraries being in Java provide a significant performance improvement over Rails (100% Ruby) in my view. Grails is a mere Groovy facade onto a well integrated set of libraries, I've been saying this at ever presentation I've given about Grails since day one. This is one assertion Charles is most certainly correct on.
  
• We also see these same benefits for people who need a reasonable migration path. Questions like "how can I use my existing Hibernate domain model?", "Can I continue to use Spring MVC controllers?", and "Can I inject and re-use Java services?" all have a clear and well defined answer in Grails making it much easier (although still challenging) to sell into enterprise organisations.
  

So back to the original question then, the answer is a most resounding "yes!" we could most certainly support multiple languages. But, before we get too excited lets get back to reality. Creating simple web frameworks is simple, creating tightly integrating, elegant, user-friendly frameworks is hard.

With Grails we've embraced the Groovy language idioms like builders, closures and meta-programming in a big way. We've pushed the boundaries of what Groovy is capable of doing. Now say we decided to support JRuby, and maybe JavaScript could we create as elegant a framework by making compromises to support all language idioms? Actually, in this case yes we probably could because Ruby for example as Charles says in his typically "language neutral" way "everything you can do in Groovy you can do in Ruby (plus more)". But how long would that take?

Then there is the Java integration story, which I believe Charles is only getting half of the picture here. Java integration is not just about being able to invoke a method on a Java object. Java integration is about mindshare integration, API integration, syntax integration, object model integration. JRuby has only just managed to solve object model integration, it won't ever be able to solve API, syntax or mindshare integration. What I mean by this is when i create a File, it should be a java.io.File, what about Streams do I forget about those? And the Collections API? Out the window with JRuby. Hang on, when I'm in "Ruby-land" a string isn't a java.lang.String? Telling an organisation that they're going to have to send their entire development team on weeks and weeks of training to understand Ruby and Rails is a hard sell. As Chad Fowler said recently at RailsConf, Ruby is not for "stupid programmers", which effectively means you need well trained people.

And of course then there is Agile and scalable application complexity. Dynamic languages are only useful for small to medium complex applications. This is also "fact". Having supported a multi-tier Perl system for a number of years I would rather die than have to write a complex banking system completely in Groovy or Ruby. But, I would be quite happy to write parts of it in either. If you take this approach you get what I call scalable complexity. The ability to start off in a dynamic language and when things get tricky implement certain parts in Java.

The problem here is that to take this approach you need two languages (one dynamically-typed, one statically-typed) that work seamlessly together. Why? In Agile one of the activities known to reduce productivity is task switching. Read any book on Lean Thinking and Agile and they'll tell you to eliminate waste by eliminating task switching. Switching language idioms is task switching and in this sense the Java-to-Groovy story is just so much stronger. A developer can easily switch between using Java and using Groovy without having to start thinking in a completely different way. This is simply not the case with JRuby.

On the practicality front, Grails 1.0 will be out by Autumn (that's Fall for those on the other side of the pond) or maybe even sooner. By supporting all these languages we'd end up in a situation like Phobos, which is basically going nowhere and does not do a quarter of what Grails or Rails is capable of.

So does all this mean I don't want to support Ruby on Grails? Hell, I would love if we could! Choice is a good thing and with the JVM this is completely possible, its just down to the old conundrum: Resources. So maybe Sun should, instead of wasting their time with dead end projects like Phobos, step up to the plate and commit resources to projects that do matter now. Like Grails.

So why should Sun do this? Well, Grails is beginning to win the battle for the hearts of minds of Java developers looking for the next big web framework. How can I justify this claim?

• We have had a huge surge in popularity, Groovy in Action is the number one best selling book at Amazon "Java Books"
  
• There are 12 sessions featuring Groovy and/or Grails at JavaOne.
  
• Grails is the most popular project at Codehaus.org by a long way.
  
• Over at JBoss they're scrambling around attending GroovyDevCon meetings and looking to get Groovy incorporated in Seam to bring the same level of elegance to Seam as we have now in Grails. Still, I believe JBoss are on to a good thing, keep up the good work guys ;-)
  
• JRuby on Rails is being talked about, and noise is being made, but where is the real world use cases? Who is actually deploying JRuby on Rails now? No one. fact. With Grails we have people using and deploying real worlds Grails applications all over the place. In the Java space, JRuby on Rails is playing catchup to Grails and not the other way round. And now we have JRuby on Grails being suggested. How the tables are turning ;-)
  
• Then we have poor old Phobos, which has managed 38 posts on the user mailing list since June last year. As Charles says, you guys are "damn smart" Sun engineers, so do the smart thing and give up guys, this is going nowhere. On one side of the fence you're saying "use JSF and forget about Javascript!" and now you want people to write it on the Server-side? I love JavaScript, but there are far more elegant languages to include on the server-side. My advice? Join Grails and help make it better and support other languages. We have solutions to most of the problems you're trying to solve now. Why duplicate effort?
  
• People all over the place are discovering and enjoying Grails. It provides a solution now, everyone else is just talking about a solution.
  

Call me "opinionated", but one thing is for sure I said it at the end of last year and I'll say it again now. This is going to be one hell of a year for Groovy & Grails. So no Charles, you're not wrong, you are indeed right. Its just a matter of time and resources, and whether Sun are willing to to waste their time (Phobos) or commit to something special (Grails).