3 ms·
Why highly suspect ? We know and use cooperative concurrency since decades. Agreed on the "not suitable for all" but no one said that.
by mackwic 12y ago
Why highly suspect ? We know and use cooperative concurrency since decades.
Agreed on the "not suitable for all" but no one said that.
- rubiquity 12y agoCooperative concurrency is fine and a lot of languages use cooperative concurrency just fine. The issue with Node is that it completely ignored the multicore reality that we live in. Everyone argues that multithreading is so complex, and it is unless you have the right abstractions. But what is guaranteed to always be complex is single-threading with process forking. As soon as you want to communicate between processes, and you will want to communicate between processes, you now have to implement IPC. In come the message queues... that is once you pick which message queue to use. We've also been using event-driven IO for decades and Node is the only modern run-time to ignore the obvious perils of evented IO. Instead of doing what languages like Go and Erlang did, which is have event loops in the run-time that are completely transparent to the developer, Node pushes the evented IO right into the application developer's face. Are there remedies for writing good evented code? Absolutely. But why should application developers need to be schedulers in the year 2014?
- ziikutv 12y agoThe stuff you were saying about forking, IPC... it made me giggle because I just wrote a midterm on these concepts last night :) Thanks. Erlang seems interesting, would you mind expanding on Erlang or GO?
- rubiquity 12y agoEverything in Erlang is asynchronous and non-blocking but this is almost completely transparent to the programmer. When you start an instance of the Erlang VM it spawns as many threads as you have CPUs and a thread for an event loop. Each thread can have thousands of Erlang processes (Erlang's unit of concurrency is called a process) executing. Inside of the thread is an Erlang scheduler that allocates execution time to each Erlang process using a technique known as reduction counting. Erlang also has great features for distribution. Communicating with processes that live in another Erlang VM node is also transparent. It's debated whether this is a good thing or not because some people think communicating over the network shouldn't be transparent due to partitioning, but in a lot of Erlang programer's experiences this is a wonderful feature. The result of all of this is that the Erlang code you write looks synchronous but is executing concurrently. You have both CPU concurrency and IO concurrency. The Erlang VM takes care of most of the nasty bits of asynchronous code, which is what a good language run time does for you.