Scaling is fundamentally about the ability of a system to easily support many servers. So something is scalable if you can easily start with one server and go easily to 100, 1000, or 10,000 servers and get performance improvement commensurate with the increase in resources.
When people talk about languages scaling, this is silly, because it is really the architecture that determines the scalability. One language may be slower than another, but this will not affect the ability of the system to add more servers.
Typically one language could be two or three, or even ten times slower. But all this would mean in a highly scalable system is that you would need two or three or ten times the number of servers to handle a given load. Servers aren't free (just ask Facebook), but a well-capitalized company can certainly afford them.
http://www.businessinsider.com/2008/5/why-can-t-twitter-scal...
but a well-capitalized company can certainly afford them
But these days when you don't have to buy servers and make a long term capital commitment and you can use something like AWS, if you have a scalable but not efficient architecture and you have the faith of the investors, you can get enough servers to get you over the hump temporarily, slowly start replacing the most performance sensitive part of your architecture and then scale down.
Look at what HN darling Dropbox did, they bootstrapped on AWS, got big and then when the time was right, they moved to a cheaper architecture - off of AWS and built their own infrastructure.
Purely in terms of App in think the largest would be Cookpad. AirBnB never shared their numbers so I don't know.
https://speakerdeck.com/a_matsuda/the-recipe-for-the-worlds-...
You have your nice web framework in X language and then you need something else quickly is already built-in in Rails or a very powerful feature that in Rails you could just install a gem and call it a day.
I'm working with Express/Node now, I've worked with Symfony/Laravel in php, I've worked with Django in Python, I like them all but there's nothing which can truly replace the speed of coding with Rails.
Most of the problem lies in Database. Rails may not be best architecture for scale. But I doubt you could even get 100x difference if the bottleneck is in Database.
I don't know any large, JVM based WebSite in large scale on top of my head, but I consider Stackoverflow, written in ASP.NET to be one of the best and most optimised site. Near 700M Pageview per month, with 10 Front End Servers. At peak it does close to 5000 RPS, Cookpad does 15,000 RPS with 300 Rails Server. But the SO servers are at least twice as powerful, so that scale is like 500 RPS / Server to 100RPS / Server. 5x Difference.
Twitter was a realtime messaging platform (fundamentally not edge-cacheable) that evolved from that CMS foundation. So the reason for the difficult evolution should be clear.
It's not really a coincidence that before Twitter I worked at CNET on Urbanbaby.com which was also a realtime, threaded, short message web chat implemented in Rails.
Anyway the point is: use my new project/company https://fauna.com/ to scale your operational data. :-)
EDIT: either it was edited above, or I’m blind. I think it was the earlier?
And this is exactly what Twitter did, and how Twitter replaced Ruby and Rails with the JVM
In the context of my original post where the contention was that languages don't scale that architectures do. Your post was that it was exactly what you did - replaced Ruby with Java. Not that you replaced Ruby with Java and rearchitected the entire stack - exactly what my original post said waa the problem with Twitter - the architecture.
To the point of Twitter, what we _didn't_ do, despite a lot of Ruby expertise on the team, is write a lot of microservices in Ruby. The reason for that is that I don't think you can get the same RPS out of a Ruby service that you can out of a JVM service, all else being equal. In fact HTTP benchmarks for various platforms show this, if you bother to look.
1. Twitter wasn't built on a scalable architecture
2. Ruby didn't use resources efficiently -- it was slower than other stacks.
If Twitter had been scalable, even if it were 10x slower than Java, you could throw 10x the number of servers at it until you optimized the stack then reduce the number of servers needed and the customers would have been none the wiser. Of course the investors wouldn't have been happy. Well at least in today's world. I don't know what the state of cloud services were in 2008. Then you could focus on efficiency.
But since Twitter wasn't scalable, you had to fix the stack while the customers were effected. I'm almost sure even in 2008, with the growth of Twitter they could have gotten the capital to invest in more servers if they needed them.
It's not completely analogous but Dropbox is a good counterexample. Dropbox was hosted on AWS at first. Dropbox never had to worry about running out of storage space no matter how big it grew (it had a scalable architecture) but for their use case, they weren't as efficient (ie cost not computer resources). Their customers were never affected by their lack of efficiency because they could operate at scale. They had breathing room to re-architect a more efficient solution.
FWIW, Twitter did what you're describing, we had 4 or 5 thousands hosts running the Ruby stack at its peak. Unicorns and Rainbows, oh my. Then it started shrinking until it shrank to nothing. That period was actual the relatively stable period. The crazy period, the one that I wasn't there for, was probably impossible to architect your way out of because it was simply a crazy amount of growth in a really short amount of time, and it had a number of ways in which unpredictable events could bring it to its knees. You needed the existing architecture to stay functional for more than a week at a time for a solid 6 months to be able to start taking load off the system and putting it onto more scalable software.
Any startup would be making a mistake to architect for Twitter scale. Some startups have "embarrassingly parallel" problems -- Salesforce had one of these, although they had growing pains that customers mostly didn't notice in 2004 timeframe. Dropbox is another one. If you're lucky enough to be able to horizontally scale forever, then great, throw money at the problem. Twitter, at certain points in its evolution (remember AWS was not a thing) was literally out of room/power. That happened twice with two different providers.