Twitter and Rails

In short, a Twitter engineer mentioned in an interview that they'd been having scaling problems with Rails. He mentioned in particular that Rails didn't have multiple db support (from what I can tell he wanted some kind of round robin pooling of multiple db's for performance reasons).

I am not a big Rails fanboy. I like Ruby, but if I was forced to use someone elses framework, it'd be Django hands down - even though Python has some problems compared to Ruby, the metaphor of metadata in the framework rather than a recordset SQL based approach wins easily for me for any non-trivial application.

That said, in any world, the kind of multi-db support they wanted is an edge case and to say that Rails should support that out of the box is ridiculous. To add insult to injury, someone offered a patch that solved the problems in 75 lines of code within a couple of days of the original posting . . .

While DHH does get defensive (hey, who wants people calling your baby ugly?!) I think that he was spot on saying that rather than bitching about the fact that the feature wasn't built it they should have gotten off their asses and contributed their own 75 line solution to the community. That is what OSS is all about.

I saw a follow on article (sorry - lost the link) from another company (slide share or something) saying they were also having scaling problems and that they were using a web server -> app server -> db server architecture so they could more easily throw more processors at Rails in the middle, and they made a good point that "throwing more servers at the problem" is not a free solution in terms of the engineering challenges in managing the servers and making sure they all play nice.

There is no question that dynamic languages and smart frameworks currently come with a performance cost, although I think we'll see less of a cost as the compiler guys catch up with the programmers (I know Microsoft is working hard on optimizing the CLR for dynamic language support, and I'm sure someone must be doing the same in the Java world), so there is (as always) a trade off.

Simple apps with huge traffic requirements needs different engineering choices that complex enterprise apps that may have lower loads but higher complexities and maintenance burdens. When I look at an app like twitter (which is when it comes down to it, a submit form, a list display and an API along with some really interesting scaling challenges) I'm not sure Ruby or Rails would be the ideal tools. I'm not sure what language has the very best support for the highest and most robust levels of performance and scalability, but I'm guessing whatever it is would be the perfect choice - even if it meant it took you a week instead of a day to code the form, the API and the list (I know it is a little more than that, but I think we all know it doesn't need to be TOO much more than that - it isn't exactly an insurance quoting app or something).

As with anything cool and new (remember when Java was the *it* language?!) Ruby and Rails are being widely misused. I am not convinced that all of the Web 2.0 start ups selecting Ruby have picked the bet tool - they've picked the coolest one. However, cool tools bring the smartest programmers so it still may be a smart decision - even if the language and framework has problems, at least choosing them means you can more easily get the most innovative programmers to work on your problems, and just like in Venture Capital where a good team trumps a good idea, in programming a good coder trumps a good language.

Still, it will be interesting to see where Ruby ends up in the programming landscape when everyone finally "discovers" Haskell or D or whatever the next big thing becomes!