There are a few interesting discussion points being thrown back and forth between the Yahoo developer Bruno and Joyent founder Jason.
The most interesting question raised in my opinion is Bruno essentially saying that thread-per-request blocking I/O server design is safer than event based server design. If one thread dies it's less likely to propagate problems that will kill the server. Due to this added complication he thinks that node.js should focus more on reliability and believes that V8, with roots in browser side and not server side JS, is ill-equipped.
Jason wants to focus on two things. First, he keeps asking for specific examples of where problems have arisen (as otherwise it appears to be a theoretical fear) and second he wants to push node.js towards 1.0 and stabilize the API and feature set.
It seems Jason thinks Bruno is looking too far into the future. It's essentially the architectural equivalent of premature optimization - until the API and feature set stabilizes there's not going to be any great call for perfectly reliable production servers.
Even then Jason is confident Joyent can deliver on the latter considering how many active V8 devs they have working for them.
Both guys seem to really love server side JS and want to push for it, they just have different ideas about which direction to head.
I admit both of them have lots to say about SSJS or even SS-anything. Still I can't understand Bruno's sentiment towards thread-per-request approach, considering that he's talking about the Node here. Node.js is all about a simplicity of evented, single thread design. If someone thinks this "worse is better" approach went too far in this case, why to use Node at all? There are tons of good thread-based solutions nowadays - a fit for anyone's taste.
The issue is that a single V8 thread in Node.js could be handling the event loop for thousands of clients. A process crash here could cause a mini thundering-herd when all the users attempt to reconnect at the same time.
So his question is not baseless - the solution is to have a VM that rarely crashes.
n.b. Erlang also hard-crashes when it can't allocate memory. This hasn't hurt its reputation for reliability.
A process crash will cause the same problem for thread-per-connection server. There is essentially no difference in stability between thread-per-connection and event-loop based servers.
Yes, Bruno's fundamental point is that "desktop" language VMs will just end a process when there's memory allocation errors. So basically there has to be real means to instrument and error handling has to be robust, he's correct in this assertion.
The most interesting question raised in my opinion is Bruno essentially saying that thread-per-request blocking I/O server design is safer than event based server design. If one thread dies it's less likely to propagate problems that will kill the server. Due to this added complication he thinks that node.js should focus more on reliability and believes that V8, with roots in browser side and not server side JS, is ill-equipped.
Jason wants to focus on two things. First, he keeps asking for specific examples of where problems have arisen (as otherwise it appears to be a theoretical fear) and second he wants to push node.js towards 1.0 and stabilize the API and feature set.
It seems Jason thinks Bruno is looking too far into the future. It's essentially the architectural equivalent of premature optimization - until the API and feature set stabilizes there's not going to be any great call for perfectly reliable production servers.
Even then Jason is confident Joyent can deliver on the latter considering how many active V8 devs they have working for them.
Both guys seem to really love server side JS and want to push for it, they just have different ideas about which direction to head.