I work at what a company that's not particularly large. Our original API is a Django monolith that serves about 1000req/s.
While you could argue Python isn't the bottleneck, Django often is. I hear the same feedback from colleagues that work in Rails. Not only do we run into issues with latency per request but we have to run a significant number of Kubernetes pods to serve this workload. With c#, golang, java or a similar language we would only require a handful of pods and drastically cut our compute costs.
Even for web workloads, these slow interpreted languages and their developer experience optimized frameworks absolutely do become a bottleneck and claiming they don't (or that you need to be at Google/Facebook scale before they do) is false.
Everything is a tradeoff but the way I think of it: speed is a feature.
I strongly believe it is wrong to do otherwise and is a source of numerous footguns unless you invest in tracking them down.
As for EF Core - it very good as of today (has it ever been bad?). You can transparently compose your queries with `context.FromSql(...).SingleAsync()` which will use string interpolation API to consume your plain $"SELECT * FROM {myTable} ..." and make it injection-safe and transform passed arguments as appropriate. It's quite handy.
For every engineer insisting Ruby is fast enough in a situation where it is not, there are 1000s in environments where Ruby absolutely is more than sufficient, insisting it’s too slow.
You're trying to make it seem like it's a wash, because "scripted" but it's not. Node.js outperforms Ruby in every department. And it's based on one of the slowest scripting languages of all time. Ruby is a dead language in many countries.
In Canada, you would have to travel the country to find a Ruby job. And if you don't think in American-centric terms, that is meaningful.
I enjoy writing Ruby a heck of a lot more than I do writing JavaScript. I like the object model. I like Ruby’s standard library. I like the Ruby community. I like the tooling: irb is fantastic. Bundler is still one of the best package managers around—makes npm and yarn look silly by comparison.
The spec sheet just does not matter for virtually any of my work. Switching to a less enjoyable, more performant, language might make a 60ms response time average become 55ms. Who cares? That performance difference was even bigger 15 years ago, and it didn’t matter then. It matters less today.
GitHub, Shopify, Airbnb, Netflix (yes! Even Netflix!), Soundcloud, Kickstarter, etc. etc. all use Ruby today. It is a fantastic development environment when you’re more concerned with doing your job, and less concerned with performance pissing contests.
We're talking about performance because of the context, which is – there aren't the jobs to support the language's continued growth and dedication. We're talking about speed because there needs to be a defining reason to continue using a language and develop in an ecosystem that isn't moving at the growth of other communities.
If Nintendo Switch had 4 games, and they all looked like dog piss - asking why would I bother wasting time with Switch is a valid opinion.
There's also this insect-minded logic of only being a "front end developer" or "back end developer", and that mindset is furthered by languages that don't bother speaking the language of the web. If I learn javascript, I can be both - pretty much on day 1. If I learn Ruby and Javascript, great. How easy is that to do for a junior developer just getting out of school? Not widely.
You wouldn't spend so much of your time reading and writing about ruby if you didn't care about it. You'd move to things you do care about.
Ruby, and scripting languages in general, are fast enough for the jobs they get used for. When they're not they get replaced.