Sure, peaks are much higher. But a good part of it is reverse proxying with in-memory caching and locking, which I've implemented in several stacks over the years, and many struggle with it (I have been paid to do comprehensive benchmarks on the topic). On the BEAM it's a non-event.

Only if users are nice and spread the load evenly over the day, but they are never so considerate.

To be fair, Erlang runtime semantics (cooperative "async threads") never needed changing to tackle C10k problem, they got that right as part of the early designs before C10k was even on the tasble.

Everyone else just moved towards the same kind of cooperative thread runtime semantics (even if the lingo differs, async in C#, callbacks first, then async in NodeJS, virtual threads in Java, async in C++ and so on).

I think an interesting historical tidbit is that Java actually had M:N threading in early versions (1.1, 1.2, 1.3?) that got ripped out because it was deemed complex and error-prone since people back then often did native bindings naively (And perhaps file/socket API's were less complete?) only for them to reintroduce it again in Java 20 I think it was under the virtual threads name?

~160 req/s on average, higher peaks. Not trying to impress anyone though, my point was that LLMs work perfectly fine on an Elixir codebase, and that we get future-proof ops on a single node with zero issues. In my experience, it has been easier than with any other stack I've tried.