Why is Node async?

why.md

Why is Node async?

• Asynchronous code is how you write low-resource, high-concurrency servers. See http://www.kegel.com/c10k.html.
• Node embracing async from the get-go means that servers are low-resource, high-concurrency by default.
• Async + JavaScript = Perfect fit for an event loop.
• When it comes to threads vs event-loop, there are times when either are advantageous.
  • But there are things very hard or impossible to do with threads.
  • WebSockets are difficult to do properly with threads. That's one example where non-blocking IO (async) has a major advantage.
  • RAM usage is another factor, especially when we're talking about the physical hardware required to run your application, which translates to real dollars.
  • It depends on your application in the end:
    • If you're mostly waiting on IO the entire time, an event loop shines.
    • If you're doing CPU-intensive tasks like calculating prime numbers, then you want threads.
• Evented programming solves a different problem then progressive programming. It is not inherently better, just different.

@russfrank you are forgetting about spawning new threads, joining them, dealing with lock contention, because locking doesn't really work, the whole bunch of synchronization strategies to replace locking, cache lines, thread local memory, affinity and so on.
Multithreaded programming is too complex for most people and should be used in one case only - to implement actor model :)

@zzzcpan absolutely, I was grossly oversimplifying (for brevity's sake).

@russfrank That is not a binary choice. For example, you can use a cooperative threading model (by putting everything under a single lock) which has the big advantage that you don't need to think about concurrency within your code fragments, and has the same disadvantage as node.js' model: you only use one core. We've come there (in a proprietary setting): We used the same asynchronous, callback-driven programming model to do I/O multiplexing, and at some point doing everything in callbacks pointing to the next one becomes just too tedious for some things. (That was in C, compared to that, node.js is much simpler to handle because of garbage collection, and because of true lexical scoping.)

At some time we added the capability to start extra threads (cooperative ones) to be able to do a loop as, well, a loop instead of a data structure with a counter and proper next callback selection. The thread's stack serves as implicit state; and this turned out to be quite helpful.

Only we did it back when single-core was still the norm; node.js is a bit across the grain for current architectures in that regard.

But as we now know, loops are bad, and higher-order functions are good, so there should be a way to emulate such looping with, like, map(), and when we assume that the function argument to map needs to be not a simple function, but one that gets the input value and a result callback, there should be some async_map(fct,list,rescb) to be used like async_map (function (v, cb) { cb (2 * v); }, [1, 2, 3, 4], result_receiver).