Nonetheless, as a junior Rails developer coming into a 5 people team on a mid-sized project, I saw a diverse set of performance problems during the development phase. E.g. asset pipelines that take ages to compile so that rapid development cycles become impossible or a test suite that took heroic efforts to get down to 15 minutes despite not really doing much computationally-wise. I'm open to alternative interpretations, but I've got the impression that in more performance oriented frameworks the best practice would not turn out to be setting up and tearing down half your server stack before and after each controller test, but instead we would have chosen abstractions that can be plugged together more efficiently.
I get that it won't hit Twitter scale but that matches the majority of "how do I build a prototype" use cases.
One really insipid blog post and thousands of mindless followers later and the damage to Rails has been done.
That's not to say Rails doesn't/didn't have other issues -- it did. It's just telling that Twitter is the first example people reach for instead of anything else.
Twitter is certainly of a scale that I would not be using Ruby on the primary load points. But even billion dollar companies don't often reach that scale.
even if it's slow today; the runtime is being improved regularly and making a lot of code just faster with a version bump.
Maybe in an API server. But this is nontrivial in a monolithic application where you end up yakshaving the whole middleware stack to parity just to replace an endpoint.
You can always replace the endpoints that are slow with something written in a more performant language like Golang or Erlang later.
I’ve worked on all sorts of applications from corporate CRUD to mobile billing gateways written in Ruby (usually Rails), and in very few cases has Ruby itself been the bottleneck.