The same component isolation that made
it effective for large distributed telecom
systems makes it effective for multicore
CPUs and networked applications.
BY Joe aRmstRonG
erlang iS a concurrent programming language
designed for programming fault-tolerant distributed
systems at Ericsson and has been (since 2000) freely
available subject to an open-source license. More
recently, we’ve seen renewed interest in Erlang, as
the Erlang way of programming maps naturally to
multicore computers. In it the notion of a process is
fundamental, with processes created and managed
by the Erlang runtime system, not by the underlying
operating system. The individual processes, which are
programmed in a simple dynamically typed functional
programming language, do not share memory and
exchange data through message passing, simplifying
the programming of multicore computers.
Erlang2 is used for programming fault-tolerant,
distributed, real-time applications. What differentiates
it from most other languages is that it’s a concurrent
programming language; concurrency belongs to
the language, not to the operating system. Its
programs are collections of parallel processes
cooperating to solve a particular problem that can
be created quickly and have only limited memory
overhead; programmers can create
large numbers of Erlang processes yet
ignore any preconceived ideas they
might have about limiting the number
of processes in their solutions.
All Erlang processes are isolated
from one another and in principle
are “thread safe.” When Erlang applications are deployed on multicore
computers, the individual Erlang processes are spread over the cores, and
programmers do not have to worry
about the details. The isolated processes share no data, and polymorphic messages can be sent between
processes. In supporting strong isolation between processes and polymorphism, Erlang could be viewed
as extremely object-oriented though
without the usual mechanisms associated with traditional OO languages.
Erlang has no mutexes, and processes cannot share memory.a Even
within a process, data is immutable.
The sequential Erlang subset that executes within an individual process is a
dynamically typed functional programming language with immutable state.b
Moreover, instead of classes, methods,
and inheritance, Erlang has modules
that contain functions, as well as high-er-order functions. It also includes processes, sophisticated error handling,
code-replacement mechanisms, and a
large set of libraries.
Here, I outline the key design criteria behind the language, showing how
they are reflected in the language itself,
as well as in programming language
technology used since 1985.
The Erlang story began in mid-1985
when I was a new employee at the Ericsson Computer Science Lab in Stock-
a The shared memory is hidden from the programmer. Practically all application programmers never use primitives that manipulate
shared memory; the primitives are intended
for writing special system processes and not
normally exposed to the programmer.