This completely misses the point. You don't get rid of non-blocking single OS thread. You get rid of the horrible API to use it. Node says "here's a low level API, now write an ad-hoc version of green threads on top of it". But other languages have been saying "we already wrote and tested a solid green threads implementation on the low level async API for you, you can just use that" for years now.
Even green threads increase memory consumption and add implementation overhead.
Anyway, the call for a sync model is nearly as old as node is and I agree that a solid thread implementation should be part of node for those who like to code this way.
Show me the benchmarks. I have no reason to believe that the buggy, ad-hoc versions being written over and over again in every node app are faster than writing one good version and using it.
And it is not a call for a sync model. It is a call for a sane API.
I got you with your call for a well designed API and I am with you.
About a benchmark, I have none, but it is the nature of threading. Threads need to store and switch contexts. Even if it is just a few 100KBs with 100000 connections this easily multiplies to a gig of additional memory use. In the real world this is often a few MBs per thread making that scale even impossible for a mid class server.
No that's not how green threads work, which was the whole point. You can have an API that presents you with "threads", but not have any actual threads underlying it. It is just a state machine running async, event driven code under the hood. The overhead of such a system is no higher than it is using the naive and error prone event loop approach.
