Monday, January 14, 2008

Relevance on Grails vs Rails Architecture

Oh I love these back and forth posts, as a follow-up to their original thoughts on my last post, Relevance have put up one called "How to pick a platform". Unsurprising, they choose Rails over Grails for the case where there is no legacy "baggage".

Since they're a Rails company (althouth this may change given they've hired 2 guys from the Groovy/Grails community ;-) this isn't really surprising. The conclusions are that Rails' architecture is better because:
  • Ruby is a better language than Groovy.
  • Spring does most of its heavy lifting in the stable layer, which is not the right place.
So let's deal with these one by one. First, the whole "Ruby is better than Groovy" deal, this in my view is subjective and not worth arguing. Ruby has some nice features, and so does Groovy. If you come from a Perl background you'll probably like Ruby's syntax. If you're a Java guy, Groovy is pretty nice.

Stu's, second point is somewhat confusing and contradictory. He link's off to this post by Ola Bini where Ola says and I quote:

"The first layer is what I called the stable layer. It's not a very large part of the application in terms of functionality. But it's the part that everything else builds on top off, and is as such a very important part of it. This layer is the layer where static type safety will really help. Currently, Java is really the only choice for this layer. More about that later, though."

Later Ola goes on to say that Java is no good for the stable layer either and that another statically typed language like Scala would be better, but at no point does he say that a dynamically typed language is good for the stable layer.

Since Rails is 100% Ruby and, according to Ola Bini (JRuby committer) its not a good idea to build "the stable layer" in a dynamically typed language (Ruby) who has the better architecture?

Grails where the stable layer is built on powerful, stable and performant Spring or Rails where the stable layer is in Ruby, which is dog slow and problematic. I'll let you decide.

Personally, I don't buy into Ola's problems with Java for this so called stable layer nor do I believe that a dynamic language can't be used, at least in part, in the stable layer, because 25% of Grails' "stable" layer is written in Groovy. However, what I will say is Relevances' 2 conclusions are complete nonsense and fall into the "Crap" category of their original post.

What I advise anyone trying to make this decisions is download and try out both frameworks and use what suits you and your company. Every business is unique and not every framework is suitable for every business need. Don't buy into nonsense from either Stu or I that ones architecture is better than the other without comparing how it fits into your own existing architecture.

12 comments:

Christian Rivasseau said...

Ola's post is not really interesting since he does not give a single argument to make his point.

I don't understand if Ola does not believe in java on the stable layer why would he get so involved in Jruby and not CRuby, ScalaRuby / whatever he thinks should be on the stable layer.

Graeme Rocher said...

In some senses I agree with Christian, I'm just quoting his post to point out the contradiction in the Revelance post.

However, what I will say is there are big benefits to having some of the core of Grails written in Java performance wise.

Anonymous said...

Graeme

One thing i have learnt in having my own business is "don't get distracted by what the competition is doing"

They will have you running around chasing your tail.

Grails is an awesome framework. What really shines for me is when you really start using it in anger. You can see that you guys have thought of things that would only come from someone who has REAL experience mixed with a purist view of programing.

With Grails you can see that the framework was built and designed by a programmers. Where as Rails was build and designed by graphic designers. That is why when you scrape the surface with Rails things are not too pretty.

Any way my point is. To fend off the competition just keep on doing what you are doing. Grails is superior and will gain market share by simply being the best not by dissing the competition. Let them waste their time with that.

Also try to make sure grails does not try to please everyone. As much as it is important to state what you do it is also important to state what you do not do.

War is not about who is right, it is about who is left.

Pete

Anonymous said...

I couldnt agree more. Who cares about what the Rails guys think. In my book, their fiveteen minutes of fame is just about over ;)

Grails is just too friggin damn good.

Anonymous said...

Sakuraba you really should be approaching this argument with something useful to bring to the table. Although I am a Rails person over a Grails person I still very much value the opinions of others. You can learn a lot from other people no matter who is right or wrong which in this battle is all subjective anyways. I will continue to back Rails for several technological reasons, but there are a few reasons at the end of the day that keep me excited about going to work everyday and it really doesn't revolve around the technology. Yes I am a Relevance guy and will defend our ways and points of view but I think where we all meet in the middle is the fact that I like the people I am working with because they are excited and passionate about technology. I am sure that Graeme and his crew are just as excited to work with each other and just as excited to keep at it everyday. Plus it pays the bills! I really enjoy seeing these types of back and forth(s) but it always takes a turn for the worst when little comment trolls make stupid comments like Sakuraba did. I look forward to reading more from each side because I think we can all learn from it. I am of course biased very heavily but it doesn't mean I don't care about what the other side has to offer! Let's keep the comment banter useful though.

Anonymous said...

