(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.
Three reasons people think Rails doesn't "scale":
(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.