Who needs to webscale to millions of requests per minute?
Really, the vast majority of web apps built today will see hundreds of requests per minute.
Still, Github and Shopify have proven that Rails can scale to hundreds of thousands of requests per second. Which is a great number.
Said that, if my goal was to build an app with a simple set of features that don't change often, and that will serve 100 million users, where none of them is paying user, I would probably not choose Rails.
> if my goal was to build an app with a simple set of features that don't change often, and that will serve 100 million users, where none of them is paying user, I would probably not choose Rails.
What would you choose in this case? I'm also a little confused where the user "paying" comes in. Is that in terms of the importance of that specific type of interaction or the concern of friction scaring of "free" users?
Go, Elixir or Java would seem like good options for building something that could handle that many users. If the expectation is 100 million users, then you're truly building for scale, not how fast you can get an app out the door.
Really, the vast majority of web apps built today will see hundreds of requests per minute.
Still, Github and Shopify have proven that Rails can scale to hundreds of thousands of requests per second. Which is a great number.
Said that, if my goal was to build an app with a simple set of features that don't change often, and that will serve 100 million users, where none of them is paying user, I would probably not choose Rails.