[mcs]

In thread-per-connection server applications, the concurrency is exactly the number of threads spun up for the pool of connections. In node, it achieves that concurrency without a thread pool for the connections themselves, and thus you get less resource usage (memory mostly) for the same number of connections as the daemon scales up.

Node's real draw, aside from pretty easy concurrency, is the package ecosystem.

[tracker1]

Not to mention the overhead of switching threads... Moving context in and out of secondary memory (RAM, disk) is pretty big. And when you get to thousands of threads per core, the context switching becomes very costly.

Some modern systems use thread pools, and manage state switching internally to avoid this overhead at the CPU layer... just the same it is costly.

I worked on a simulator a few years ago that was being written in many threads (each virtual character in play would have its' own worker thread)... this lead to a much lower number of users/system than should have been needed... switching to an event-loop and message bus reduced the overhead significantly.