Major Enterprise Ruby on Rails Issues?

Published:

July 26, 2006

Greg Luck has written a Report from OSCON2006: The Ruby Conspiracy where he proceeds to smash Ruby on Rails.

First, I’m just starting to get past the Rails tutorials so I have NO (zero) knowledge of Rails at an Enterprise level. And I’ve had similar thoughts to Greg’s that Rails was being pushed for the betterment of the speakers before.

So really I’m asking a question here… Are the points that Greg makes true?

Does Active Record really not have support for Prepared Statements?

We have two production applications running on Ruby. And how is it. Well, despite being perhaps no more than 5% of the functionality of our applications, Ruby on Rails is the number one consumer of Oracle CPU and logical gets. Why? Rails does not support prepared statements, so Oracle has to reparse every time.

He then goes on to say:

And ActiveRecord seems not to have learnt Hibernate’s lession; that OR tools suck for performance and need caching tricks to make them work well.

Although maybe this is a result of Prepared Statements being absent?

Then, he has issues with Rails not running through a connection pool, because fastcgi is forking processes? Really? That sux:

Also, our Rails apps running in (now unmaintained) fast-cgi regularly go awry and fork more processes. Each one creates a new connection to Oracle. So, the opposite of connection pooling; connection denial of service.

Next:

And does Ruby support Unicode. Not really. And is Rails threadsafe? No.

Not threadsafe? Woah! Is this true?

So I’m really looking for answers now. Is everyone that is pushing Ruby on Rails really looking for more money, and not thinking about the enterprise readiness of the product? I know the 37signals success stories, and there are many more, but what of these questions that Greg raises?