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 particularilysuprising
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.
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
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
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, 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
? 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.
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
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
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.
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.
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 ;-)
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
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 allovertheplaceare discovering and enjoying Grails. It provides a solution now, everyone else is just talking about a solution.
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
附：朝花夕拾——Groovy & Grails
posted on 2007-05-01 00:41 山风小子
阅读(513) 评论(0) 编辑 收藏
所属分类: Groovy & Grails