Twitter's scaling needs are in the 11,000 requests/second and higher range (number from DHH). How is that working out, given that Twitter was developed in Ruby on Rails? If I can paraphrase the discussion so far:

Alex Payne (Twitter Developer): Ouch, scaling that big with Rails was hard, and we lost a lot of the elegance of ActiveRecord.

DHH: You could work with us to improve ActiveRecord to address this issue and continue to benefit from the elegance of the programming model.

People will draw their own conclusions from these perspectives. I personally live in the "make it work, then make it fast" camp. But the interesting point is not the discussion, it is the context: 11,000+ requests per second. Wow. 99% of all web application code will never need this scale. For most every project out there, advantage: Rails.

Lots of people are invested in the "Ruby is slow (but I don't care)" meme. Benchmarks establish that Ruby is just about the slowest serious language out there. Enthusiasts counter that Ruby is fast enough for most tasks, that programmer productivity is more important than processor productivity, and that there is nothing intrinsically slow about Ruby -- faster implementations are on the way.

Both perspectives are valid, but Avi Bryant makes an excellent point that has been mostly overlooked: Ruby's internal optimizations have made the language more difficult to understand and implement. But wait, you say. "Ruby optimizations? I thought the language was slow." Exactly. And because it is slow, much more of the core is written in C. This implementation choice leads to some unintuitive behaviors, although (as Avi's example demonstrates) you will not encounter problems unless you are doing very odd things. The more important effect is on language implementers. Avi argues that the JRuby team has to work much harder because the core is too large. The core is too large because of an optimization that was probably necessary at the time, but will seem premature in hindsight five years from now.

Except that the problem will be gone in five years. We can fix this one.