"There is no forking or IPC - it's just synchronous events and callbacks. In Erlang you have to think about about IPC on the first connection. The Erlang-model might turn out to be the wrong level of process granularity. Maybe the right level of process granularity is how computers are already designed: 10,000-1,000,000 connections per process, use one per core."

Also false. An Erlang "process" is not an OS process. It already works the way you say, except it can use multiple cores simultaneously. Automatically. Node.js has nothing on Erlang except a familiar syntax. Nor does IPC come up like some kind of blocker; it's baked into the core and quite natural, often all wrapped up behind a simple function call.

And let's not even talk about the baked-in clusterable Mnesia database or the OTP library, which Node.js can only dream about. (Erlang isn't just multicore, it's pretty easy to make it multi-system.) Or how Erlang has code replacement (the Node.js complaint of the day) built right in to the core, where it really has to be for it to work. And Erlang laughs at your "non-blocking purity"; in Erlang, you can call sleep and it won't block anything! No special support needed, no magic from the user, no arranging things in callbacks manually (how 1980s). Try that in Node.js.

It's actually impossible for Node.js to do some of these things because you have to start with them.

You don't understand how Erlang works. That's fine, except you started to criticize it. I refer back to my previous comment that the people hyping Node.js don't seem to have used the competition. Maybe my problem is that I have used the competition, quite extensively. Come to think of it, I've yet to hear anyone say "Gosh, I was using Erlang but Node.js is just so awesome I had to switch!:" That probably says something important.