Async event-driven programming is not going away, it's probably always going to be the most performant model because incoming packets translate into interrupts and kernel mode and thread context switches are expensive.

Javascript is not going away, and has become shockingly efficient with V8.

These are both forces of nature in their own respective domains. So somebody's gonna combine them to implement an async IO reactor system in Javascript. This is Node.js, which looks to me like a pretty decent implementation of the idea.

It may not be your cuppa tea, or the best way to implement every dynamic website. It just is what it is: inevitable.

I just made it go away -- started using gevent. You can make it go away also by using an actor based language like Erlang.

If we were in the 90s you'd probably would have said C++ is not going away so that's what all web services should be written in.

> thread context switches are expensive.

Green thread context switches are pretty cheap and Erlang's processes are very light weight. I was running with 100K processes at one point all with long polling (comet style) connections. That's very cheap.

> It just is what it is: inevitable.

Yap but that wasn't his argument. I don't see (even in general) how inevitability of something turns that something into a good thing.

Actually, I work on some C++ web services today (but I wouldn't advise everyone do that :-)

Erlang's processes are very light weight

Yeah, Erlang is great that way.

I don't see (even in general) how inevitability of something turns that something into a good thing.

In this case it's inevitable precisely because there are application domains where the use of V8 Javascript is a big advantage (say you want to leverage the same code base on the client side). There are other domains where the use of the single-thread async model is a big win, particularly when a runtime environment can support you by eliminating inadvertently-blocking calls. These domains were overlapping for some capable implementers, so I think Node.js was inevitable for that reason.

That doesn't mean it's a terrible system if it doesn't turn out to be a great replacement for your favorite PHP framework.

That's like saying "assembly isn't going away, because it's the language of the CPU". Of course assembly isn't going away, but other than the Kernel and device drivers, there's not much reason to use it else where.

Coroutines are a much better way to write performant network services. In Go, when a goroutine blocks on I/O, it yields execution to other goroutines. You, the programmer, never think about it, because the platform handles it for you.

Assembly largely has gone away. It used to be that all serious PC apps were written in asm. Eventually though, C compilers and RAM improved enough to not require that. Today the only things written in asm tend to the absolute lowest-level system routines and a few hand-tuned loops.

But you might also be interested to know that MS embeds the web server in the kernel using async IO (http.sys) and that the WinHTTP client library runs async as well.

Coroutines are a much better way to write performant network services.

I agree native coroutines or CPS would better. There are better choices of development language than Javascript, too.

But it's not the tool, it's the hand and the attitude that wields the tool that determines the quality of the result.

Not only that but, unlike Node.js, Go (and Erlang) actually do scale to multiple CPUs and don't make your whole app crawl to a halt if you got some bit of code somewhere that is CPU bound.

This fantasy that Node.js supposedly scales because it is async is so laughable I don't understand how anyone ever took it seriously.

There is simply no justification to use Node.js for anything.