node.js misconceptions?

Question

From the node.js page

"Almost no function in Node directly performs I/O, so the process never blocks. Because nothing blocks, less-than-expert programmers are able to develop fast systems."

so if a less than expert programmer does something like start an infinite loop in the callback, it doesn't kill the system (eventually)?

or, more realistically, someone does something inefficiently and it takes a long time to handle requests (say half a second or whatever). It feels like the claim 'nothing blocks' -> 'fast systems' is fundamentally flawed.

Can someone explain how in this situation the system wont suffer performance issues? Seems like it will...

Answer 1

Just because something's written doesn't mean it's right. You gotta use common sense.

Answer 2

Basically, your CPU is way fast. It is crazy fast.

Your memory is crazy fast too.

Your hard-drive isn't crazy fast.

The internet is dreadfully slow (REST, RPC, etc).

node.js aims to make sure you keep your CPU busy at all times by making the slow things events. That is, instead of

var html = download_file_from_slow_internet(url);
 /* do what-ever-what-ever to that poor HTML */

you would do something like

download_file_from_slow_internet_with_an_awesome_callback(url, function(html) {
 /* do what-ever-what-ever to that poor HTML */
});

The do-what-ever-what-ever is most likely CPU bound in terms of what you want to do. Whoever made the function download_file_from_slow_internet_with_an_awesome_callback has the onus to make sure it calls your callback sometime.

In your example, an infinite loop is pure CPU. With node.js, it will stall out the entire server which is very bad. So, don't write infinite loops.

Keep in mind, "less than expert programmer" is relative. The expert programmer's knows and understand threading, locking, conditions, mutex, race conditions. If you don't use multiple threads, then you avoid all the problems. Well, why were threads introduced in the first place?

They were introduced that way because CPUs became wickedly fast and people noticed that it doesn't make sense to wait on IO. That is, you can load your data and process it at the same time. Of course, this introduced many problems. Most socket libraries introduced non-blocking IO to solve this for networking, but that introduced a fundamental different way to think about programming.

You had to use state machines, and state machines are unpleasant and extremely buggy in the hands of non-experts. If you have ever worked with low level socket state machines in C, then you know what I am talking about it.

This is where node.js comes in on a white horse. With node.js, the state machine is implicit by using closures for callbacks. It's also called continuation passing.

The idea now is that, I say do this and then pass a function in that says "when you are done, call this". Since JavaScript supports closures, it is feasible to pass state and build a state machine implicitly using the language.

node.js as it stands now is a great platform for building custom servers and building robust web applications. It is a nice place to build a service between PHP or Ruby and C.

I recommend using it for prototyping servers, and if you are worried about the performance tax of JavaScript, then you can help me with node.ocaml which is far from done, but it makes node.js look slow.