[erlang-questions] The future of Erlang and BEAM
Mon Feb 13 23:11:20 CET 2012
Perhaps it wasnt Erlang's original intent, but I find one of the amazing
things about Erlang that I had an application that ran on a single box.
However, it needed to be running 24×7, which, of course, is impossible on a
single box, since sometimes that box has to be rebooted or taken down for
maintenance. With the addition of just a few config files no code changes
I was able to have it running at a single place on my network, but with
failover sessions waiting in the background for the occasions when the main
process goes down. This is a fun demo, too, when people ask why I chose
Erlang for the application; I can just pull up a few remote sessions to the
servers and kill the main, and they can see the failover take over right
> -----Original Message-----
> From: [mailto:erlang-questions-
> ] On Behalf Of Joe Armstrong
> Sent: Saturday, February 11, 2012 11:02 AM
> To: Radek
> Subject: Re: [erlang-questions] The future of Erlang and BEAM
> I'll try and give a short answer to your question.
> To start with you are comparing chalk with cheese - Erlang was
> NOT designed to be a fast messaging passing language. It was designed
> for building fault-tolerant applications - it wasn't designed
> for speed it was designed for safety.
> A lot of the message passing platforms you read about, and mention in
> the same breath as Erlang were designed for speed
> and not safety - so it's hardly surprising that is the absence of
> errors these other platforms are faster than Erlang.
> Where Erlang should excel is when things go wrong - when the
> code is buggy and crashes, when the system is overloaded, when you
> stress things in unexpected ways.
> The Erlang view of the world is very different to the view of
> the world used in most other languages.
> Take a web server, for example. In the conventional view of the
> world if there might be one web server per machine, the
> web server might spawn an OS process for each incoming task
> (if it wants safety) of it might handle all sessions in the same task
> if it wants speed but no safety. It (the web server) uses OS processes
> for reasons of safety - to isolate the user sessions from
> each other - but this is very slow.
> What happens if there is a rare
> error in the web-server code itself - one that is very rarely
> encountered. Does this affect *all* user sessions or only the
> session where the error occurred? - My guess is that all sessions
> will collapse if the web-server itself collapses.
> How is a web-server in Erlang written? On the face of things it
> looks like any other web sever - but an Erlang system that appears
> from the outside to be handling (say) 2000 user sessions,
> is NOT one web server with 2000 sessions - it is 2000 erlang
> process (all independent) and each one is running ONE web server.
> So in the Erlang case we have 2000 web servers, each running
> one user session - in the conventional case we have one web
> server running 2000 sessions.
> Back to my question - what happens if there is a rare error
> in the web server code itself which is triggered in one session?
> In the Erlang case only one web server dies and all the rest
> survive. In the case where all 2000 sessions are handled by the
> faster server all sessions die.
> So you choose - fast or safe? - If you want the fastest possible
> solution Erlang is not the answer - BUT it will be unsafe.
> Adding checks and recovery mechanism COSTS something.
> There are no free lunches.
> I often see messaging passing systems mentioned that are said
> to have "Erlang like semantics" and are said to be faster.
> But these are unsafe systems and Erlang like semantics means
> *a lot more* than fast message passing.
> Erlang is good at what it was designed to be good at - which was
> building fault-tolerant soft real-time distributed systems with
> dynamic code upgrade - I know of nothing that has remotely
> similar semantics.
> There are *many* systems with superficial similarities - but non
> that I would trust to build fault-tolerant systems with.
> On Sat, Feb 11, 2012 at 11:34 AM, Radek <>
> > Hello Group,
> > it's my first post here, although I've been reading many interesting
> > here for quite a long time.
> > Anyway, I posted a question on StackOverflow today with the same
> > (here). As I've written there, I don't want to start any flame-war,
> > particularly because I'm actually an Erlang fan-boy :) but I'd like
> to know
> > your opinion on the subject. Here's the original question:
> > -------
> > Some time ago I got seriously interested in Erlang (coming from
> > world) - and I've seen it has been successfuly used in the industry,
> > Ericsson, Facebook, Goldman Sachs, etc. So, I thought it would be a
> > platform to build high demanding apps, with low-latency profile, with
> a lot
> > cleaner and nicer language than, for example, Java (for me).
> > But after "wow effect" has gone, I discovered that there are many
> > performance Java libraries that seem to resolve many problems that
> Erlang is
> > theoretically best suited for (real-time, low-latency applications,
> > concurrency, fault-tolerance, etc.). Moreover, it seems that there
> > things that, despite Erlang profile, are just not possible to achieve
> > BEAM (like LMAX Disruptor concurrent framework).
> > So the question arises: is Erlang still the best platform to build
> > demanding applications ? Wouldn't it be better if we stick to one,
> > mature (J)VM and try to make it even better than trying to achieve
> > similar with less resources available (size of OTP team vs. JVM team,
> > supporters, etc) ? And is it possible at all to achieve this kind of
> > performance and adoption with BEAM ?
> > And just to make things clear: I don't want to init a flame war here.
> I am
> > just curious becouse I really like Erlang and I think it's a great
> > and I'd like to invest time and effort to build real-life projects on
> > But I'd just like to know what others might say about that and - if
> > - maybe someone could correct me.
> > -------
> > I hope we can discuss it since I think it would be valuable not only
> for me.
> > Greetings,
> > Radek
> > _______________________________________________
> > erlang-questions mailing list
> > http://erlang.org/mailman/listinfo/erlang-questions
> erlang-questions mailing list
More information about the erlang-questions