Wednesday, March 14, 2007

"Griffin, great and growing"

That is (or was) the wording on the water tower for the humble town of Griffin, GA, U.S. of A. I once had a colleague who lived there, and he mentioned that quote with a wry smile. I almost want to say "Grails, great and growing." I've been playing around with Grails now for a few weeks. Unfortunately due to my work commitments, I tend to have sporadic spurts of play, but I'm getting more and more used to it with each session.

Clearly a lot of work has gone into Grails. Chatting on-line to Graeme Rocher, the Grails project lead, I learned that he has an hour to kill on the train from Brighton to London and back - that's an hour there, and an hour back - hence he has time to work on Grails. Time well spent by the looks of it. At v0.4.2. Grails is already quite complete in terms of the architecture and the basic components that you need in a web development framework. What I like most about Grails is that underneath, you're running Java, and Grails uses proven Java libraries like Spring, Hibernate, and Sitemesh. The fact that you mix in a bit of Groovy to glue it all together is a wonderful compromise between productivity and scalability.

I think that's what bothered me about Ruby on Rails. Productivity is great, but at the end of the day, you're still running Ruby, and underneath it all, it's Ruby, and the web server that you use for Rails is essentially single-threaded. Now, before this starts a flame war, I have read about how Rails developers accommodate this to accomplish scalability, so I have to take their word for it that it accomplishes their desired levels of performance. However, to a hardened Java developer like myself, the fact that you're effectively running Java when you're running Grails is a distinct benefit. If I haven't said it eloquently enough, I think Graeme Rocher himself said it best in this entry on his blog.


I think I liked the following quote from that entry best:
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.
That hits the nail on the head in terms of what I was trying to explain earlier. "Scalable complexity" - Graeme, hope you don't mind if I use that in a meeting somewhere to build up my Dilbert points. ;-)

What's interesting in this debate is the clear sides forming within Javaland on the merits of adding effort to Groovy or of shoehorning JRuby into the mix instead. Personally, there's no debate. As Graeme points out, if you read that entire entry, if you're dealing with Groovy, you're dealing with Java. If you're dealing with JRuby, you're dealing with Ruby, with it's own of (different) threading model, I/O, API etc. So you're going to have to be familiar with both Java and Ruby. With Groovy, you're only dealing with Java. Considering Groovy is equally effective and productive, it is hard to understand why Sun are trying so hard to undermine their own language.

As I've indicated previously I've long felt Java technology suffers from really bad marketing. Often the concepts are great, but the name alone prevents you from daring to put a book about it on your shelf, for fear of being shunned like the lepers of old. No offense, but Groovy is a really horrible name for a technology that wants to be taken seriously. Perhaps that's something that the Groovy stakeholders should consider changing. Perhaps that's why Sun are too scared to strap themselves to that wagon. Of course, I don't really consider myself a marketing type, so I won't attempt to offer an alternative. I do know names like "C#", "C++", "Perl" and "Delphi", for instance, can be talked about without the need for copious blushing, or girly snickering under the table at each mention of the name. What's in a name? Maybe more than we really think. What do you think?

1 comment:

Charles Oliver Nutter said...

You have some incorrect facts about JRuby:

- JRuby does not use a different threading model, in JRuby, Ruby threads are normal native Java threads.
- JRuby does not use a different IO subsystem, it uses Java's IO subsystem. It also uses primarily Java's libraries to implement most features, though it puts a Ruby face on them and allows them to maintain Ruby semantics in Ruby code.
- JRuby can also be used to call Java libraries in the same ways you might use them in Groovy, so if you chose to use primarily Java libraries, you could certainly do so.

And your point about Groovy naming may have legs...I know quite a few folks cringe at having to talk about "GStrings" in public and making sure they're not misunderstood.