Major Enterprise Ruby on Rails Issues?

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?

Groovy OJUG Talk last night

Last night at OJUG (Omaha Java Users Group), Scott Hickey gave an awesome talk over Groovy. I wish I had a link to his website, but I didn't see one. He is the lead on the groovy Eclipse plug-in, and is currently finishing an article for the IBM DeveloperWorks Practically Groovy series covering groovy and spring. He's been writing production groovy code for a few years on a mission critical financial app.

He covered some great code examples comparing java and groovy. Things seem to be written much easier (as like most dynamically typed languages), and it's cool that groovy runs in the same jvm as the rest of the code. From what I could tell, the syntax looks a lot like Ruby.

I liked his example showing how he did some Test First development by using a Map in his test, and later replaced with an object because of the dynamic typing.

He stressed that groovy by design uses BigDecimal behind the scenes, which is great when used in math statements. 1.1 + .1 should = 1.2, but in java it equals 1.19999999 except when using BigDecimal. He had some great examples here too.

He mentioned catching exceptions only when you want to. This was a bit scary to me, but I think in practice I might agree.

As for his Eclipse groovy plugin... They are looking for some help in finishing the code completion portion. It's a difficult task in a dynamically typed language. I'd advise him to look at the javascript Eclipse plugins. The latest ones try to guess what object you are code completing by remembering previous methods that you have called. This works surpising well, and may be enough for them to use IMHO....

Thanks to Scott for a great talk, and to Matt for pulling it all together...