Node.js is backwards

I read an interview with James Duncan, who is part of the company backing Node.js. One question in the interview really struck me:

A hot topic in computing is parallel programming in languages such as Erlang. Is JavaScript going to join the party?

James Duncan: Node, in some ways, has a similar view: it’s all asynchronous-based programming, all asynchronous IOs. Where it steps away from what Erlang is doing is that it explicitly says, “You shall run as one process.” You get one CPU to play with. What we’re going to see inside the Node space is some capability to have messaging between CPU cores and, therefore, Node processes running on different CPU cores. I don’t know if anyone’s going to go to the same extreme as Erlang, but some of the things Node is doing are similar.

To understand why this is misleading, we need to go over some background information. Erlang popularized the concept of lightweight processes (Actors) and provides a runtime that beautifully abstracts the concurrency details away from the programmer. You can spawn as many Erlang processes as you need and focus on the code that functionally declares their communication. Behind the scenes, the VM launches enough kernel threads to match your system (usually one per CPU) and has event-driven context switching (epoll/kqueue) built in. It also abstracts away the details of communication, so communication between processes on the same machine is identical to communication between processes over a network. Essentially, you can write event-driven, asynchronous Erlang code without having to worry about what blocks the system and how to connect CPUs (locally or over a network).

On the other hand, Node.js is a hack on top of Javascript/V8 to replicate these features. It requires explicit continuation-passing-style (chains of callbacks) since the language itself doesn’t support event-driven I/O. The code blocks until you return from the current function and pass a callback (continuation) to the global event loop. When your blocking I/O is complete and the event-loop is surrendered to, it will call the callback you provided, continuing the execution of your “task.” The result is isomorphic to user-space threads where the scheduling is done by the programmed code rather than a backing runtime scheduler. The lack of language support also necessitates that the programmer manually run one process per core and figure out a way to make “Nodes” communicate. Communication involves further layers on top of the language like RPC frameworks and message types (thrift or protocol buffers, for example), which have to be custom-tailored to Node’s asynchronous I/O strategy.

Node.js’s concurrency mechanisms are simply an approximation of Erlang’s. Saying that it “steps away” makes it sound like the creators of Node.js wanted to do things differently than Erlang, but in reality they were forced to work within the confines of Javascript to crudely replicate some of Erlang’s behavior. Furthermore, Erlang isn’t “extreme” for supporting this programming model. The heavily tested Erlang runtime will automatically figure out the optimal way to load balance the resources on your machine. Node.js appeals to people who already know Javascript and don’t want to learn a new language, not systems optimization people who can design software that load balances itself as well as Erlang. In fact, the mechanisms for IPC/RPC in Javascript push the language to an “extreme,” but they are perfectly natural in Erlang.

It’s worth pointing out that I am in no way affiliated with either language, and I certainly don’t think Node.js is completely a bad thing. Enabling people to code in more ways than before is always great, and I certainly respect the project. But, the people involved should be straight about the fact that their system is an approximation of what Erlang provides. It’s not “in some ways, a similar view.” Instead, it’s the same view, just executed in a different language that doesn’t support event-driven I/O natively.

∞Posted on June 11, 2011

Notes: 22 notes

Comments: View comments

Tags: erlang,javascript,node.js,