[seabrookmx]

There's always this rift between the "language is slow" crowd and the "but it's not the bottleneck" crowd. I think this comes from the types of applications you work on and their scale.

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.

[ochoseis]

Further, with a lot of the batteries-included web frameworks you end up with a ton of suboptimal database queries (e.g. unintentional query-in-loop). Some would argue that you can just profile your code and optimize the hot spots, but I would tend to think it still slows you down quite a bit overall.

[neonsunset]

One of the biggest breaking changes that EF Core did was to explicitly disallow such generated queries that required application-side evaluation and could not get compiled to pure SQL (you can get other behavior back with a toggle but it is discouraged).

I strongly believe it is wrong to do otherwise and is a source of numerous footguns unless you invest in tracking them down.

[seabrookmx]

I will admit I'm behind the state of the art with EF, but I switched to dapper in the early days of dotnet core and never looked back. It gets out of my way so I can properly utilize postgres' advanced features like jsonb while cutting out a lot of the boilerplate associated with hand-rolled queries.

[neonsunset]

Dapper is great. I'm very happy that there now exists an AOT-supporting flavour of it too: https://aot.dapperlib.dev/

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.

[seabrookmx]

So common that apps like sentry have special logic to detect these "N+1" queries. We find DRF is awful for this.

[fomine3]

It's 'resource usage' rather than 'speed'