Grails vs. Rails - My Thoughts

 

[quote=raphael valyi]

"Is there anything that Rails can do that Grails can't?"

-> Well, I'm not a specialist of Grails, but I think the resource stuff of Rails is more powerful. I think Rails is more powerfull at:

• automatically mapping elegant URLs to CRUD operations to any resource, restfully, taking nesting into account
• name those routes so you can simlify your code, avoiding to state obvious but unreadable parameters

[/quote]

Grails has a URL mappings DSL. I'm no Rails expert, but our users enjoy it

http://grails.org/doc/1.0.x/guide/6.%20The%20Web%20Layer.html#6.4%20URL%20Mappings

[quote=raphael valyi]

BTW, You shouldn't think native Rails anymore. You should now think JRuby on Rails. This is now more performant, simpler to deploy (yes, this is finally true!) and allows you to access all the Java platform power, much like Groovy.

[/quote]

Really? I wish JRuby people would get real about this. Without annotations, generics and a joint compiler you simply can't access the full power of the Java platform. Want to a write an EJB entity in Ruby? bad luck. Want to write a JSR 172 web service? too bad. In addition, its a one way contract, calling Ruby code from Java is not fun.

[quote=raphael valyi]

Some useful plugins include: globalize for localization, resful URL mapping for Globalize, resftful authentication, openid authentication, act_as_state_machine for easy unbloated BPM, act_as_taggable, acts_as_ratable and much much more. With Rails, somebody always found a 1 liner to any problem you are likely to encounter and this has a lot of value.

[/quote]

Grails has many plugins too, they're just different and more useful for the Java developer integrating it with Java technologies like GWT, Flex, RMI, JMS etc. :-)

Most of the Rails plugins benefit Ruby devs which is great, but the plugin community for JRuby is very young with goldspike being about the only one

[quote=raphael valyi]

By the way, with native closures inside Java7, I see the space of Groovy threatened, so I'm not too sure it's such a strategic move on the medium and long run.

[/quote]

Groovy's value extends far beyond just closures due to its dynamic nature, I think the only one that feels threatened is those, like yourself, who are realising Rails is not the only game in town ;-)

Grame, 

    Grails has a URL mappings DSL. I'm no Rails expert, but our users enjoy it

    http://grails.org/doc/1.0.x/guide/6.%20The%20Web%20Layer.html#6.4%20URL%...

Thanks for pointing out the Grails documentation (unlike with Rails I couldn't Google for it effectively). Still, now I'm sure about it: what the Groovy docs describes here is the Rails system back to 2004, not the Rails 2.0 nested resful resources of Rails 2007:

http://api.rubyonrails.org/classes/ActionController/Resources.html

And yes it does indeed mattern, Rails 2.0 isn't a small thing. Not fundamental, but still. In my app I might use  a few dozens of such different URL patterns, but that's only 8 lines of code in my route.rb. I know it would have been some dozens of lines (of Ruby terse code) before Rals 2.0.

And that 's not only about those few saved lines. It's just one more evidence there are the leaders and there are the followers. Which one do you ambition to be? 

    Without annotations, generics and a joint compiler you simply can't access the full power of the Java platform. Want to a write an EJB entity in Ruby? bad luck. Want to write a JSR 172 web service? too bad. In addition, its a one way contract, calling Ruby code from Java is not fun.

Well point taken. IMHO that's the only conjonctural advantage of Groovy by now (aside from the syntactic proxmimity but personnaly I think learing Ruby is just worth the reward). Still, this is moving quickly: we had Rubinline (embedding pure Java code in Ruby) working yesterday and we will get a (J)Ruby to pure Java code compiler soon too. Not sure how far it can goes with annotations for instance but still I think it can goes far enough, with optional Java typying passed from Ruby back to Java. Not too bad...

OK, even if JRuby gets closer here, Groovy will stay a bit ahead regarding to calling the scripting language from pure Java code. But actually, the thing is that Ruby is so sweet that you are much more likely to do the contrary and feel happy with it: glue existing Java frameworks and do your abstracted domain specific code in the Ruby language. And BTW the Java 6 scripting framework makes doing the contrary okay too.

And finally no, I don't feel threatened at all, I'm only a happy JRuby part timer, I didn't invest anything big on such a language (unlike you), so that's all fine. I'm just writing this to save a bit of people time if they can give a shoot to JRuby on Rails instead of experimenting with Groovy. I doubt they come back to Groovy but one never knows, history will tells us.

Regards,

Raphaël Valyi.

 

 

Oh we've done plenty of leading of our own. Just in a different direction. Grails features declarative transactions, rich conversations with web flow, command objects, tag libraries, built-in i18n all features conspicuously missing from Rails.

Some cross pollination *shock horror* has even occured ;-)

 http://blog.thinkrelevance.com/2008/1/18/announcing-simpleservices

