How do I download the paper for study and future use? Will I be vio...
### Hard Real Time vs Soft Real Time
A real time system is a sys...
CHILL is a procedural and object oriented programming language. Its...
The Ericsson MD110 is a PBX system (Private Branch Exchange), which...
### Declarative vs Imperative programming
These are two programm...
### PROLOG
PROLOG is a logic programming language (as opposed to ...
Even tho Ericsson's market share in the mobile phone market decline...
The AXE10 is part of the AXE telephone exchange product line of cir...
PLEX (Programming Language for EXchanges) is a special-purpose, pro...
PABX stands for *Private Automatic Branch Exchange* which is a tech...
It's important to underline that even tho Erlang is a language that...
### Agner Krarup Erlang
Agner Erlang was a Danish mathematician, s...
BEAM is the virtual machine at the core of the Erlang Open Telecom ...
Strand is a parallel programming language. The citation goes to a b...
*JAM* stands for Joe's Abstract Machine
[Warren Abstract Machine (WAM)](https://en.wikipedia.org/wiki/Warre...
I wonder if this is still true? I would say that most software engi...
Further notes on the basic syntax of Erlang:
```
-module(math)....
### SNMP
Simple Network Management Protocol (SNMP) is an applicati...
I think it is interesting that [H|T] and {Key1, Val, S,B} (above) b...
You can read more about the effort to create a type system for Erla...
The development of Erlang
Joe Armstrong
Computer Science Laboratory
Ericsson Telecom AB
joeQcslab.ericsson.se
Abstract
This paper describes the development of the programming
language Erlang during the period 1985-1997.
Erlang is a concurrent programming language designed
for programming large-scale distributed soft real-time con-
trol applications.
The design of Erlang was heavily influenced by ideas from
the logic and functional programming communities. Other
sources of inspiration came from languages such as
Chill and
Ada which are used in industry for programming control
systems.
1 Introduction
This paper describes the development of the Erlang pro-
gramming language. Erlang is a language which draws heav-
ily from various traditions in the logic, functional and real-
time control programming communities.
Our goal was to make a language which could
be used
for building large soft real-time control systems. By large I
mean systems with possibly millions of lines of code. By a
soft real-time system I mean a system which does not faif
catastrophically if a real-time deadline is missed.
Erlang was developed by the author and his colleagues
at the Ericsson Computer Science Laboratory. Ericsson is
currently the world’s largest supplier of telecoms systems
and the world’s leading manufacturer of mobile phones.
Ericsson’s flagship product is a telephone exchange called
the AXE lO which is programmed in a proprietary language
called PLEX. A typicaf AXEl O system has over 5 million
Iines of PLEX. The AXEIO is specified to have a “down
time” of less than 3 minutes per year - such requirements
are common in the telecoms industry.
The programming languages which are used for building
such systems have to deal with a range of problems not usu-
ally encountered in traditional batch or interactive computer
systems. For example, one requirement is that the system
should be in “continuous” operation - this means we must
do software upgrades without stopping the system. It also
implies the use of fault-tolerant processors and a software
architecture which protects the integrity of the system from
various classes of programmer error,
Erlang grew out of a series of experiments which we per-
formed to see if we could find better ways of programming
telecoms systems.
Our criterion for success was that we
could program telecoms systems with less effort and fewer
errors than could be done using conventional technology.
Permission to
make digital/hard copy of part or all this work for
personal or classroom use is granted without fee provided that
copies are not made or distributed for profit or commercial advan-
tage, the copyright notice, the title of the publication and its date
appear, and notice is given that copying is by permission of ACM,
Inc. To copy otherwise, to republish, to post on servers, or to
redistribute to lists, requires prior specific permission and/or a fee
This paper starts with a brief discussion of the various
milestones which the language went through. This is fol-
lowed by sections describhrg the language, finally future di-
rections of research are mentioned.
2
Milestones
●
s
b
Early experiments
Being a telecoms laboratory we were in the fortunate
position of always having hardware to play with. The
lab had a Ericsson MD110 (which is a smafl telephone
exchange) which had been modified so it could be
controlled by a conventional Unix machine. We pro-
grammed POTS1 in as many programming languages
as we could lay our hands on.
The main conclusion [5] was that declarative language
programs for POTS were a lot shorter and easier to
understand than imperative language programs. Un-
fortunately the declarative languages lacked features
for concurrency control and had poor error handling
facilities.
We concluded that we would like something like Pro
log with added facilities for concurrency and improved
error handling. No such language existed at the time.
1986 - 1989
The Prolog interpreter
Having decided that we liked Prolog for programming
POTS we started a series of experiments call LOTS
(Lots of POTS) to program not only
POTS but aleo
an extremely large number of different telephony fea-
tures in Prolog. Before long I had programmed a large
subset of PABX features in Prolog. To do so I wrote
a Prolog meta-interpretor which added the notion of
a process to Prolog and which added facilities for ad-
vanced error detection and recovery. This work is de-
scribed in [1].
The Bollmora group
Using the results of the work with the Prolog interpre-
ter we were able to attract the curiosity and interest of
a group of engineers who
were responsible for a future
soft ware architecture of the Ericsson MD 110.
‘
POTS stands for Plain Old Telephony Service, that is, subscriber
A calls subscriber B and they chat for a while
‘Who worked in Bollmora, Stockholm.
ICFP ’97 Amsterdam, ND
0 1997 ACM 0-89791 -918 -1/97 /0006 .,.$3.50
196
●
●
This group thought that they could US( our results as
a vehicle for investigate ing their own software architec-
tures. This began a period of collaboration which led
to the development of Erlang as a fully fledged lan-
guage and to a new range of Ericsson products.
During the period 1986-1988 members of the computer
science lab worked closely with the Bollmora group,
meeting once or twice a week. During this time the
Prolog interpretor (and the language which it defined)
changed rapidly, The language grew and evolved and
somewhere along the line acquired a name, Erlang,
named in honor of the Danish mathematician Agner
Krarup Erlang (1878- 1929) whose name is associated
with the telecoms industry.
The jam machine
By about 1988 is was clear that Erlang as it was now
called wss a good language for prototyping telephone
exchanges [10]. It was a strange mixture, with declar-
ative features (inherited from Prolog), multi-tasking
and concurrency (inherited from EriPascaJ and Ada)
and an original combination of error handling mecha-
nisms.
Erlang was, however, tar too slow to be used for prod-
uct development, The Bolhnora group did some mea-
surements and decideil t}lat for product development
they needed a system that was 40 times faster than
the Prolog interpreter
This requirement lead to the development of a number
of different abstract lnachines and compilation tech-
niques used for implementing Erlang. A cross compiler
from Erlang to Strand [7] was developed. After a num-
ber of experiments tht JAM [4] machine was invented.
This was based on the Warren Abstract Machine with
added primitives for concurrency and exception han-
dling.
By this time the Erlang effort had grown to three peo-
ple. Mike Wifliams wrote a byte code emulator for
JAM code, I wrote the compiler and Robert Virding
wrote the support libraries.
While we only ever distributed one version of the sys-
tem to externaf user:., internally there were severaf
competing Erlang “engines” where we experimented
with different implementation techniques.
The resulting JAM implementation was delivered to
the Bollmora group in 1989. Fortunately it was 70
times faster than the original Prolog interpretor - un-
fortunately they had now revised their original esti-
mates and wanted a machine that was 280 times faster
than the original.
Adding distribution
During the period 1989-1994 the Erlang “group” ex-
panded (there has ne~,er been a formal group). Claes
Vikstrom joined the group in 1990 and added distribu-
tion to the language. The original language had been
designed with “hooks’ for adding distribution - but
this was Iiever actually done until Claes implemented
it.
The Bollmora group had now decided to go ahead
and build a new PABX in Erlang. Erlang wasn’t fast
●
9
●
enough but it was generally thought that the perfor-
mance problems could be solved. In 1992 they started
development of a product called the “Mobility Server”,
In 199.5 this was launched and became part of the
“Consono” product range. At the time of writing the
Mobility Server is marketed in 12 countries. Among
other things it is used to control the DECT mobile
phone in the European Parliament in Strasbourg.
Fight for acceptance
During the period 1992-1996 it was by no means clear
that Erlang was suitable for programming large-scale
industrial products. While we were very successful in
a number of smalf projects, Erlang programming and
programmers stilf represented a very small percentage
of the programming effort at Ericsson.
The Mobility server project continued and we attracted
several new smalf projects. During this time we were
involved in maasive “guerilla marketing” activities. I
don’t think there was a single person in Ericsson who
ever came out of Bjarne’s3 office without a copy of the
Erlang manual under their arm!
The beam
Performance has always been a major problem. In
1992 Bogumil Hausman started work on the BEAM.4
The BEAM compiles Erlang to C which can then be
compiled with a conventional C compiler. The BEAM
can afso compife to threaded code which can be freely
intermixed with compiled code.
Compiled code is faster but takes up more space than
threaded code. In a large embedded system with mil-
lions of lines of code, the volume of object code can be
a major problem,
Infrequently used and non-performance critical parts
of the system can be compiled to threaded code while
performance critical parts of the system can be com-
piled to native code. There are performance tools
which we can use to analyse the system and find out
which parts of the system need to be native code com-
piled.
The BEAM is described in [6]. In many applications
the BEAM is comparable with C in performance terms.
The BEAM replaced the JAM as the principle system
for new product development in 1997.
Erlang Systems
Up to 1995 most users were “enthusiasts” and Erlang
spread internally within Ericsson by “word of mouth”.
We didn’t find new users, they found us.
As the language spread we needed to produce training
material and hold courses to train new users. Initially,
all courses were held at the Computer Science Lab by
members of the Erlang “group”. Whife holding such
courses was great fun, demand soon far outstripped
supply.
In April 1993 a new company “Erlang Systems” was
formed to handle sales, marketing, education and con-
sulting of Erlang. We had been in the fortunate posi-
tion of having supervised a number of Master degree
3
Boss of the computer science lab.
4 Bogdans’s Erlang Abstract machine.
197