Erlang vs node.js
journal.dedasys.com
journal.dedasys.com
Pattern matching is another big part of it, but several other languages did pattern matching first.
Likewise, pattern matching completely eliminates complex layering of nested 'if' statements, and is an alternative solution to the kinds of problems typically solved with polymorphic dispatch in OO languages.
Every day with our production systems we check the live production logs to identify defects that we try and remove.
The second key point about 'let it crash' is that with OTP your system is always macro stable. Even if every function is only a stub and every stub contains exit(bleh) and always fails at a micro level, your system is always macro stable - the gift that keeps on giving!
I recommend reading Joe Armstrong's thesis: http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf
Your comparison of erlang and node.js is a reasonable exercise. However, I think the most valuable thing to get out of the exercise is that node is not really in competition with erlang. I think its more interesting to look at how node can be used to handle non-blocking http requests (and compare that to rails/django) and write your server code in the same language as your client side code.
The one issue I have with nodejs at the moment is that since it is nonblocking, when you call riak and ask for data nodejs will move on and continue execution when what you really wanted is that the next execution use values returned by riak. The main way to do this is to chain your calls so you basically nest your next call inside your current call. This can get sloppy. Apparently there is no built in method to wait on results. There were promisses but they were removed. Now there are some add-on libs like Step which I'm still trying to grok cause my js/node-fu is not up to snuff.
Other than that, nodejs makes it ridiculously easy to start hacking away at all kinds of interesting stuff. anything that has to do with sockets or at a higher level, http interaction. Take a look at a post from yesterday to see just how easy, http://news.ycombinator.com/item?id=1301272.
Because if you do that, the whole value proposition of Node.js completely falls apart. Now you've blocked the entire system waiting for your result. You might as well be programming in any other blocking language (all of which have Node.js-like libraries, by the way). This is what you get when you try to build concurrency on top of a language fundamentally built on non-concurrent primitives.
Consider going pure Erlang, which does work exactly the way you are looking for it to work. You call a function, which passes around messages and gets the result for you, and the result comes back along the function call, and all the not-blocking is handled by the Erlang VM, totally transparently. (Oh, and you get OTP, which if your server is non-trivial you really need, even if you don't know it yet. And transparent multi-proc support, easy clustering support, couple of other things that Node.js may someday have with great, great, great, great effort and even then they'll still be hacks unless they fundamentally change Javascript to basically become Erlang.)
Node.js is probably going to end up being a huge argument in favor of Erlang, because I suspect you will not be the last to encounter this problem in Node.js. It is absolutely inevitable that any significant application trying to be built in Node.js must collapse into a mess of callbacks and closures that will be very difficult to trace through. That's how it's designed. Any attempt to hack around this will have its own issues with gross hacks or difficulties with branching.
I really don't see Node.js being a success in the long term. It is built on a foundation that is not up to the task. Building a really big Node.js app would be a nightmare, and the reasons why are not going to come out of the foundation easily, if at all.
Here, let me give you an example with my work system I'm building. I have a single function which fans out an RPC request to multiple systems, collates the results with a timeout, and returns the results to the caller (or optionally calls some other code at the end, in the handler process). The initiator does not set up a callback, it just makes a call. The fanout mechanism does not set up a weird time-sliced mechanism to send out the calls, it just does it. There's some callbacks for handling whether it gets an error or a result coming back, which is pretty normal, and note, I don't have to contort around whether those callbacks may themselves want to do something over the network, they're just simple, one-layer callbacks that I would have implemented as callbacks in any language. (Imagine how you'd do that in an event-based system, deal with a response callback that may itself want to do a callback chain. It's perfectly feasible, I can easily see how to do it, but I sure as hell don't want to actually try to code it.) In Erlang, this is very natural; a function call that behind the scenes spawns a process that does what it says and says what it does, and works quite well. In an event-based system, this simple bit of functionality would be a callback explosion. I count a dozen, easily, and it would probably double if I really tried to do it. And that's not my whole system, either, it's just one bit. The multiplicative complexity explosion that occurs with Node.js's approach just isn't feasible.
(Note Erlang handles "events" quite well, indeed, it's a native paradigm for many parts of the system; what it doesn't have is the multiplicative explosion of manually-created event handlers caused by offloading the scheduling onto the programmer.)
Check out:
http://github.com/rsms/node-promise
http://github.com/creationix/step
http://github.com/creationix/do
Did the value proposition of node fall apart?
.
re: multi-proc support
From www.nodejs.org architecture design statement:
"But what about multiple-processor concurrency? 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."
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.)
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 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.]
I can't wait for lfe to mature.
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.)
Indeed it can. I am a fan of flow-js however. It has really helped me to avoid getting sloppy in Node.js.
I know node.js isn't "gunning" for Erlang but for any language out there: Spend some quality time integrating fault tolerance deep within the language and you'll give Erlang a run for its money. Other than this, there isn't too much that makes Erlang special (sure fast message passing, fast process creation, etc. but the fault tolerance is whats really special)
Something wrong with HN.
Also, calling Erlang "designed from scratch" is a bit odd given that it actually evolved out of some Prolog system they'd built, something that is quite visible in the syntax.
It stopped mattering that Erlang evolved from a Prolog prototype when it ceased running on top of SICStus's IO primitives. (FWIW, Prolog is a really cool language, particularly for prototyping. Event-driven, IO-heavy stuff is just not its strong point. The pattern matching stuff in Erlang comes straight from Prolog, though.)
In my mind this is a good thing because more people will realize some problems are too painful to solve in Node.js and they will take a hard look at Erlang. Or they'll get sick of the convoluted syntax hoop-jumping and they'll take a hard look at a Lisp.
I find JavaScript beautiful in a sense because in a very roundabout way it's pulling people towards more advanced PLs.
Pushing a simple solution to its limits is how people evolve to the next thing.
It's the ultimate example of the “When you have a hammer, everything looks like a nail” phenomenon.
Is it the best alternative?
Erlang, as the article states, has some good things going for it; it's better than anything else that I know of for several categories of tasks. The problem is that other things are catching up, and while they may not be "as good", people can and will pick them if they are "good enough" and have other qualities that make them a good choice, such as being easier to learn.
Your comment to me comes across along the same lines of the people thinking digital photography would never surpass the quality of regular film. Maybe node.js won't be the one to catch up and pass Erlang, but my gut feeling is that something will. Scala, maybe?
At least Scala is in a similar category. Node.js is basically a bolt-on solution. It doesn't even actually have a comparable threading model, it just has a comfortably familiar one.
This project will be the first time many Javascript programmers will brush up against topics of scale such as these, and speaking as one, I'm definitely going to focus on Erlang to explore these problems. (but still play around with Node.js on the side ;)