Ankur Blogoyal

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.

Every time I type copy-and-paste Factory into my code I die a little inside.

I found “Some Thoughts on Cancer from a Hacker” on Hacker News today.

This is the kind of article that really bugs me. Math and Computer Science are so rooted in rigorous theory that we constantly overlook how complex biology is.

Anyway, the author’s proposed solution is

So let’s suppose that there are a million different proteins which either are under or over expressed due to a Cancer. If you had ways of correcting each one, and if a computer could do the analysis, theoretically you could create an intervention that would be tailored to that particular cancer, changing and evolving as the “bugs in the programming” for that particular person mutated.

We aren’t even close to understanding how much we should express certain proteins. Even if we did know, we can only estimate expression of DNA and protein, and the corresponding tests take a couple of hours of chemistry to produce results. Beyond that, we don’t even understand what most of the proteins in our body do, and why they’re expressed in certain amounts at certain times. Finally, even if all of this information were available and this testing were possible, cancer cells by definition have figured out how to survive better than our functioning cells (normal cells fail and die after an appropriate period of time). Cancer cells express proteins at least as optimally as our normal cells, so “correcting” cancer cells doesn’t make much sense.

But, the author admits that he’s not well versed in science. Let’s account for that and investigate this a little more abstractly. His final conclusion is that the current research approach and selfish competition prevent us from pursuing hyper-individualized therapy, because competing forces wouldn’t want to work together and drug trials wouldn’t be convincing enough:

I don’t see any way the government could approve of such a therapy, and more importantly, I don’t see any way private companies could make money from helping folks, unless you let them start patenting each one of the two million interventions, which would effectively bring research to a standstill.

I think the way we do science, the way we do medicine, the way we regulate markets where companies can help each other — all of these things don’t match up to the solution we’re working towards in Cancer research. And a lot of people are going to die because of it.

This is completely incorrect. Have you ever heard the claim that every time you shuffle a deck of cards, you’ve ordered them in a way that’s never been done before? That’s because there are 52! (roughly 8 x 10^67) possible configurations. Well similarly, chemotherapy is a whole class of drugs, and patients receive a variety of orderings and configurations throughout their extended care. There are definitely more than 52 chemotherapy drugs and every patient reacts to these drugs differently, so with high probability each individual cancer treatment is unique as well.

Physicians already try to “debug” each individual’s cancer. The problem is that cancer cells are part of your own body, so it’s really challenging to effectively kill them off without killing off your useful cells. In fact, this is the problem that needs to be solved to “cure cancer,” and the author seems completely unaware of this fact. I suspect that his analysis is a confused combination of media hype around drug companies misbehaving with AIDS treatment and the simple fact that cancer is famously challenging to solve.