Yup, exactly what I was expecting to see. Not even close to matching Erlang. You're still chopping up your code pretty grotesquely, and you're going to rapidly find out that while that made a few things you were used to doing work well, when you want to take the next step of logical flow that stuff is going to stick in your craw. It's a fairly normal abstraction, in that for the price of making one thing easy it's going to make other things harder.
I implemented that for myself in browser-side javascript years ago, so I actually do know what I'm talking about. (All 3 are really the same basic approach, and it's the only basic approach there is.) It's a little more convenient than the alternative, but it only lightly brushes over a couple of the pointy bits of this approach, and leaves quite a lot of the rest of them still in your face.
" Threads are necessary to scale programs to multi-core computers. Processes are necessary to scale to multi-core computers, not memory-sharing threads. The fundamentals of scalable systems are fast networking and non-blocking design—the rest is message passing. In future versions, Node will be able to fork new processes (using the Web Workers API ), but this is something that fits well into the current design."
I don't have to do anything in Erlang to get multi-processor support. I just run the VM. Rationalizations about why multi-process is hard and it's OK that we don't have it, we don't really need it are irrelevant, I have it in hand. And if you're not familiar with Erlang, you may need to know what it's definition of "process" is: An "Erlang process" is basically a thread, but has process-like isolation from other threads, which is where the word "process" comes in. Erlang essentially automatically runs things in the most-optimized thread-pooling system you've ever seen, and I don't have to think about it. Are you going to be able to spawn off a few ten thousand Web Workers without worrying about the resource usage? (Or hundred thousands? ... or millions?) I'd be surprised. It might be possible, but I'd be surprised.
Bear in mind I'm coming at this as a near-decade user of Javascript and a multi-year professional user of Erlang. I am not unfamiliar with the languages. You can not match Erlang in Javascript, not even with web workers. You can smooth things around, but all you'll get is a yet-more beguiling slide into complexity if you try to do anything at a large scale. (You'd honestly be better off if you hit the limits of Node.js sooner, rather than later.)
Part of my point in the article is that, while node.js is not as good as Erlang, it may be "good enough" for a great many web/network things where Erlang might be considered for its strengths. It's sort of a 'disruptive innovation' situation.
And that's fine. I rather expect you're totally correct in terms of describing what's going to actually happen; Erlang is a non-Algol language and while that's slowly becoming more respectable we've got a long ways to go before it is considered as anything but a negative by the vast bulk of programmers.
It's just that I've actually been down this path a few times with other apps and I feel a responsibility to raise a flag and point out that all applications tend to grow and building with a base that will cause your code to explode in complexity as you tend to grow is not the best plan, but I also know that this is very firmly in the class of things people have to learn for themselves. And the cute little proxies and such aren't bad, it's surprisingly hard to guarantee your app stays in the class of "cute little".
One of my other work apps is actually something built on the Perl wrapper around glib, using its event library, because I ended up having no choice for other reasons (was wrapping a C library and local political concerns wrote Erlang out). And ye gods, the mess, the mess, and the bugs, the bugs. Event chains four or five layers deep in callbacks (multistage login processes being wrapped by other multistage login processes, oi). It's the same exact organizational pattern as Node.js, and it just doesn't scale, even when you know what you're doing. Every trick I know brought to bear to simplify and improve (plugins, simulated generators with goto at a couple points, equivalents to the func chaining hack linked above), but you just can't overcome the weakness of the primitives.
I read your comments on node.js with interest, but I object to being called an 'algol-like' programmer just because I can't deal with erlang.
I work with haskell and lisp just fine, and I can find my way around monads, closures and continuations. It's just the prolog syntax I can't get past.
That and a million little niggles. How do you quit from erl, anyway? Is there a faster way than C-g C-c a? [update: argh, C-\ has thwarted me for years. http://www.erlang.org/faq/getting_started.html It's hard to describe why - it's always obvious in hindsight - but erlang has been extremely painful to learn. I have no trouble with documentation and man pages, but with erlang it seems there's always one more place to check.]
Sorry, I only saw this much later. When I say that Erlang is non-Algol, it is not a criticism of a given programmer. It is a criticism of the industry as a whole, that nothing that looks like Algol can succeed anytime soon.
Erlang is full of frustrating quirks and in other contexts you can find me complaining about them and how they don't all go away when you get used to them. (; , . is just plain BS.)
Yup, exactly what I was expecting to see. Not even close to matching Erlang. You're still chopping up your code pretty grotesquely, and you're going to rapidly find out that while that made a few things you were used to doing work well, when you want to take the next step of logical flow that stuff is going to stick in your craw. It's a fairly normal abstraction, in that for the price of making one thing easy it's going to make other things harder.
I implemented that for myself in browser-side javascript years ago, so I actually do know what I'm talking about. (All 3 are really the same basic approach, and it's the only basic approach there is.) It's a little more convenient than the alternative, but it only lightly brushes over a couple of the pointy bits of this approach, and leaves quite a lot of the rest of them still in your face.
" Threads are necessary to scale programs to multi-core computers. Processes are necessary to scale to multi-core computers, not memory-sharing threads. The fundamentals of scalable systems are fast networking and non-blocking design—the rest is message passing. In future versions, Node will be able to fork new processes (using the Web Workers API ), but this is something that fits well into the current design."
I don't have to do anything in Erlang to get multi-processor support. I just run the VM. Rationalizations about why multi-process is hard and it's OK that we don't have it, we don't really need it are irrelevant, I have it in hand. And if you're not familiar with Erlang, you may need to know what it's definition of "process" is: An "Erlang process" is basically a thread, but has process-like isolation from other threads, which is where the word "process" comes in. Erlang essentially automatically runs things in the most-optimized thread-pooling system you've ever seen, and I don't have to think about it. Are you going to be able to spawn off a few ten thousand Web Workers without worrying about the resource usage? (Or hundred thousands? ... or millions?) I'd be surprised. It might be possible, but I'd be surprised.
Bear in mind I'm coming at this as a near-decade user of Javascript and a multi-year professional user of Erlang. I am not unfamiliar with the languages. You can not match Erlang in Javascript, not even with web workers. You can smooth things around, but all you'll get is a yet-more beguiling slide into complexity if you try to do anything at a large scale. (You'd honestly be better off if you hit the limits of Node.js sooner, rather than later.)