fiveteen - is that the accumulative minutes in the lifetime of 5 teenagers - isn't that about 70 or 80 years of fame - that s a pretty long time in my book.

Anonymous said...

Oh boy.. this must feel like being "that other woman". For the first time in my life, I am "that other troll".

>>I really enjoy seeing these types of back and >>forth(s) but it always takes a turn for the worst >>when little comment trolls make stupid
>> comments like Sakuraba did.

There is a difference. I wrote "in my book, ...". That means MY opinion. I have used both frameworks and MY opinion is that I like Grails better. Pretty subjective? Of course it is, nothing that involves humanity can be objective. Everybody has its opinion and is free to express it.


My overall idea to post here was to say that we - the Grails community - should no longer care about the Rails vs Grails yadayada battle. Grails is good enough to stand on its feet, it does not need a framework war behind it.

It is like those "PC vs Mac"-ads. I hate it when they just bash PCs in those ads. They need to show what is better about their product. In the same way we should not use energy on fighting blog posts by some people coming to some strange conclusions. Just show what is so insanely brilliant about Grails here and be done with it.

Raphaƫl Valyi said...

Hi,

I also believe having such a first stable layer associated to a dynamic layer is a key toward a good compromise between productivity and reliability.

Still I think you are very partial in your post.

Who ever told you using JRuby on Rails will force you to forget all the static libs from java? Of course you can use them just like you would with Groovy! I'm actually doing so myself in a project: there is an algorithmic part that needs to be both fast and reliable. It's not intend to change that much. So I went for it: it's just done in plain Java and then I'm calling it from inside JRuby on Rails. Dead simple and effective. Nothing prevents you from even doing it with Hibernate persistent objects or Spring beans... Really nothing. JRoR will only bring the web goodness to your stable, fast and reliable Java stack.

Second, you may argue that Rails itself has no static layer and this is bad. I would almost take it. That's especially true when updating Rails (to version 2) or a gem, you always feel a bit anxious whether everything will work smoothly together again. And sometimes that's true it doesn't. BUT, those edge cases are very rare and should be balanced with the HUGE benefit of using Rails. Overall, one must think that in the huge Rails community, you don't get the reliability from any static code, neither from the test, you actually get reliability and docummentation from the community that's so big and devoted. If somethings goes wrong with Rails, you are absolutely sure you'll Google a better workaround that you would with the J2EE stack (not to say Grails). In short Rails can afford what a small specific project can't.

On the contrary, I've seen so many so-called statically secure J2EE programs that in turn use Java reflection based loose coupling a lot, with no community, no up to date documentation and are full of bugs. So no more hypocrisy here please: Rails itself doesn't really need that static layer itself because its community and concision are already a superior warranty against troubles than any other web dev framework I saw until now.

So IMHO, your whole point about Rails itself not having a stable layer is either naive, either hypocrite.

jonas said...

Graeme,

Grails is a great framework, it has the best of Rails without its weakness (ActiveRecord, IMHO). I just posted about that on this monday: http://jonasfagundes.com/blog/2008/01/grails-the-good-the-ugly-and-the-bad.

I hope will be helpful in this discussion.

Cheers,
Jonas Fagundes

Graeme Rocher said...

@raphael

Again I repeat, I never said I agreed with Ola. I was merely pointing out a flaw in Relevance's blog post in that they seemed to be referring to Ola's post as justification that static languages shouldn't be used in the stable layer when it says quite the opposite.

In fact as it says in my blog post I think there *is* a good case for using dynamic langauges in the stable layer. Its mainly about getting the balance of flexibility vs performance which I think Grails has got quite nicely.

As for JRuby on Rails, I never said that you can't call Java libs from JRuby, what I said is it does not support true mixed source development.

Why? because its a one way relationship. You can call Java from JRuby but going the other way is very painful, and JRuby has no joint compiler.

Anonymous said...

Frankly, I'm just excited to see Grails come to light. As a Java developer who's put a lot of investment in Java, I would not consider a move to Rails --even if for some reason turned out to have an edge.

I am willing to bet that Grails plugin architecture will take a life of its own in this new community and surpass anything Rails has to offer :)

If only the job scene for Grails would be more apparent...

At any rate, I've been able to put together a prototype using Grails in a couple of weeks and should be available by early March, 2008 as:

http://www.socialThumbs.com

100% Grails!

Anonymous said...

I always heard something from my neighbor that he sometimes goes to the internet bar to play the game which will use him some habbo credits,he usually can win a lot of habbo gold,then he let his friends all have some habbo coins,his friends thank him very much for introducing them the cheap habbo credits,they usually buy habbo gold together.
I am so happy to get some hero gold and the hero online gold is given by my close friend who tells me that the hero online money is the basis to enter into the game. Therefore, I should buy hero gold with the spare money and I gain some hero money from other players.