We just have a different focus than Rails, as you can see we plan integration with Java technologies like JPA, JCR, Portlets etc.

http://grails.org/Roadmap 

But Groovy is trying to be appealing to the Java crowd.  Groovy's fundemental dynamic nature deteriorates performance too much for serious development IMO.  Every primitive operation results in wrappers and math method calls.  Every method call results in introspection.  Unless the Groovy runtime is re-invented Java will be a better choice for serious development I think.  Upcoming closures and what-nots will deminish Groovy's appeal as well.

I'm not against Groovy, there is a lot I like.  But if we want to see Groovy succeed, a concrete plan needs to be in place beyond tinkering and smoothening.  A whole new parser/compiler strategy is needed.

End of day, we must NOT continue to see method calls where inline is possible, NOT see autoboxing where not needed (perhaps that requires updating the language spec), and NOT do indirect dynamic calls (with introspection) where the programmers clearly wants a plain straight forward method call.  I certainly am not going to invest inventing technologies writting in Groovy knowing my inventions will be hampered by this.

Perhaps there is a plan, but is it the right plan? 

No great surprise there then, Websphere and RAD are the most unproductive combination I've ever personally worked on. Overengineering at its best.

I think a better answer though, is to strive to optimize these things and perhaps make small changes to the language that makes it better possible to achieve these optimizations. Perhaps more redesign than optimizing.

The often commonly used stock answer is to use the right tool for the right job. The moment a Groovy application gets used under load and used beyond the simple test and hello world shopping cart toys, the system will buckle. Writing template processing engines and database processing engines might seem attractive in Groovy from a programming point of view, but in practice you just can't. For Groovy to gain real ground, I think it must tackle this issue. I think it IS possible to address the performance (beyond just streamlining and gaining a few percentages here and there). If the compiler knows, or even at runtime it knows, that a method call is known where it lands, it could generate code (at compile time and/or runtime) that allows it to call it without any instrospection. There is also no reason that if the compiler knows it's dealing with all typed variables that all the code can be inline without autoboxing or method calling for math operations.

Without tackling this, Groovy is positioned to compete with languages like Ruby, Python, and Javascript and the like.  It's main competitor will be Java.  This is really backwards, trying to appeal to Java programmers while in the end it'd be better to switch from Groovy to Java because it's the better alternative, because Groovy can't meet the requirements.  Also, Ruby and Python remain rogue geeky languages that the industry is not willing to invest in and use for obvious reasons.  Groovy just makes it another one of those.  Groovy tries to sell the story that it is everything Java is and more.  "There is no learning curve, it's just picking up where you left off and move beyond."  Yeah, with one major thing taken out, all the advantage points of the Java performance. Now ok, granted, and this is cool, you can intermix Java and Groovy.  But when is it ok to write what parts in Groovy, where every time you do, you risk making a compromise?  Imagine in a project with a team of programmers in a weekly meeting.  "Why is our server performing so badly?".  "Oh, it must be Mr Soandso that keeps adding all these Groovy classes.".  Perhaps not fair, but you see my point.

I really think the Groovy team should strive for a re-implementation. You can not afford to in the long run I think.  I'd like to see Groovy succeed.  How is this project run anyway?  Is it a collection of volunteers, or is this an actual team of staff members at a company (Sun?).  Or a combination of both?

I've used both Rails and Grails and truly enjoy either.  I'm finding the same things that are "curves" for me on one are that same things that are curves for me in the other.

Also, Graeme is right...its about choosing the best tool for the job.  If you're wanting to integrate with EJB3, use annotation etc, the Groovy probably makes sense.  Depending on your team as well, if they're already a bunch of Java guys and they're happy doing the Java thing, then you have to look at Groovy.

If you happen to be lucky and work in a place that will let their developers spread out just a bit on other projects, (usually internal projects) then it would behoove one to learn Ruby and RoR.  The options are there to at least deploy along side your already existing java apps and architecture.

It took some time to get used to, but I like looking at Ruby code, it feels clean.  Groovy code to me feels a bit congealed at times, but again, I'm getting used to that too.  

I really do like the Grails domain model approach with the DB being built off the properties of your object and not the other way around. 

