I have been doing async-style programming for a while and still consider it terrible. I had to do it because at the time there were no better alternatives given my constraints. I could have told you then it was a bloody mess when evaluating it and I can tell you the same now. In other words it seems "accessible to brain" and a "better platform" can be independent.
I've never jumped on the Node bandwagon either, because I detest Javascript, but...Shouldn't async-style programming be fairly familiar to Javascript developers? At least those who have ever made an AJAX app?
It seems like it was a paradigm shift for the author, but I wonder if it actually is for most people who Node is primarily targeted towards: those who like and regularly use Javascript.
On the client you have callbacks every time an object has an event handler. It's not just AJAX. And yes, anyone familiar with client side JS should understand and be using callbacks everywhere.
It's not that async is hard, it's that callback-based frameworks like node.js force the programmer to structure their code in an entirely different (and more verbose!) way to what they would writing synchronous code. It doesn't help that the shortest way of declaring a function in Javascript is function(){...};
Look at coroutine-based frameworks like gevent if you want to see what easy async looks like. You'll still have to remember you're writing async code, but instead of do_lots_of_io(function(){wrap_up_afterwards();}); you can just do_lots_of_io();wrap_up_afterwards();. It makes code infinitely more readable.
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.
> Async event-driven programming is not going away,
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.
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.
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.
> 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.
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.
> 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.
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.
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.
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.
