This thing is dead on arrival. Unless I'm mistaken it's not open source, so the main draw of node (unrestrained hackability -- see npm) goes out the window.
The touted benefit is marginally increased parallel performance, but even if you buy this (I don't), the best case scenario is this buys you a slightly decreased server bill for the price of closedness, lock-in, and compatibility headaches. If your code shards horizontally like this then you can already trivially parallelize and shard across servers with first-class node core clustering.
I spend most of my waking hours writing all sorts of crazy things in node, and I still can't think of any scenario in which using this makes sense.
"This thing is dead on arrival. ... it's not open source, ..."
The open source argument holds except in situations where there is a compelling advantage/value. Companies that are dedicated to open source will not be customers, but may not have been paying customers anyway.
MapR is a good example of a closed source technology doing well in the largely open source Hadoop ecosystem. Many companies will not touch MapR, however there are enough companies that really need the features / capabilities / value delivered by MapR that they are willing to pay for it.
Closer to home, there were people who thought Meteor would not take off b/c it dropped npm in favor of a new (open source) package manager. Yet, Meteor provides enough compelling value that it's growing rapidly even with a new package manager.
That said, this product will need to deliver compelling value to a customer segment that's willing to pay, while accepting the fact that many in the node community will not use it. If there are enough of these customers then the company will do fine. However, that's a tradeoff they'll have to evaluate.
As a total aside, it's my opinion that the open source requirement is selectively applied. Mac is clearly not open source, yet BSD is freely available. Yet people choose to use a closed source OS b/c it provides value to them. Same thing with editors and just about everything else. To those who are open source up and down their stack, then kudos for the consistency. For the rest of us, we should at least be honest and own up to the fact that open source is not an absolute requirement, but a selective requirement that's arbitrarily applied. (flame away :)
> Maybe you don't have a case but there are many scenarios can benefit from multithreading including web hosting.
> The goal is to have a zero compatibility issue and we are almost there with the next beta.
> I believe that the node developers would enjoy benefiting from load aware instance monitored processes instead a trivial multi processing. BTW, still you can combine multithreading with multiple processes in case you want to keep process is active during v8 is GC'ing on one of the threads.
The touted benefit is marginally increased parallel performance, but even if you buy this (I don't), the best case scenario is this buys you a slightly decreased server bill for the price of closedness, lock-in, and compatibility headaches. If your code shards horizontally like this then you can already trivially parallelize and shard across servers with first-class node core clustering.
I spend most of my waking hours writing all sorts of crazy things in node, and I still can't think of any scenario in which using this makes sense.