[erlang-questions] node.js compared to erlang
Pablo Platt
I'm using erlang and I love it.
I'm not trying to create an argument but to better understand the power of
erlang.
In what areas erlang dominates and what areas will you consider using node.js?
For example, would you consider building something like rabbitmq or ejabberd in
node.js?
Or maybe you'll use node.js just for a simple single chat room but erlang for
anything complicated than that.
Are there a fundamental differences in performance or stability or use in
distributed systems?
Ulf Wiger commented on the comparison of erlang and node.js
and said that erlang solves the problem of non blocking functions which might be
very hard for other languages.
http://journal.dedasys.com/2010/04/29/erlang-vs-node-js
Thanks
Max Lapshin
> Hi
>
> I'm using erlang and I love it.
> I'm not trying to create an argument but to better understand the power of
> erlang.
>
> In what areas erlang dominates and what areas will you consider using node.js?
I can't imagine area to use node.js? Awful language, lack of good and
tested libraries. I can't see a reason to prefer ruby or python to
Javascript. It doesn't solve any problem, that erlang solves.
________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-questio...@erlang.org
Rapsey
> If you're proficient in Erlang, I don't see a single advantage in using
node.js for anything.
Sergej
>
>
Joe Armstrong
I don't know why node.js ws desiged - I guess so you could write servers
in js.
Erlang was designed for building soft real-time fault-tolerant systems
that could be
upgraded without taking them out of service. These design criteria led
to erlang features like:
- fast per/process garbage collection
- ability to change code on-the-fly (ie the module reload stuff, with the
ability to run old and new module code at the same time)
- several orthogonal error detection mechanisms (catch-throw/links/ ...)
- cross platform error detection and recovery
(ie to make something fault tolerant needs at least 2 machines,
think the case when one machine crashes - the second machine must be
able to take over)
In the erlang system there is quite a lot going on behind the scenes to make
sure this all happens without the user being aware of it - to first
approximation
you can spread processes and database tables over multiple nodes and
it will behave in a reasonable manner ...
I don't think things like have any correspondence in node.js - I guess if
an entire node.js node crashes the user would not expect another node
to take over
in a seamless manner.
The fun stuff in Erlang has to do with how the failure model interacts with
code changing, moving code around, upgrading code without stopping the system
and so on - these characteristics are extremely important if you want to
build a 24x7 system with zero down time - less so if you just want to serve up
pages as fast as possible and don't care if you take the system out of service
for upgrades or errors.
Erlang was designed for building fault-tolerant systems - node.js was not
Cheers
/Joe
On Sun, Oct 3, 2010 at 5:00 PM, Pablo Platt <pablo...@yahoo.com> wrote:
________________________________________________________________
Kaiduan Xie
- cross platform error detection and recovery
(i.e. to make something fault tolerant needs at least 2 machines,
think the case when one machine crashes - the second machine must be
able to take over)
Can you give us a real-life example on this point? I have not seen an
illustration for this in your book, and in Francesco/Simon's book. The
upcoming Erlang/OTP-In-Action also does not touch this area. OTP
supervisor structure seems focusing on re-start process on local
machine.
Of course Mnesia is a good example. I would like to see a code example
from other projects too.
Best regards,
/Kaiduan
Moritz Ulrich
http://www.erlang.org/doc/design_principles/distributed_applications.html
(It's an application-, not a supervisor-feature)
--
Moritz Ulrich
Programmer, Student, Almost normal Guy
http://www.google.com/profiles/ulrich.moritz
BB5F086F-C798-41D5-B742-494C1E9677E8
Joe Armstrong
>
> - cross platform error detection and recovery
> (i.e. to make something fault tolerant needs at least 2 machines,
> think the case when one machine crashes - the second machine must be
> able to take over)
>
> Can you give us a real-life example on this point? I have not seen an
> illustration for this in your book, and in Francesco/Simon's book.
When you spawn_link a process on a remote node it
behaves just like a local process (apart from latency) - if the entire node or
machine dies you'll get an exit. You can arrange that proceses in a supervisor
tree are on remote nodes and thus try to restart them or restart them
on a different
node.
In the books I guess we don't make the point strongly enough, but the
link between processes is something that can exist across machine boundaries.
So whatever applies on one machine (regarding error recovery) should work
across machine boundaries.
The process architectures on single nodes and in distributed systems are
broadly similar with the exception that entire groups of processes will die
if a node dies, even if they are not linked together.
Most real life examples need only pretty simple things like replicated
data in mnesia and a cross machine takeover mechanism.
> The
> upcoming Erlang/OTP-In-Action also does not touch this area. OTP
> supervisor structure seems focusing on re-start process on local
> machine.
But there is no need why this should be so - supervisor structures
could cross machine boundaries if necessary.
The essential point is that spawn_link works over machine boundaries
delivering exit signals across machine boundaries if processes die.
The supervisors are just wrappers that encapsulate this mechanism in a
convenient way.
/Joe
Masklinn
>
> I don't know why node.js ws desiged - I guess so you could write servers
> in js.
Hassy Veldstra
V8 is a good JS engine, and Node.js is an interesting project and it
can be a good platform for writing a certain kind of servers when you
already know Javascript, but you don't get fault-tolerance,
distribution, the amazing OTP libraries, and many other things.
Node.js has good momentum (there's a lot of Javascript programmers out
there). I think it will end up attracting more people to Erlang.
Tony Arcieri
> In what areas erlang dominates and what areas will you consider using
> node.js?
> For example, would you consider building something like rabbitmq or
> ejabberd in
> node.js?
Node makes you write everything in a fully asynchronous, event-driven
manner, an upside down world of callbacks and inverted control. Erlang
provides abstractions like processes and messages which allow things to
appear synchronous when in fact they're fully asynchronous underneath.
Erlang processes will hang on to state for you, so you can process incoming
requests as a combination of the request and the current state, rather than
having to backtrack and figure out what state you're in from a centralized
I/O handler.
Node may be nice for smaller servers that handle more trivial I/O problems.
Erlang is better suited for building larger systems which are factored apart
into several different processes.
--
Tony Arcieri
Medioh! A Kudelski Brand
Raoul Duke
> On Sun, Oct 3, 2010 at 9:00 AM, Pablo Platt <pablo...@yahoo.com> wrote:
>> In what areas erlang dominates and what areas will you consider using
>> node.js?
> Erlang is better suited for building larger systems which are factored apart
> into several different processes.
fundamentally, as a narrow-minded, often statically-typed-bigoted,
jerk, i don't understand how anybody could see javascript and think
"this is *so good* we *have* to extend its use to all other areas of
programming endeavour!"
i mean at least i get Dialyzer, QuickCheck in the Erlang world. :-)
yeah, ok, all languages have problems, and javascript gets blamed for
issues that are really in the DOM and the individual browsers, but
even leaving those things aside, i still don't like it. :-)
apologies, end of rant, shutting up.
sincerely.
Tony Arcieri
> fundamentally, as a narrow-minded, often statically-typed-bigoted,
> jerk, i don't understand how anybody could see javascript and think
> "this is *so good* we *have* to extend its use to all other areas of
> programming endeavour!"
The interesting thing about JavaScript is people are used to using it in an
asynchronous, callback-driven manner where time is spent outside the
interpreter doing other things, namely the web browser waiting on events for
the JavaScript interpreter. Because of this, JavaScript is a "natural"
environment for the sort of asynchronous, callback-driven programming that
Node offers.
I am not a fan of JavaScript as a language in general, though.
Joe Armstrong
and apache" or
"erlang and node.js"
It's the difference between having one web server and a few hundred thousand.
An erlang web server will spawn a single process per connection - each
process is
in itself a complete little web server - if you are running mochiweb
with 100K chat sessions
you really have 100K webservers on your machine - not one. If one of these web
servers crashes who cares.
If Apache crashes it's a big deal - if an erlang process representing
a web server crashes it's
not a big deal. Erlang itself crashing (or yaws etc) is more akin to
an entire machine failure.
Think of an erlang system as providing hundreds of thousands of tiny
isolated web servers.
This argument is not entirely true and should not be pushed to far, but it does
illustrate an essential difference in philosophy.
/Joe
________________________________________________________________
Max Lapshin
hundreds of thousands of legacy code lines. It is about management
resources in runtime. Best way to manage resources in runtime.
David Mercer
Javascript and Erlang. I had been writing full-blown server-side Javascript
applications for 5 or 6 years until I discovered Erlang in '07. What had
attracted me to Javascript was the ability to replace code on the fly (for
instance, by loading the file into a string and eval-ing it). For
distribution (the application was distributed over about 20 machines
internally with about 100 additional smaller-scale remote servers
communicating with the central hub), I used the file system and TCP (and
HTTP for negotiating across firewalls), depending on the requirements. (I
had also originally used MSMQ, but we phased that out over time in favor of
more expedient methods that we developed ourselves.) The end result was a
less robust version of an Erlang application, that worked pretty well. We
had hot code loading, and redundancy gave us the fault-tolerance we
required.
When I discovered Erlang in 2007 (not sure why it took me that long), I
immediately recognized that Erlang was built to handle all the problems we
had written around, but it had a longer history and was certainly better at
it. We had required so much of our redundancy (20 machines running about 7
processes each) not only to handle the load, but also to handle failures.
Windows Script Host, which was our Javascript engine, is not as stable as
you might think, and seemed to suffer from memory leaks which manifested
itself over time. With 20 machines times 7 processes per machine and an
MTBF of, say, a week, we had 10 or 20 failures a day (which were
automatically handled). Honestly, the surprise for us was that WSH
performed as well as it did. We had originally written our application in
Javascript/WSH as a prototype, intending to rewrite in C/C++/Java/something
else when we had completed our proof of concept. But as it turned out,
processing speed wasn't really an issue for us -- network latency was
usually the limiting issue, not CPU. However, it was surprising to us that
WSH could, at times, run for days or weeks, processing millions of
transactions before failing. WSH's multi-threading capabilities are
nonexistent, and I tried various hacks to coax it into running multiple
threads, but they tended to cause other problems (as you can imagine), so I
wrote my own scheduler that time-sliced between various tasks. (It was
actually a heap-based priority queue.) We isolated blocking operations (the
main issue we had with blocking was that some asynchronous SQL queries were
not working right, so we had to do them synchronously) in their own process
so that they wouldn't block other tasks.
However, Erlang does everything we wrote, and it does it better. Having
written an equivalent system in a non-Erlang language, I really appreciate
all the tools Erlang gives you to create manageable distributed server-side
applications. Besides the interprocess messaging and hot code-loading, OTP
is an excellent way of thinking about and framework for building your
fault-tolerant servers. I did not know about Erlang and OTP when I started
writing server-side Javascript, but if I had, I would have begun by
rewriting Erlang and OTP (e.g., gen_server) in Javascript. It would have
created a much better architecture, though it is not clear why I would write
such a system in Javascript if I knew about Erlang. Node.js is only a small
step up from WSH in that it is more portable and has better support for
multi-tasking. I suspect you would find yourself rewriting a lot of
Erlang/OTP in Javascript if you decided to build in Node.js your own
server-side applications.
That being said, as an old Javascript warrior myself, I'd be interested to
hear how it goes. I, too, have considered trying out Node.js as my New
Favorite Platform(TM), but haven't yet had the need. Today, I haven't done
much programming in Javascript in a couple of years, but I gotta admit, as a
language, it is very highly capable. I daresay, there was a time, 5-10
years ago, when I considered myself one of the best Javascript programmers
in the world, and I would sometimes log into Experts Exchange or somewhere
like that to help out, only to be dismayed that the Javascript questions
were not about the language Javascript, but about manipulating the DOM in a
web page. No-one ever seemed to ask the tricky questions about closures or
object context, or performance of certain approaches etc. that was my
expertise. You see more of that nowadays, as most of these concepts have
gained traction in the mainstream; now there are probably tens of thousands
of people with that knowledge, not just the hundreds of a few years ago.
Thank-you for this walk down memory lane. Let me know how it goes with
Node.js. I just might have to try it out...
Cheers,
DBM
Dale Harvey
erlang.
I enjoy programming with node in a way that I dont with erlang, stuff feels
fun, I have lots of libraries that people have written for me, it already
has a package manager which to be honest embarrasses the erlang side of me
slightly.
However using node I have had problems making very simple things be
resilient to errors, async error handling is very very hard (as most erlang
people know) and there seems to be little effort with nodes community to
resolving that. So for now node is still a little fun toy to play with, but
when I want to write something that I know stays up, I use erlang.
However I am a little troubled by nodes popularity and the general dismissal
of "well erlang does it better", people are flocking to node in a way that
they are not with erlang, People are more and more needing to write the type
of async servers that node and erlang provide, programming with an embedded
server is also a huge benefit, people obviously want this but why are they
embracing node in a way they arent with erlang?
It took me 5 minutes from getting to the node website, to compiling it and
having my first hello world server up and running, a few minutes later I had
a package manager installed and some user contributed libraries that helped
me write what I wanted.
Installing erlang is mostly fine, however once I am there, there is no
standard build tools which will let me write my first module, compile it
(and by standard build tools I mean one command, not write my own emakefile,
or type c(module) at the shell) and run it, there are a bunch of web servers
to chose from which none are universally recommended and none are properly
documented, I have absolutely no idea how to install any of these servers
properly, to this day everyone had massively differing opinions on how
libraries should be bundled.
I think the erlang community really needs to sort out these problems once
and for all, and before diving into emacs, these are political problems not
technical ones.
I have had this on my mind for a while and still dont know the best
solutions, however, I am promising now that by the euc erlangotp.com will
finish its redesign with one major goal, to get a programmer completely
unfamiliar with erlang to get a "hello world" web server up and running in 5
minutes.
I think its time to settle on and promote tools like rebar / mochiweb /
learnyourselfsomeerlang / unknown package manager / and not wait for things
to be officially blessed by the otp team, they are busy making erlang
awesome, we as a community need to pick up the slack on that end.
So yeh, bit of a rant, but if anyone else is interested in lowering the
barriers to entry for erlang then shoot me an email / make a new thread, I
certainly want as much of the community as possible involved.
Cheers
Dale
David Welton
> code changing, moving code around, upgrading code without stopping the system
> and so on - these characteristics are extremely important if you want to
> build a 24x7 system with zero down time - less so if you just want to serve up
> pages as fast as possible and don't care if you take the system out of service
> for upgrades or errors.
>
> Erlang was designed for building fault-tolerant systems - node.js was not
node.js was designed for creating mostly asynchronous servers, with
most people using it for the web, a space where it competes with
Erlang to some degree.
I wrote the journal entry comparing node.js to Erlang referenced in
this thread, and my intuition is that while node.js is not as "good"
as Erlang, it's "good enough" for most web people doing asynch web
stuff like comet. And, given its popularity and industry adoption, it
will likely continue to improve, if it's managed well.
I see Erlang getting eclipsed by node.js in the web space, and
remaining something of a niche system for people who really do need
all the fault-tolerant, 24/7, etc... stuff. Erlang's advantages there
are obvious. However, mostly, the web world gets by without those
things - they may be nice, but most people get by ok without them.
It's a pity to see Erlang remain in that narrow niche, though, because
Erlang would benefit from the "network effects" of increased
popularity that its use in building web applications would bring, and,
in the same vein, would likely make Erlang a more valuable skill for
those of us who know it.
--
David N. Welton
Ulf Wiger
>
> I see Erlang getting eclipsed by node.js in the web space, and
> remaining something of a niche system for people who really do need
> all the fault-tolerant, 24/7, etc... stuff. Erlang's advantages there
> are obvious. However, mostly, the web world gets by without those
> things - they may be nice, but most people get by ok without them.
>
> It's a pity to see Erlang remain in that narrow niche, though, because
> Erlang would benefit from the "network effects" of increased
> popularity that its use in building web applications would bring, and,
> in the same vein, would likely make Erlang a more valuable skill for
> those of us who know it.
In a sense, this is a problem plaguing all technologies that require a bit
of extra effort up front in order to save time and money down the road.
Erlang comes off as being strange by definition, since it is not OO, Java-
like, or basically similar to anything mainstream.
Also, the advantages of Erlang are perhaps not so readily apparent, as
principles for massive concurrency and the issues of exception flows and
exception handling in concurrent systems are not part of the regular
curriculum. Add to that the "pioneering nature" of much in the Web space,
and you will have a large group of people who go for the low-hanging fruit,
and defer any problems of scale, robustness and complexity until later.
It will be a combination of knowingly deferring some problems, and of not
even realising what lies ahead. I don't necessarily view this as a bad thing.
Much innovation might have been stifled by too much knowledge of the
difficulties lurking around the corner.
BR,
Ulf W
Ulf Wiger, CTO, Erlang Solutions, Ltd.
http://erlang-solutions.com
Anthony Molinaro
On Fri, Oct 08, 2010 at 12:18:32AM +0100, Dale Harvey wrote:
> I think its time to settle on and promote tools like rebar / mochiweb /
> learnyourselfsomeerlang / unknown package manager / and not wait for things
> to be officially blessed by the otp team, they are busy making erlang
> awesome, we as a community need to pick up the slack on that end.
Just wanted to mention framewerk (http://code.google.com/p/fwtemplates/)
and erlrc (http://code.google.com/p/erlrc/). The former provides an
erlang template which allows you to quickly get a development package
up and running which includes the following
- generates a hello world style app when you initialize a new project
- provides the building of .erl files using make
- automatically builds .app and .appup files according to appup cookbook
- has eunit, dialyzer and cover integration
- builds debs, rpms or just tar.gz's.
- manages dependencies and maps those to the packaging system you are
using
- integrates with your version control system to tag when you release a
package
It also integrates which erlc which makes deb and rpm attempt to use
hot code loading when you install packages.
I use this currently by running an erlang node on a machine and having
everything I install packaged as an rpm. If a new rpm is available
I can use yum/rpm install and it will attempt a hot code upgrade during
the installation. It still has a few problems on RHEL but they are usually
a result of broken code_change handlers.
It's a great model, because you can have multiple applications versioned
separately all running in the same node. If you need to launch to multiple
nodes it ends up being as easy running for h in host1 ... host2 ; do ssh
$h "yum install new_package" ; done.
I've ended up repackaging many open source erlang projects as framewerk
projects just so I can get erlrc and rpm integration.
I've not played with rebar, but it seems to want to make a single application
which is fine for a download and test sort of setup, but when deploying
different applications to 100s of production machines, using standard
packaging managers works really well.
Anyway, I like it, and I think it brings something to the table in that
it sort of skips the "lets build a package management system different from
all other package management systems", and instead tries to work with the
most common systems (rpm and deb). It's also possible to add other package
management systems, so you could for instance get it working with faxien as
an alternative packaging system, making it possible to release packages in
many forms easily.
-Anthony
--
------------------------------------------------------------------------
Anthony Molinaro <anth...@alumni.caltech.edu>