Do you have a reference for the "official policy" statement? Any experienced, systems developer, regardless of language, would never think that was a good thing.
In addition, it is not hard to handle the errors due to callbacks. The Node variant of Javascript is basically dynamically typed C and error handling actually follows a very similar pattern to what is standard practice in C. Fault-tolerant systems are hard, period. But since the most important fault-tolerant systems (cars, planes, etc) are all written in C. I do not see why it is "too hard" to build a fault-tolerant server with Node since error handling follows a similar pattern.
Just to be clear, I am not advocating the use of Javascript for automobile software.
With the crucial difference that in Erlang, the thing that dies is extremely fine-grained, while in Node it's the entire server. In other words, this is far from the Erlang way of doing things.
Comments
Do you have a reference for the "official policy" statement? Any experienced, systems developer, regardless of language, would never think that was a good thing.
In addition, it is not hard to handle the errors due to callbacks. The Node variant of Javascript is basically dynamically typed C and error handling actually follows a very similar pattern to what is standard practice in C. Fault-tolerant systems are hard, period. But since the most important fault-tolerant systems (cars, planes, etc) are all written in C. I do not see why it is "too hard" to build a fault-tolerant server with Node since error handling follows a similar pattern.
Just to be clear, I am not advocating the use of Javascript for automobile software.
I don't know about node, but it's certainly the Erlang way of doing things. You let the process die and leave a supervisor to deal with the problem.
With the crucial difference that in Erlang, the thing that dies is extremely fine-grained, while in Node it's the entire server. In other words, this is far from the Erlang way of doing things.
Here's where the official API docs say you should always let your process die when you encounter an unhandled exception:
http://nodejs.org/api/domain.html#domain_warning_don_t_ignor...