[erlang-questions] Newbie - Erlang VS other functional languages

Fred Hebert mononcqc@REDACTED
Fri Jan 16 17:17:54 CET 2015

On 01/16, Garrett Smith wrote:
> I don't think Erlang has an edge over any other language in terms of
> scaling across multiple servers - not at all. Other functional
> languages have access to network APIs the same way Erlang does.
> I suppose it's less fiddly to send Erlang terms across the wire.
> Erlang has some built in facilities for building distributed
> applications. Erlang's been doing this sort of thing for a long time.
> But other languages can do it - particularly with the many
> multi-language messaging libraries and tools available today.
> What Erlang is special for IMO is it concurrency model, which is
> implemented in and enforced by the *VM* - there's no shared memory
> across threads of execution. One thread cannot corrupt the memory used
> by another. To communicate between threads of execution, threads must
> pass and receive messages (copied data).

Ah but this is why Erlang is also good for distributed systems! These
things are related, not independent.

Distributed systems communicate by message passing and cannot share
anything (well, they can, but I encourage you to read some papers on
distributed object garbage collection on why this is a bad idea). This
requirement to do it locally ends up giving us timers, links, monitors,
and all other kinds of goodies that are useful when doing distributed

Of course there are caveats; a local process that dies can be monitored
and linked and will pretty much always be dead when you receive that
message (bar some rare VM bug in old versions). Aremote process can die
with the reason 'nodedown', meaning that a remote node is gone. We can't
know if the process is truly dead, the node timing out, the
communication pipe saturated. That requires special consideration.

But Erlang has *all* of that tooling already in place. Hell, there's a
version id in each pid, port, and reference that the VM sets (through
EPMD) to make it possible to know (with up to 3 restarts) if the pid is
the same as the one you talked to if they share the same number.

It is right that Erlang doesn't take the hard problems out of
distributed computing: a lot of libraries shipping with the language
don't even consider netsplits a possibility (some do -- global, pg2,
etc.). However, it has put in place a lot of scaffolding to solve almost
all of the easy problems.

This means that when you're building a distributed system, you still
have to fight all the nasty bugs and assumption that go in your design.
But at least, you don't nearly have to fight all the nasty bugs and assumption
in all the communication mechanisms that your system is built on as
often as you would in most other languages out there.


More information about the erlang-questions mailing list