"if your framework only supports one (or a few) concurrent connection you're gonna have a bad time."
Rails only supports one concurrent connection per process (by default...for good reasons), and there are a great many people using it at scale, including on Heroku. Asynchronous stacks are becoming more common, but they're still exotic in terms of deployment -- and most of those probably aren't written very well.
I'm specifically talking about WebSockets. Do you really want to run one process for every client to connected to your WebSocket server? The answer is no. Even one (OS) thread per connection can get unwieldy.
And I think lots of people would disagree that async stacks are still "exotic" or "not written very well".
"Do you really want to run one process for every client to connected to your WebSocket server? The answer is no. Even one (OS) thread per connection can get unwieldy."
Yes, no kidding. But people will still try to do this with frameworks that don't support anything else (like Rails), because that's the shortest path to a working product.
"And I think lots of people would disagree that async stacks are still "exotic" or "not written very well"."
Well, those "lots of people" can disagree all they want, but they're wrong. The problem isn't that the frameworks are badly written, necessarily -- it's all the stuff in the stack, including the app-specific logic. Virtually no one knows how to write asynchronous web apps of any complexity. It's a very hard problem.
Rails only supports one concurrent connection per process (by default...for good reasons), and there are a great many people using it at scale, including on Heroku. Asynchronous stacks are becoming more common, but they're still exotic in terms of deployment -- and most of those probably aren't written very well.