I can't tell you how many people have tried to shove ruby on rails down our throats. I'll agree that its pretty looking code, and that its probably pretty manageable, but as of now it is an abosolute nightmare when it comes to scaling.
At SXSW, we had some dude freaking out about how we didn't know what we were talking about because his site could handle hundreds of thousands of users at a time.. It was cute, and almost not even worth responding too given our background with sites like Engadget, TMZ, Autoblog, Joystiq and the rest of the happy blogsmith users.
Anyhoo, one of the Twitter developers, Alex Payne, was interviewed and specifically asked about their experiences with the Rails framework, being that they are now probably the biggest Rails site on the net.
The common wisdom in the Rails community at this time is that scaling Rails is a matter of cost: just throw more CPUs at it. The problem is that more instances of Rails (running as part of a Mongrel cluster, in our case) means more requests to your database. At this point in time there's no facility in Rails to talk to more than one database at a time. The solutions to this are caching the hell out of everything and setting up multiple read-only slave databases, neither of which are quick fixes to implement. So it's not just cost, it's time, and time is that much more precious when people can['t] reach your site.
Full interview here
I have yet to meet a Rails developer who honestly thinks that Rails (in its current form) is a highly scalable framework, unless they come from a design background or a java background. Two backgrounds who ultimately shouldn't be allowed to discuss efficient, affordable scaling in any serious tone. ;)
(hat tip
Gavin for the link)
