

Comparing Erlang and Node.js - silentbicycle
http://groups.google.com/group/erlang-programming/msg/a6fbf0414b50c8ee

======
AlexC04
While I agree that it does come across as very biased, I think it might be a
valid and valuable evaluation of some of node's current areas of weakness.

Maybe rather than taking it as flame-bait & starting a holy war over it, we
could take a deep breath and pause to remember that not only does e-Mail
always come across as more abrasive than it should, _SOME_ programmers have
that 'just sorta mildly autistic sometimes(1)' difficulty expressing
themselves in ways that take the time to address all those layers of social
nicety that people sometimes expect. (more gruff, factual communication, less
time for mediating language).

It seems to me that this is actually a really great opportunity to put a list
of things on the node.js TODO list (some of which, I think is already
available through various addins).

If Joe Amstrong is one of the creators of Erlang, he's clearly quite brilliant
as a programmer and his evaluation of node's should be taken for what it is: a
great opportunity to make node better.

(1)Not that I'm accusing the OP of that in any way ... it's just that the
"tone" isn't really relevant to the rest of the discussion.

 __ _edit_ __actually, on subsequent readings, it sounds less abraisive as
well. Even he says that he doesn't know why node was created, but does know
why Erlang was.

It kindof reminds me of the quote that was attributed to Einstein:

    
    
         "Everybody is a genius. But if you judge a fish by its 
         ability to climb a tree, it will live its whole life 
         believing that it is stupid." 
         — Albert Einstein

------
joelangeway
The reason they should be compared is because getting comfortable enough in
Javascript to stop complaining about asynchronousity causes one to think about
that aspect of programming the same way Erlang programmers do.

Erlang and Javascript are similar in that they both developed in highly
asynchronous environments. And with multiple instances of Node.js, they have
similar models of getting things done concurrently; that is, share nothing,
pass and handle messages.

Both communities seem to prefer dynamic and/or functional solutions to
programming problems rather than the sort of solutions you see in statically
typed, "object oriented" languages. Though Node.js does make use of
Javascript's object model, whereas Erlang uses very light weight processes to
separate concerns.

Erlang's syntax is "weirder" where weird means doesn't look like C. It's
semantics and facilities are much more strictly functional, though with some
discipline you could use the same semantics in Javascript, minus nice
functional features like pattern matching.

------
mcs
This seems a little bigoted. There are people working on fault tolerance, load
balancing, and other clustering mechanisms in Node. Granted, they might not
rival OTP/Mnesia, but I have great confidence that the Node community will be
able to do most of the outlined stuff in his email soon.

He did specifically say "was not designed" for these kind of applications, but
that doesn't mean the application layer can't take care of it. In fact I would
argue that with Node, you have the possibility of having greater control over
your clustering and failover logic.

------
zerosanity
Umm... apples and oranges? Erlang is a programming language. Node.js is a
javascript framework.

~~~
mononcqc
Erlang is also an entire programming environment, including a framework,
database(s), a web server, etc.

~~~
zerosanity
That would be OTP and not Erlang specifically.

~~~
mononcqc
Erlang (the language) can not run without OTP as OTP is essential to the
runtime environment of Erlang. They are the same entity, which is why the
official name is Erlang/OTP.

EDIT: an example to be more specific. The basic libraries such as the code
server (in charge of loading the Erlang modules in the VM) are packaged as
Erlang applications, which is an OTP framework construct. These parts of the
OTP framework themselves are included in the Kernel application, and written
in normal Erlang.

------
akadien
Why stop there? What about comparing Scala and Apache? Or F# and Sqlite?

~~~
jerf
Because both Erlang and Node are programming environments, and both examples
you cite are not the same thing? What makes you think that comparing them is
somehow wrong?

Strange, two other comments as I write this and both boil down to how it's not
a good comparison. What on Earth makes comparing two programming environments
unfair?

(By the way, I might as well save some time and point out that any cited
standard should _fail_ to explain why it's also wrong to compare using Node to
compare to PHP or any of the other things Node seeks to supplant for some set
of use cases.)

------
jhuckestein
This seems to be comparing apples to oranges. Node.js is a way lower-level
tool than erlang and with it come the advantages of programming close to the
next lower layer in your stack (in this case syscalls) and less potential for
error in node.js itself.

I think people are working on things similar to erlang that are built on top
of node.

~~~
jerf
"Node.js is a way lower-level tool than erlang"

What on Earth are you talking about? Erlang is a language/VM combo (it's hard
to separate the two), with nothing else between it and the OS. Node sits on
top of a VM not really intended for what it is being used for, so Node has
another layer between it and the OS. And the programming style engendered by
Node.js is the single most bug-ridden programming style I know, for all its
other features. Manually-chopped-up asynchronous callback based programming is
a terrible paradigm for code reliability.

Erlang is also unparalleled in general for its error handling. I can't even
think of another environment that even _has_ a story equivalent to Erlang's
cross-cluster supervision trees built in to the core libraries themselves, let
alone one with over a decade of refinement.

~~~
silentbicycle
I think by "lower-level" he means "having to manage resources by hand that
could be handled automatically", not "close to the OS".

~~~
jhuckestein
Thank you. Put another way, nodejs (except than the VM, granted) has less
magic than erlang.

At least it seems that way to me having looked at erlang for no more than a
few hours and using nodejs every day, so take this with a grain of salt :)

~~~
silentbicycle
It wasn't a compliment. :)

Erlang has a scheduler which automatically makes intelligent tuning based on
dataflow in ways that are realistically impossible for anybody to do managing
callbacks by hand. They aren't "magic", they just take into account a fairly
simple cost-per-action model ("reductions") and whether a process is active,
has messages to process, or is blocking with an empty mailbox.

------
knieveltech
for the TL;DR crowd: Author expresses ignorance regarding node.js design
considerations then provides a long list of erlang features.

A meaningful discussion of node.js capabilities appears to be entirely absent.
So either the HN title is flamebait or the author's biases glow in the dark.
Choose your adventure.

~~~
silentbicycle
The post's author was one of the primary Erlang authors, in case it's not
clear. I'd expect his biases to be obvious.

~~~
knieveltech
That doesn't change the contents of the article. Have a nice day.

