Twitter had scaling problems because they had such a massive onslaught on their systems. Any language/framework would've buckled a little under that stress. I'm not saying RoR is perfect (its not...) and it has its bottlenecks, but to solely blame the language isn't fair.
Scribd runs on RoR and they've yet to bitch about scaling. Twitter seems to running well now.
Just use whatever feels right in your hands. I use RoR with Django/Python a close second. If you ever run into Twitter-like scaling problems, then good for you. Worry about that when it happens.
Interview: How has Ruby on Rails been holding up to the increased load?
By various metrics Twitter is the biggest Rails site on the net right now. Running on Rails has forced us to deal with scaling issues - issues that any growing site eventually contends with - far sooner than I think we would on another framework.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.None of these scaling approaches are as fun and easy as developing for Rails. All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise. Once you hit a certain threshold of traffic, either you need to strip out all the costly neat stuff that Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move the slow parts of your application out of Rails, or both.It's also worth mentioning that there shouldn't be doubt in anybody's mind at this point that Ruby itself is slow. It's great that people are hard at work on faster implementations of the language, but right now, it's tough. If you're looking to deploy a big web application and you're language-agnostic, realize that the same operation in Ruby will take less time in Python. All of us working on Twitter are big Ruby fans, but I think it's worth being frank that this isn't one of those relativistic language issues. Ruby is slow.
http://www.radicalbehavior.com/5-question-interview-with-twi...
And just to be clear, I wasn't knocking Rails. I have absolutely nothing against it, I haven't even used it yet. I was just trying to point something out. The developer's words, not mine.
The fervor among some of you is disturbing.
---- For us, it's really about scaling horizontally - to that end, Rails and Ruby haven't been stumbling blocks, compared to any other language or framework. The performance boosts associated with a "faster" language would give us a 10-20% improvement, but thanks to architectural changes that Ruby and Rails happily accommodated, Twitter is 10000% faster than it was in January. -----
http://highscalability.com/scaling-twitter-making-twitter-10...