> Node.js’s concurrency mechanisms are simply an approximation of Erlang’s.
Lulz? Here's a much simpler explanation: it's a polling server. It's not an intentional approximation of this or that (Erlang), this is just how event loops using select\poll\epoll\kqueue have always worked. Unless you want to do a bunch of extra work and throw in per-core preforking\threading and scrap the libev dependency Node built upon.
Erlang, and other similar efforts like Haskell's forkIO and Python's eventlet/gevent, are also built upon the same fundamentals as libev (and some actually just use libev). But using libev in the way that Node.js does boils down to user-space threads with cooperative scheduling (you yield control every time you make a blocking I/O call). The abstractions that Erlang/Haskell/Python provide let you program in the familiar synchronous, threaded style while retaining the performance advantages of an explicit (e)polling server.
>(you yield control every time you make a blocking I/O call)
You're referring to is coroutine vs. continuation passing (callback). This is unrelated to whether you also are also forking into a small number of processes for each core. You can do both. Node simply doesn't yet. Nginx with workers is an example of an asynchronous server that does.
In regards to your link and the coroutine yielding approach: Being able to write psuedoblocking and monkeypatching code is not necessarily a good thing! It encourages you to keep making subrequests sequentially in serial, rather than in parallel as comes natural with using callbacks. It also discourages one from using custom continuation logic such as quorums. Examples of when the yielding approach fails:
- You want to both send and read independently on the same connection without creating multiple coroutines\greenthreads\userthreads per connection.
- You want to continue once 2 of 3 data services have calledback that information was successfully stored
I've written a fast single-core asynchronous server here in Lua without using user space thread yielding that you may be interested in: https://github.com/davidhollander/ox
Lulz? Here's a much simpler explanation: it's a polling server. It's not an intentional approximation of this or that (Erlang), this is just how event loops using select\poll\epoll\kqueue have always worked. Unless you want to do a bunch of extra work and throw in per-core preforking\threading and scrap the libev dependency Node built upon.