The Erlang thing is different though - that's a userspace scheduler, scheduling userspace tasks onto one-thread-per-core. Classic M:N scheduling in a similar way to go.

It works extremely well at scale - you can handle 10k connections on a normal machine with very little thought, and WhatsApp has reported handling 1 million. Yes everything has some point at which it won't scale, and apparently that approach (or at least that implementation) struggles at 100 cores. That's not a normal machine.

It appears you are unfamiliar with "may" coroutines which is a userspace M:N scheduler.

Erlang phenomenon mentioned is the same and the behavior is easily reproducible on a normal laptop.

"may" defaults to the same number of OS threads as there are cores. Scale the set_pool_capacity() to 1000, 5000, or beyond for coroutine scaling. Also try set_workers() for OS threads.

Try it any which way and you see thread contention and cache locality penalty increasing latency.