Monday, March 12, 2007

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).

4 comments:

Dierk said...

Hi, very good post!

I would like to add that there is a fundamental difference between the two types of languages for the Java platform: type A, which are languages designed specifically for that platform (Groovy, Scala, etc.), and type B, which are ports of a foreign language (Jython, JRuby, Kawa, Bistro, and the likes).

While type B languages can achieve a decent level of interoperability, only type A languages can truly integrate with Java. This is because foreign languages not only have their own libraries, APIs, and such but more important, they come with their own object model, threading architecture, security concept, performance and debugging hooks, and last not least their own runtime architecture that can be fundamentally different from Java. Any type B language has to overcome this impedance mismatch breaking either Java's or the foreign language's behavior.

The acid test for integration is to replace any given Java class (be it abstract, or in the middle of an inheritance chain, or having overloaded methods, or using annotations) and replace it with an implementation in your language. This is what only type A languages can possibly achieve.

Dierk

Anonymous said...

While Charles has good points, I definitely agree that continuing the focus on core grails development at this point in time is a better use of time and resources.

Splab said...

I would like to strongly disagree with Graeme's assertion that shoehorning JRuby into Grails is simply a matter of resource. This is a classic case of when you have a hammer, everything becomes a nail.

There are clear and obvious benefits to using Groovy (regardless of that name) over JRuby with Java. I believe the arguments put forth by Graeme elaborate on this eloquently. You have the same issue with .NET. You can port any language to .NET, but there will be a few hoops to jump through where the idioms differ substantially. And IMHO, Ruby is sufficiently different to Java that I come to the point of begging you, not to try and shoehorn JRuby into Grails.

I've seen this happen on other open source projects. The big problem is that people like Charles, while being very competent, overlook the frustration that users experience picking up, running, and staying with a technology. Webwork was like this. Webwork 1.x was a great framework. Then *cough* (he shall remain nameless - he knows who he is) got it in his head that Webwork needed a complete rewrite, and thus we got XWork+Webwork2. Jump ahead a year or so and now we have Webwork2 moving to Struts2.

I'm so frustrated with this kind of unnecessary leaf jumping. Stick to your leaf on the pond. We aren't all frogs and we don't all like jumping from one leaf to another when all we're trying to do is get out of the frigging pond. Okay, my analogy went pear-shaped, but the point is that Groovy and Grails is a marriage made in heaven. JRuby is the ugly step-sister.

Charles, you're probably really smart and you may have good intentions, but at this stage of the Grails project, if you dilute the effort into JRuby and Groovy support, what you're doing is halving the development resource commitment, doubling the documentation required, fracturing the learning curve and all for what purpose? I don't get it. If people love Rails/Ruby so much, then damn well stick to Rails and Ruby. If scaleability is your concern, fix that, but fix it in Rubyland. Stay the hell out of Javaland.

I'm sorry for my ranting, but I'm so sick and tired of discovering a really cool, new technology, getting excited about it's application in my world of interest, only to see if fractured by the genuine but misguided efforts of some people who seem to take more pleasure in the framework than in what the framework can accomplish.

Anonymous said...

Hmm, guess I should reveal my true identity other than just 'splab'.

Done. :)