You can get equivalent performance through more work, more caching layers, more servers and more hardware resources, but there's a real limit to how much one server can handle before it starts slowing down.

The simple fact is that a a Bash web server will never be as fast as a bespoke x64 assembly HTTP server. There's a huge gradient between the two and I'm not suggesting we need to build a Mastodon backend in C, but this "it's a web server so who cares about performance" approach to programming languages needs to go.

Take a look at the techempower listing if you don't believe me. Ignore the weird, bespoke, benchmark oriented servers and focus on real world applications if you wish to make the gap smaller but even among big frameworks you'll find the differences. JSON serialisation is one example every web API needs to deal with, and ASP.NET stands head and shoulders above Ruby on Rails performance, for example.

In practice, there's probably no real performance difference between the JVM, dotnet, and Rust frameworks because of I/O limitations. However, Ruby on Rails lives in a whole different performance segment, next to PHP and Python.

https://www.techempower.com/benchmarks/#section=data-r21&tes...

There is a reason Twitter switched from Ruby to Scala during their fail-whale era.

If the Rails part scaled as well as my DB, I believe I could trivially handle 10x the number of users I have today.

Having fast code means that random $10 a month VPS can now support much bigger community. The hosting providers can also provide cheaper/better service for people that want just pay someone to run it for them.

Not really when it powers most of eCommerce, services in and around Asia; within Japan it's far from obsolete.

It may not be a thing in the Western World. It is over the pond.