4 ms·

Why is non-blocking IO radical? Tons of libraries and frameworks offered it much before node, including twisted, Java's NIO, and the entire System.Net namespace

Why is non-blocking IO radical? Tons of libraries and frameworks offered it much before node, including twisted, Java's NIO, and the entire System.Net namespace in .NET. Other than that, surprisingly sensible advice.

jbooth 14y ago
It's not radical, it's just occasionally more confusing than blocking io to implement, and doesn't really have any performance benefits in the multicore world. I'm actually using node for a side project right now as part of re-learning web development (been back-end the last few years), and using javascript as a client language, server language, and db query language via mongo is a neat environment. Also, npm rocks. But don't listen to anyone who tells you they use node+mongo to handle their WEB SCALE PERFORMANCE. If they really had that problem, they'd be better off using the java ecosystem or, if they really wanted to go hardcore, using a lot of C. But Java's unfashionable and C's ridiculous to write a web app.
- mcantelon 14y ago
  >doesn't really have any performance benefits in the multicore world AFAIK, Node's cluster API, which can spawn workers for each of a machine's cores, will, when delegating requests to a worker, factor in OS-level core utilization info.
  - jbooth 14y ago
    From what I could tell, that spawns actual child processes and communicates with them over pipes. Fine from an architectural standpoint, but a penalty compared to shared memory from a performance standpoint. And it still has the problem of a single heavy CPU request on a given worker blocking all the requests behind it on that worker. Again, I'm not saying node sucks, I'm using it and I like it. I'm just saying if you really need to crank out performance, use java.util.concurrent, or maybe Go. They both offer event-driven i/o if you really want it, and have better threading models.
SkyMarshal 14y ago
Not only is node non-blocking but all of its libraries are, unlike Python, Java, and .NET. I wouldn't call that radical per se, but distinguishing yes.
- jerf 14y ago
  It was radical when Erlang did it. Nowadays it is still moderately distinguishing, but that distinction is definitely fading rapidly.

jbooth 14y ago

It's not radical, it's just occasionally more confusing than blocking io to implement, and doesn't really have any performance benefits in the multicore world. I'm actually using node for a side project right now as part of re-learning web development (been back-end the last few years), and using javascript as a client language, server language, and db query language via mongo is a neat environment. Also, npm rocks. But don't listen to anyone who tells you they use node+mongo to handle their WEB SCALE PERFORMANCE. If they really had that problem, they'd be better off using the java ecosystem or, if they really wanted to go hardcore, using a lot of C. But Java's unfashionable and C's ridiculous to write a web app.

mcantelon 14y ago
>doesn't really have any performance benefits in the multicore world AFAIK, Node's cluster API, which can spawn workers for each of a machine's cores, will, when delegating requests to a worker, factor in OS-level core utilization info.
- jbooth 14y ago
  From what I could tell, that spawns actual child processes and communicates with them over pipes. Fine from an architectural standpoint, but a penalty compared to shared memory from a performance standpoint. And it still has the problem of a single heavy CPU request on a given worker blocking all the requests behind it on that worker. Again, I'm not saying node sucks, I'm using it and I like it. I'm just saying if you really need to crank out performance, use java.util.concurrent, or maybe Go. They both offer event-driven i/o if you really want it, and have better threading models.

SkyMarshal 14y ago

Not only is node non-blocking but all of its libraries are, unlike Python, Java, and .NET. I wouldn't call that radical per se, but distinguishing yes.

jerf 14y ago
It was radical when Erlang did it. Nowadays it is still moderately distinguishing, but that distinction is definitely fading rapidly.