(1) Earlier versions were adopted by applications with anomalous scaling requirements. So, the project had to "learn to scale" on its feet in a very short amount of time. There were predictable hiccups. Or, put even more simply: it's a young framework that got adopted quicker than people expected.
(2) There's an expectation that web platforms can accomodate near-automatic horizontal scaling with maybe just a couple config-file tweaks. That expectation is unrealistic on any platform for which you can easily hire developers. The reality is that scaling to Twitter or even Github's volume is extremely difficult, and the developers who can reliably accomplish it on any platform are extremely hard to find and extremely expensive.
(3) Rails attracts a kind of junior/casual developer that Python just doesn't have, and (weirdly enough) also I think attracts systems developers like myself that aren't steeped in web scaling folklore, which long story short means lots of projects start out by making lots of embarrassing mistakes.
In our practice we see much more Rails today than we do any other framework (there may be some selection bias there, but probably not too much) and for the most part Rails just works. It is definitely not the case that we see lots of startups go out the gate on Rails, go "oh shit we can't scale", and switch to something else.
> There's an expectation that web platforms can accomodate near-automatic horizontal scaling with maybe just a couple config-file tweaks. That expectation is unrealistic on any platform for which you can easily hire developers.
I can attest to this. I did consulting work for Match.com a few years ago back when they ran around 20 million uniques/month. They are a .NET shop here in Dallas, TX where you can throw a stone and likely hit a .NET developer.
After a few years, their stack looked nothing like a typical ASP.NET stack. It included things like custom database replication, memcached, config pulled out of files and stored in actual code, and lots of other things that went way off the beaten path from standard practices for .NET. New developers often had to learn "The Match Way" before they could be effective. Many things that worked with typical .NET enterprise apps would break down spectacularly when massive scale was thrown at them.
Hulu, Living Social, All of 37 Signals, Groupon, AirBnb, Scribd, Zendesk, Soundcloud, etc.
Twitter's scale is unlike nearly every single web app online, so I think the real story with Rails and Twitter isn't that "they had to move away from it for scalability reasons," but rather it's amazing that they were table to leverage Rails for as long as they did."
Also, Twitter is more dropping Ruby all together rather than just Rails specifically. Again, this isn't to say that Ruby isn't a great language that works for most people (it let Twitter grow quickly to where they are today), but at their scale with their demands it doesn't work well.
From my experience, you can scale a rails app the same way you can scale a django app the same way you can scale a java webapp, and so on. The general problem with frameworks is they try to make you not think about datastore access. Datastore access tends to be the hardest part to scale.
Also, in addition to what others have mentioned, iLike uses (used?) rails - it was a large early facebook application. Not sure what their traffic is like nowadays, but I think it was pretty large in the early days. (Edit: http://blog.ilike.com/ seems to document their growth in registered users all the way back to 2007)
Shopify is using rails. The thing is rails is bad when there are a whole lot of short life requests. This is what twitter had. The entire rack middleware being loaded for every tweet.
I'd like to know this as well. Some of my Coworkers went to RailsCon a few weeks ago and were remarking how a speaker talked about how they scaled from tens of thousands of hits a month to a couple hundred thousand hits a month. Not very encouraging when that's the sort of traffic we get in an hour and the solution was to use nearly double the amount of web and memcached servers than we do now on our PHP stack.
You can't compare servers to servers. Each app has its own computational needs and caching rules. Your hit is not my hit. One site might simply render a template, another might perform 20 queries and generate giant complex docs.
While it's true you can't do 1 to 1 the fact that my site does ~700 times as much traffic, and it is absolutely the latter of your two types time ten is a cause for caution. This is why I want to hear from some actual enterprise level people that have solved real scaling problems, unfortunately at the conf it seemed like startup size scaling problems were being addressed, and perhaps not very well.
I know Twitter kind of had to move away from Rails due to scalability issues.
Is that true? I know they replaced their Ruby Starling system with a Scala-based solution, but that wasn't Rails to begin with. They also built a new search engine that didn't use Rails. But as much as I can ascertain, the core consumer facing product still does use Rails today.
But will JavaScript be able to scale? It has come a long way from the days of onMouseOver but it seems like it's going to be hard unless it gets turned into a different language (i.e. Dart).
V8 increases performance by compiling JavaScript to native machine code (x86,[2] ARM,[2] or MIPS[3] CPUs), before executing it, versus executing bytecode or interpreting it. Further performance increases are achieved by employing optimization methods such as inline caching.
I mean the language itself, not the performance of the individual implementations. For example, I can't imagine prototype based OO being used for large scale projects.
I'm pretty sure they still use Rails for the HTML application that you see when you visit twitter.com - it's the backend stuff (the data storage layer, the message queues, the API etc) that's been ported over to Scala/Java.
Also who cares if Twitter had to move to another technology. 99.9999% of people will never ever have to face those issues.
Twitter would have hit the wall with any other tech, it just grew like crazy all of a sudden. The fact that it was able to get on its feet so fast though, that's thanks to Rails.
I think this whole "Rails doesn't scale" is the new "Java is slow". Baseless and ridiculous.
I know Twitter kind of had to move away from Rails due to scalability issues.
GameBattles.com also had to back away from Rails after their uptime dropped to 80%.
I am not trying to tarnish Rails, I am just curious to learn about some success stories involving Rails at very large scale.