I agree that the Node.js model of concurrency is one of the weakest models out there. CPS is for the compiler writer, not for the programmer.
The underlying problem is that sequential languages do bad when you "bolt on" concurrency to them - unless said language is expressive enough to make it bearable (Haskell and some MLs come to mind). For all other language, you are just frankensteining your system.
The reactor-model, of which Twisted, Node.js and a couple of like systems are built around has one advantage: It is fairly easy to get going. It is by far the simplest model you can get bolted onto a system with relative ease. The crux of the problem is that we have a lot of sequentially oriented programmers who suddenly need to do full concurrency. This is the first attempt.
To a professional Erlang programmer like me, it does look rather odd that one would hail a reactor model as being anything decent to work with. There are other concurrent calculi out there, which may be better than what Erlang provides, but none of them worries about callbacks in the style of Node.
I have a hunch the kid must be dragged screaming into the concurrency shop.
> The underlying problem is that sequential languages do bad when you "bolt on" concurrency to them - unless said language is expressive enough to make it bearable
Really?
I'm not familiar with Erlang, but have you tried Go? Concurrency fits seamlessly into the language.
Go is not sequential, but concurrent. It has built-in primitives for handling concurrency, witness the `go` keyword. It also has special syntax for doing selective receive over channels, which in turn means that the concurrency of that language is definitely not "bolted on" in the sense I meant.
Perhaps you are confusing my definition of "sequential" with yours. I tend to use "sequential" as the opposite of "concurrent" like I have another, orthogonal, axis for "serial"/"parallel". So you can be serial/concurrent (Node.js is close to this. So is a 4.4BSD OS without any SMP support). And you can be sequential/parallel (GPUs is my preferred example).
The underlying problem is that sequential languages do bad when you "bolt on" concurrency to them - unless said language is expressive enough to make it bearable (Haskell and some MLs come to mind). For all other language, you are just frankensteining your system.
The reactor-model, of which Twisted, Node.js and a couple of like systems are built around has one advantage: It is fairly easy to get going. It is by far the simplest model you can get bolted onto a system with relative ease. The crux of the problem is that we have a lot of sequentially oriented programmers who suddenly need to do full concurrency. This is the first attempt.
To a professional Erlang programmer like me, it does look rather odd that one would hail a reactor model as being anything decent to work with. There are other concurrent calculi out there, which may be better than what Erlang provides, but none of them worries about callbacks in the style of Node.
I have a hunch the kid must be dragged screaming into the concurrency shop.