Both are viable options in my opinion.  They have similar weaknesses and similar strengths.  I don't understand the purpose of the back and forth game when it comes to this.  Chances are that unless you are running your own show or are the man in charge etc, you don't get to make these decisions.  Alot of corporations say things like, we're all .Net, or we're all Java etc and you won't get the option to choose.

either way, you can't go wrong with at least familiarizing yourself with both.  I'm sitting on a project right now where we basically have come up with three options: Grails, Rails or PHP+Code Igniter.  (My preference is actually the PHP+Code Igniter) but due to some theoretical issues with the possible integration (it hasn't been decided on yet how heavily we'll be interacting with the other systems) we're looking closer at Grails and then Rails (in order to let our developers expand their horizons a bit).

In the end...you can get the job done with nearly anything... 

[quote=cbegin]

Really? I wish JRuby people would get real about this. Without annotations, generics and a joint compiler you simply can't access the full power of the Java platform.

Graeme, tell me you didn't just say that.... :-) I want to be a Groovy fan, and I hope that annotations and generics were only included in Groovy for completeness. I hope I never see annotations or generics being used in Groovy code except where absolutely necessary, which in the case of generics is never.

Want to a write an EJB entity in Ruby?

Since you asked, no. :-) Cheers! [/quote] Hi Clinton, I'm with you man, in an ideal world generics in particular would just go away, you won't find a single example in Grails where we use annotations or generics by default. I believe generics are an abomination and annotations are ok when not abused, but unfortunately they are abused and often just move the problem (from the XML to the annotation). Anyway, regardless of what I or you think, generics and annotations are used in a wide variety of the new specifications coming out the JCP. A language that can't take advantage of those does not, in my view, integrate well with Java. Neither does a language without a joint compiler.

Hi Mike, there are various techniques that can be used to greatly improve performance, in Groovy 1.6 which will be out soon we're implementing the first cut at call site caching (see http://blogs.sun.com/jrose/entry/anatomy_of_a_call_site)

Which is a technique that allows the JVM JIT to inline code at a given call site if it can predict the path is said code is always going to be the same. We've seen that this technique has boosted Groovy 1.6's performance so that on certain benchmarks it is even 8x faster than Groovy 1.5

 This is only the tip of the iceburg. My point is that we do don't believe that performance is going to be addressed by "just some tinkering" and have various strategies to resolve/improve performance in coming releases.

After starting with Perl CGI scripts, I did some JSP pages/servets, then some ASP/ASP.Net, then some Struts work, and then some OCaml/mod_caml work.  More recently, I did one major commercial Rails project, one JRuby on Rails (which was, in turn, on Groovy on Struts), and have now committed to working with Grails, including offering training (see http://www.SmokejumperIT.com).

For my part, I am attracted to Grails because the technologies seem better initially thought-out than with Rails.  Don't construe this as calling DHH an idiot -- he was coming from a PHP background, innovating the technologies from scratch, and using a language that didn't have the support of Java's well-established stack(s) of open source technologies.  So he did the best he could under the circumstances.  But Grails was able to come out of the gate late yet be comparable with Rails very quickly becaues it does leverage those advantages.  And Grails is advancing day in and day out by leaps and bounds as it integrates with other proven open source Java technologies (e.g. my Autobase plugin, which integrates Liquibase smoothly into the Grails development process).  This is really the core advantage of Grails over Rails: it does not have to reinvent functionality, just port it into a more productive and expressive syntax.

There are those out there who will say that JRuby makes that somewhat moot, because it enables Java integration with Ruby.  From someone who has done this, that isn't true.  JRuby works extremely well moving from Java to Ruby.  Due to Java's statically typed nature, though, it does not work well moving from Java to Ruby: basically, you end up having to hand-roll method dispatch, and that's a pain.  Groovy, on the other hand, integrates very well going either direction.

Aside from being built on established, proven technologies and having better Java integration, the last key advantage I found in Grails is a more mature recognition of the functionality needed in an application that isn't just CRUD.  Specifically, the de facto standard Quartz jobs, Spring dependency injection, and the ability to launch background jobs without hackery were functionality/capabilities that I really missed in Rails.

There are other more minor advantages, too.  As a Rails developer, I always have to keep schema.rb open in addition to my domain class when I'm trying to understand my domain objects: with Grails, that's all in a single place (and the most common migrations are written for you).  As a Rails developer, I end up having to create non-ActiveRecord domain objects into my model folder in order to encapsulate what Grails represents as Services.  The Grails taglibs and GSP format are also much, much cleaner than Rails's helpers and inline coding.

All of this said, I think it is important to remember that if your previous web application structure is straight CGI scripts or Struts, you can't go wrong by picking any of these leaders.