Erlang vs node.js

http://journal.dedasys.com/2010/04/29/erlang-vs-node-js

by davidw • 16 years ago

32 31 16 years ago

journal.dedasys.com

siculars• 16 years ago

Oddly enough, I just started a project that uses nodejs to access riak which is built on erlang. In addition to accessing data natively via erlang, riak speaks http and now protobuffers. Currently I have node.js speak to riak over http and I may change this in the future to use pb instead.

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.

jerf4• 16 years ago

"Apparently there is no built in method to wait on results. There were promisses but they were removed."

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.)

Rauchg• 16 years ago

re: promises/chaining

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."

BrianHammond• 16 years ago

"This can get sloppy."

Indeed it can. I am a fan of flow-js however. It has really helped me to avoid getting sloppy in Node.js.

http://github.com/willconant/flow-js

signa11• 16 years ago

would be nice if the any language that tries to imitate erlang does whatever is mentioned here: http://ulf.wiger.net/weblog/2008/02/06/what-is-erlang-style-... nicely...

rubyrescue• 16 years ago

supervisors and process hierarchy is missing from his list of things erlang does really well (he mentions fault tolerance but ties it to distributed computing). for node.js to implement the message passing/process linking that erlang has would be difficult; and it would be easy for node to then lose some of what makes it so interesting.

davidw8• 16 years ago

I was trying to list practical things - what category would you put the process stuff under? In other words: process supervisors are not really an end unto themselves, they're part of what makes Erlang good at X.

silentbicycle3• 16 years ago

The process hierarchy is a big part of what makes coding in a "let it crash" style possible, and AFAIK it's fairly unique to Erlang (though some other languages have copied it).

Pattern matching is another big part of it, but several other languages did pattern matching first.

jhancock• 16 years ago

"let is crash" is critical to the erlang approach. erlang's approach to concurrency fails without it.

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.

c00p3r• 16 years ago

Trying to compare a mature, designed from scratch, battle-tested enterprise solution that powers Eriksson's switches with v8 (which is so good to be true) + libevent?

Something wrong with HN.

davidw8• 16 years ago

They get used for some of the same things, so it makes sense to compare them, just as we might compare Java (which also comes from a big company) web stuff with Ruby on Rails. Why don't you point out actual problems in the comparison rather than whine?

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.

silentbicycle3• 16 years ago

By "designed from scratch", he/she probably means that Erlang's asynchrony is thoroughly integrated, while node.js tries to retrofit such a model onto JS, and still has operations that will cause the whole system to block.

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.)

swannodette• 16 years ago

I think the article is trying to point out that for simpler problems you no longer have to immediately reach for something as robust as Erlang, Node.js might do.

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.

KirinDave3• 16 years ago

I think it's sad that people are so afraid of trying new languages and investing a bit of their time diversifying that Node.js looks like a viable alternative to Erlang, ever.

It's the ultimate example of the “When you have a hammer, everything looks like a nail” phenomenon.

HidingInABunker• 16 years ago

I have to agree, speaking as a programmer just starting to get comfortable in Javascript with little to no experience in more established functional programming languages. The initial wow factor of having javascript on the server and client side quickly gave way to all the reasons to use alternative approaches.

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 ;)

mitchellh• 16 years ago

While concurrency is a strong feature of Erlang, Erlang's _killer_ feature is fault tolerance. For any language to be able to be sufficiently compared to Erlang, it must provide fault tolerance support (either through the language or through a standard library).

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)

davidw8• 16 years ago

The scheduler and awareness of its importance is not something you can slap on to any old language and its runtime, IMO. I mean, you could build one into another language, but the mentality of keeping the core system non-blocking is very central to Erlang.

evgen• 16 years ago

What I am really waiting/hoping for is someone to take the erlang_js hooks that the Basho guys created and use them to provide a node.js interface that is actually run by erlang. The erlang side chops up the js at the various node.js API interface points and then handles everything that node.js is supposed to provide, but does it using the power of erlang to run the show. Instead of being its own event loop node.js just becomes an API that the erlang side provides for the js code.

Erlang vs node.js

Related Stories