Threading at the JS level in node is really ineffective. V8 has a global lock on all JS objects that prevent them from being passed between threads. The only way to allow threading is to serialize and deserialize the objects into new "isolates" (V8 language). V8 does this for some pretty obvious reasons, you wouldn't really want to allow threading at the JS level in a browser, now would you.
You can use threads if you dive down into C++ land, but event then, you should have a really good reason for doing so, because if you're only manipulating objects for processing you're going to have to serialize into a C++ data-structure, process, and then serialize into a JS object. Threads in node are good for doing process intensive work that doesn't require any two way input from the main event loop, otherwise it's very unlikely to be worth your time or effort.
This is why fibers are kind of silly for node and is also why process intensive programs should most likely be avoided in node (with rare exception). Please use node for what it is good at; it's a short lived connection proxy maven, and good at ancillary front-end work that requires complex state transitions (i.e. mobile). Working it into a monolithic stack is just asking for trouble and pain. No serious architect should consider it for a large monolithic rendering stack.
If computation is local to each of many long-running threads, and the two-way messages being passed around is small enough (so the serialization overhead is negligible), then threads do perform better on multi-core machines than alternative models.
EtherCalc.org is one such use case: http://aosabook.org/en/posa/from-socialcalc-to-ethercalc.htm...
Which mates well with what one of the projects in the article is up to: audreyt's node-webworker-threads. Webworkers extend webmessaging, so it's- as you talk about- about passing objects to one another.
Certainly Webworkers can and have been implemented without threads. Node-webworkers does just that, but it uses websockets to do inter-worker communication: it cannot leverage Transferables that causes the need to copy objects. Would that there be a common process where postMessage() could transfer an object from one owner to another!
I highly recommend learning and using webworkers for all developers- they are a huge part of the future of the web- and anything that Node can do to nurture and make common and harmonious it's existence with the de-facto well defined means for multi-processing. I cannot but see as a good thing. I also cannot help but think that perhaps multi-threading is a fine and advantageous way to achieve webworkers intercommunicating form of multi-processing: it enables Transferables, where ser-deser can be avoided.
Or, like everyone else recommends: use processes and ipc (e.g., the cluster module).
I'd really like to have Erlang-style actors at the JS level in a browser, which is predicated on having threads.
I was wondering over this same statement. It seems rather...presumptuous?
[1] https://github.com/kriskowal/q [2] https://github.com/substack/stream-handbook
Lol, keep killing it web bros.
(Full disclosure: I am, in fact, using Node now, and there is nothing quite so painful as the lack of coroutine or fiber or thread support. Cluster is cool, but only if you want to make a bunch of processes.)
Perhaps you should think of node as "event-driven" rather than "asynchronous".
As for type-checking, there are options such as TypeScript which can be used on Node if a team finds them helpful.
I might be ignorant, but it seems that you have to do a lot of ceremonies for some simple parallelisation, how do I do Parallel.For(...) or Task.Run(...).ContinueWith(...) in Node.js?
We're using it happily in production, and it's proved to be quite stable, and there's quite a few users — certainly more than the average amount of emails I get from other projects. :-)
It's true that I haven't heard from the earliest adopters (like Uber.com), but it might be a sign of its maturity rather than abandonment.
The last commit was 2 month ago, and only to repair compatibility with the then-just-released V8 version. It will likely require another commit for Node 0.12.0 — pull requests welcome!
Edit: Just released v0.4.8 to npm with references to the http://aosabook.org/en/posa/from-socialcalc-to-ethercalc.htm... writeup.
I don't think it's really needed any code updates recently, as it works on Linux / OS X / Windows and all recent versions of node.
I think it's somewhat hard to tell what the adoption of fibers looks like, as it typically wouldn't be used by other modules in npm. You don't want to force people using your module to use fibers. So, it would mostly see its usage in applications.
It will be interesting to see what happens to fibers once generators ship with core node (available now under the --harmony-generators v8 flag). The most compelling reasons for using fibers can also be met by using generators.
(I maintain a library built on top of fibers: https://github.com/scriby/asyncblock)
http://nodejs.org/api/cluster.html http://nodejs.org/api/child_process.html
Now not to say you can't have it "just because", a worthy exercise I'm sure. But in the coming years we will all be asked to use multicores, multiple machines, and multiple data centers. For these scenarios, it may make more sense to think high order.
Hopefully I made some sense, I happen to be on my mobile device.
