I can certainly see your point, and I am aware that I am playing a little fast and loose with some of the terminology around blocking vs non-blocking. To be precise, in node's case, it presents a consistent, callback based API to non-blocking IO. Given that that API is reflected exclusively in JavaScript the language, this has impacts the style and appearance of Node programs. The resultant style is imprecisely referred to as asynchronous, non-blocking, etc.
Using Erlang vs Node on my current project was a serious consideration. It is well thought out and its message passing and lightweight process based design is more evolved than anything node has or likely will have. It's also Erlang and I have found productively programming in it to be incomprehensible. Maybe its a personal problem, but it is what it is. Ditto for Haskell. I was surprised to find that my brain didn't bend that way.
Very good points. I wrote the article and have struggled a lot with how right node is as a general purpose tool. My interim conclusion, for many of the reasons you point out, is that to the extent that it can be made relatively safe, it is a good tool for those situations where my other choice would have been to write a massively scalable, non-blocking C program. This class of problems does not come up every day, but it is coming up more and more as the web and mobile arena move to more of a fully connected mesh of clients and the switchboards that arbitrate their exchanges need to become more flexible and efficient.
On the flip side, building massively scalable systems based on blocking IO is rife with problems and I've found that enforcing architectures that make it manageable have a way of obscuring the code and making it difficult for people to intuitively get right as well. I personally find the explicit functional style to be just as intuitive as structured and/or OO and therefore find that when I need it, a platform like node that makes the knife's edge that is asynchronous programming explicit and manageable with a good functional style is a good trade-off in the world where I am trying to find less bad options to a hard problem.
Sometimes you have to step back 20 years in order to break through the layers of assumptions that were added in the interim. I doubt node is the last word on the topic, but it is a refreshing interlude to what was becoming an unwieldy calcification of the theory of how to program computers. The water will find the right course eventually as we experiment with the different styles.
That was embarrassing. I do know how to craft a good apache config, and am just going to claim a case of being stupid.
It is ironic that node is in fact designed to handle this type of memory/connection scalability problem reliably, but in this case it was pure administrative (me) error.