Erlang (programming language)

Erlang (/ˈɜːrlæŋ/ UR-lang) is a general-purpose, concurrent, functional programming language, and a garbage-collected runtime system. The term Erlang is used interchangeably with Erlang/OTP, or Open Telecom Platform (OTP), which consists of the Erlang runtime system, several ready-to-use components (OTP) mainly written in Erlang, and a set of design principles for Erlang programs.[3]

ParadigmsMulti-paradigm: concurrent, functional
Designed by
First appeared1986 (1986)
Stable release
22.1.7[1] / 8 November 2019 (2019-11-08)
Typing disciplineDynamic, strong
LicenseApache License 2.0
Filename extensions.erl, .hrl
Major implementations
Influenced by
Lisp, PLEX,[2] Prolog, Smalltalk
Akka, Clojure, Dart, Elixir, F#, Opa, Oz, Reia, Rust, Scala

The Erlang runtime system is designed for systems with these traits:

The Erlang programming language has immutable data, pattern matching, and functional programming.[5] The sequential subset of the Erlang language supports eager evaluation, single assignment, and dynamic typing.

It was originally proprietary software within Ericsson, developed by Joe Armstrong, Robert Virding, and Mike Williams in 1986,[6] but was released as free and open-source software in 1998.[7][8] Erlang/OTP is supported and maintained by the Open Telecom Platform (OTP) product unit at Ericsson.


The name Erlang, attributed to Bjarne Däcker, has been presumed by those working on the telephony switches (for whom the language was designed) to be a reference to Danish mathematician and engineer Agner Krarup Erlang and a syllabic abbreviation of "Ericsson Language".[6][9] Erlang was designed with the aim of improving the development of telephony applications. The initial version of Erlang was implemented in Prolog and was influenced by the programming language PLEX used in earlier Ericsson exchanges. By 1988 Erlang had proven that it was suitable for prototyping telephone exchanges, but the Prolog interpreter was far too slow. One group within Ericsson estimated that it would need to be 40 times faster to be suitable for production use. In 1992, work began on the BEAM virtual machine (VM) which compiles Erlang to C using a mix of natively compiled code and threaded code to strike a balance between performance and disk space.[10] According to Armstrong, the language went from lab product to real applications following the collapse of the next-generation AXE telephone exchange named AXE-N in 1995. As a result, Erlang was chosen for the next asynchronous transfer mode (ATM) exchange AXD.[6]

In 1998 Ericsson announced the AXD301 switch, containing over a million lines of Erlang and reported to achieve a high availability of nine "9"s.[11] Shortly thereafter, Ericsson Radio Systems banned the in-house use of Erlang for new products, citing a preference for non-proprietary languages. The ban caused Armstrong and others to leave Ericsson.[12] The implementation was open-sourced at the end of the year.[6] Ericsson eventually lifted the ban; it re-hired Armstrong in 2004.[12]

In 2006, native symmetric multiprocessing support was added to the runtime system and VM.[6]

Erlang Worldview

The Erlang view of the world, as Joe Armstrong, co-inventor of Erlang, summarized in his PhD thesis:[13]

  • Everything is a process.
  • Processes are strongly isolated.
  • Process creation and destruction is a lightweight operation.
  • Message passing is the only way for processes to interact.
  • Processes have unique names.
  • If you know the name of a process you can send it a message.
  • Processes share no resources.
  • Error handling is non-local.
  • Processes do what they are supposed to do or fail.

Joe Armstrong remarked in an interview with Rackspace in 2013: “If Java is 'write once, run anywhere', then Erlang is 'write once, run forever'.”[14]


In 2014, Ericsson reported Erlang was being used in its support nodes, and in GPRS, 3G and LTE mobile networks worldwide and also by Nortel and T-Mobile.[15]

As Tim Bray, director of Web Technologies at Sun Microsystems, expressed in his keynote at O'Reilly Open Source Convention (OSCON) in July 2008:

If somebody came to me and wanted to pay me a lot of money to build a large scale message handling system that really had to be up all the time, could never afford to go down for years at a time, I would unhesitatingly choose Erlang to build it in.

Erlang is the programming language used to code WhatsApp.[16]

Functional programming examples

Factorial Algorithm

A factorial algorithm implemented in Erlang:

-module(fact). % This is the file 'fact.erl', the module and the filename must match
-export([fac/1]). % This exports the function 'fac' of arity 1 (1 parameter, no type, no name)

fac(0) -> 1; % If 0, then return 1, otherwise (note the semicolon ; meaning 'else')
fac(N) when N > 0, is_integer(N) -> N * fac(N-1).
% Recursively determine, then return the result
% (note the period . meaning 'endif' or 'function end')
%% This function will crash if anything other than a nonnegative integer is given.
%% It illustrates the "Let it crash" philosophy of Erlang.

Tail Recursive Fibonacci Algorithm

A tail recursive algorithm to calculate the n'th Fibonacci number.

%% The module declaration must match the file name "series.erl" 

%% The export statement contains a list of all those functions that form
%% the module's public API.  In this case, this module exposes a single
%% function called fib that takes 1 argument (I.E. has an arity of 1)
%% The general syntax for -export is a list containing the name and
%% arity of each public function

%% ---------------------------------------------------------------------
%% Public API
%% ---------------------------------------------------------------------

%% Handle cases in which fib/1 receives specific values
%% The order in which these function signatures are declared is a vital
%% part of this module's functionality

%% If fib/1 is passed precisely the integer 0, then return 0
fib(0) -> 0;

%% If fib/1 receives a negative number, then return the atom err_neg_val
%% Normally, such defensive coding is discouraged due to Erlang's 'Let
%% it Crash' philosophy; however, in this case we should explicitly
%% prevent a situation that will crash Erlang's runtime engine
fib(N) when N < 0 -> err_neg_val;

%% If fib/1 is passed an integer less than 3, then return 1
%% The preceding two function signatures handle all cases where N < 1,
%% so this function signature handles cases where N = 1 or N = 2
fib(N) when N < 3 -> 1;

%% For all other values, call the private function fib_int/3 to perform
%% the calculation
fib(N) -> fib_int(N, 0, 1).

%% ---------------------------------------------------------------------
%% Private API
%% ---------------------------------------------------------------------

%% If fib_int/3 receives a 1 as its first argument, then we're done, so
%% return the value in argument B.  Since we are not interested in the
%% value of the second argument, we denote this using _ to indicate a
%% "don't care" value
fib_int(1, _, B) -> B;

%% For all other argument combinations, recursively call fib_int/3
%% where each call does the following:
%%  - decrement counter N
%%  - Take the previous fibonacci value in argument B and pass it as
%%    argument A
%%  - Calculate the value of the current fibonacci number and pass it
%%    as argument B
fib_int(N, A, B) -> fib_int(N-1, B, A+B).

Here's the same coding without the explanatory comments


fib(0) -> 0;
fib(N) when N < 0 -> err_neg_val;
fib(N) when N < 3 -> 1;
fib(N) -> fib_int(N, 0, 1).

fib_int(1, _, B) -> B;
fib_int(N, A, B) -> fib_int(N-1, B, A+B).

Quicksort Algorithm

Quicksort in Erlang, using list comprehension:[17]

%% qsort:qsort(List)
%% Sort a list of items
-module(qsort).     % This is the file 'qsort.erl'
-export([qsort/1]). % A function 'qsort' with 1 parameter is exported (no type, no name)

qsort([]) -> []; % If the list [] is empty, return an empty list (nothing to sort)
qsort([Pivot|Rest]) ->
    % Compose recursively a list with 'Front' for all elements that should be before 'Pivot'
    % then 'Pivot' then 'Back' for all elements that should be after 'Pivot'
    qsort([Front || Front <- Rest, Front < Pivot]) ++ 
    [Pivot] ++
    qsort([Back || Back <- Rest, Back >= Pivot]).

The above example recursively invokes the function qsort until nothing remains to be sorted. The expression [Front || Front <- Rest, Front < Pivot] is a list comprehension, meaning "Construct a list of elements Front such that Front is a member of Rest, and Front is less than Pivot." ++ is the list concatenation operator.

A comparison function can be used for more complicated structures for the sake of readability.

The following code would sort lists according to length:

% This is file 'listsort.erl' (the compiler is made this way)
% Export 'by_length' with 1 parameter (don't care about the type and name)

by_length(Lists) -> % Use 'qsort/2' and provides an anonymous function as a parameter
   qsort(Lists, fun(A,B) -> length(A) < length(B) end).

qsort([], _)-> []; % If list is empty, return an empty list (ignore the second parameter)
qsort([Pivot|Rest], Smaller) ->
    % Partition list with 'Smaller' elements in front of 'Pivot' and not-'Smaller' elements
    % after 'Pivot' and sort the sublists.
    qsort([X || X <- Rest, Smaller(X,Pivot)], Smaller)
    ++ [Pivot] ++
    qsort([Y || Y <- Rest, not(Smaller(Y, Pivot))], Smaller).

Here again, a Pivot is taken from the first parameter given to qsort() and the rest of Lists is named Rest. Note that the expression

[X || X <- Rest, Smaller(X,Pivot)]

is no different in form from

[Front || Front <- Rest, Front < Pivot]

(in the previous example) except for the use of a comparison function in the last part, saying "Construct a list of elements X such that X is a member of Rest, and Smaller is true", with Smaller being defined earlier as

fun(A,B) -> length(A) < length(B) end

Note also that the anonymous function is named Smaller in the parameter list of the second definition of qsort so that it can be referenced by that name within that function. It is not named in the first definition of qsort, which deals with the base case of an empty list and thus has no need of this function, let alone a name for it.

Data types

Erlang has eight primitive data types:

Integers are written as sequences of decimal digits, for example, 12, 12375 and -23427 are integers. Integer arithmetic is exact and only limited by available memory on the machine. (This is called arbitrary-precision arithmetic.)
Atoms are used within a program to denote distinguished values. They are written as strings of consecutive alphanumeric characters, the first character being lowercase. Atoms can contain any character if they are enclosed within single quotes and an escape convention exists which allows any character to be used within an atom. Atoms are never garbage collected and should be used with caution, especially if using dynamic atom generation.
Floating point numbers use the IEEE 754 64-bit representation.
References are globally unique symbols whose only property is that they can be compared for equality. They are created by evaluating the Erlang primitive make_ref().
A binary is a sequence of bytes. Binaries provide a space-efficient way of storing binary data. Erlang primitives exist for composing and decomposing binaries and for efficient input/output of binaries.
Pid is short for process identifier  a Pid is created by the Erlang primitive spawn(...) Pids are references to Erlang processes.
Ports are used to communicate with the external world. Ports are created with the built-in function open_port. Messages can be sent to and received from ports, but these messages must obey the so-called "port protocol."
Funs are function closures. Funs are created by expressions of the form: fun(...) -> ... end.

And three compound data types:

Tuples are containers for a fixed number of Erlang data types. The syntax {D1,D2,...,Dn} denotes a tuple whose arguments are D1, D2, ... Dn. The arguments can be primitive data types or compound data types. Any element of a tuple can be accessed in constant time.
Lists are containers for a variable number of Erlang data types. The syntax [Dh|Dt] denotes a list whose first element is Dh, and whose remaining elements are the list Dt. The syntax [] denotes an empty list. The syntax [D1,D2,..,Dn] is short for [D1|[D2|..|[Dn|[]]]]. The first element of a list can be accessed in constant time. The first element of a list is called the head of the list. The remainder of a list when its head has been removed is called the tail of the list.
Maps contain a variable number of key-value associations. The syntax is#{Key1=>Value1,...,KeyN=>ValueN}.

Two forms of syntactic sugar are provided:

Strings are written as doubly quoted lists of characters. This is syntactic sugar for a list of the integer Unicode code points for the characters in the string. Thus, for example, the string "cat" is shorthand for [99,97,116].[18]
Records provide a convenient way for associating a tag with each of the elements in a tuple. This allows one to refer to an element of a tuple by name and not by position. A pre-compiler takes the record definition and replaces it with the appropriate tuple reference.

Erlang has no method to define classes, although there are external libraries available.[19]

The 'Let It Crash' Coding Style

Background Design Philosophy

In most other programming languages, software crashes have always been (and often still are) considered highly undesirable situations that must be avoided at all costs. Consequently, elaborate exception handling mechanisms exist to trap these situations and then mitigate their effects. It should be noted however that this design philosophy exists because many of the foundational principles of software design were defined at a time when computers were single processor machines. Under these conditions, software crashes were indeed fatal. Given this basic constraint, it was perfectly natural therefore to develop programming styles in which a large proportion of the code was dedicated to detecting and then handling error situations. This in turn, lead directly to the still widely popular coding style known as defensive programming.

However, the designers of Erlang realised that in spite of their undesirable effects, software crashes are much like death and taxes - quite unavoidable. Therefore, rather than treating a crash as a crisis situation that temporarily suspends all normal work until a solution is found, they reasoned it would make far greater sense to treat a crash in exactly the same manner as any other normal runtime event. Consequently, when an Erlang process crashes, this situation is reported as just another type of message arriving in a process' mail box.

This realisation led to Erlang's designers building a language with the following fundamental features:

  • Erlang has no concept of global memory; therefore relative to each other, all processes are isolated execution environments
  • Erlang processes can:
    • be spawned very cheaply
    • only communicate using message passing
    • monitor each other. This allows processes to be arranged in hierarchies known as 'supervisor trees'
  • A process should perform its task or fail
  • Process failure is reported simply as a message

The 'Let It Crash' style of coding is therefore the practical consequence of working in a language that operates on these principles.

Supervisor Trees and the 'Let It Crash' Architecture

A typical Erlang application is written in the form of a supervisor tree. This architecture is based on a hierarchy of processes in which the top level process is known as a "supervisor". The supervisor then spawns multiple child processes that act either as workers or more, lower level supervisors. Such hierarchies can exist to arbitrary depths and have proven to provide a highly scalable and fault-tolerant environment within which application functionality can be implemented.

Within a supervisor tree, all supervisor processes are responsible for managing the lifecycle of their child processes, and this includes handling situations in which those child processes crash. Any process can become a supervisor by first spawning a child process, then calling erlang:monitor/2 on that process. If the monitored process then crashes, the supervisor will receive a message containing a tuple whose first member is the atom 'DOWN'. The supervisor is responsible firstly for listening for such messages and secondly, for taking the appropriate action to correct the error condition.

In addition to this, the 'Let It Crash' philosophy results in a style of coding that contains very little (if any) defensive code. Consequently, applications written in Erlang tend to be much smaller than the equivalent functionality written in a language that does not discourage defensive programming.

In the case of productive Erlang applications, writing your own monitoring code is strongly discouraged because there are so many subtle and unforeseen edge cases. Within the Erlang/OTP environment, the supervisor behaviour is provided that both handles these edge cases, and provides a simple API.

Concurrency and distribution orientation

Erlang's main strength is support for concurrency. It has a small but powerful set of primitives to create processes and communicate among them. Erlang is conceptually similar to the language occam, though it recasts the ideas of communicating sequential processes (CSP) in a functional framework and uses asynchronous message passing.[20] Processes are the primary means to structure an Erlang application. They are neither operating system processes nor threads, but lightweight processes that are scheduled by BEAM. Like operating system processes (but unlike operating system threads), they share no state with each other. The estimated minimal overhead for each is 300 words.[21] Thus, many processes can be created without degrading performance. In 2005, a benchmark with 20 million processes was successfully performed with 64-bit Erlang on a machine with 16 GB random-access memory (RAM; total 800 bytes/process).[22] Erlang has supported symmetric multiprocessing since release R11B of May 2006.

While threads need external library support in most languages, Erlang provides language-level features to create and manage processes with the goal of simplifying concurrent programming. Though all concurrency is explicit in Erlang, processes communicate using message passing instead of shared variables, which removes the need for explicit locks (a locking scheme is still used internally by the VM).[23]

Inter-process communication works via a shared-nothing asynchronous message passing system: every process has a "mailbox", a queue of messages that have been sent by other processes and not yet consumed. A process uses the receive primitive to retrieve messages that match desired patterns. A message-handling routine tests messages in turn against each pattern, until one of them matches. When the message is consumed and removed from the mailbox the process resumes execution. A message may comprise any Erlang structure, including primitives (integers, floats, characters, atoms), tuples, lists, and functions.

The code example below shows the built-in support for distributed processes:

 % Create a process and invoke the function web:start_server(Port, MaxConnections)
 ServerProcess = spawn(web, start_server, [Port, MaxConnections]),

 % Create a remote process and invoke the function
 % web:start_server(Port, MaxConnections) on machine RemoteNode
 RemoteProcess = spawn(RemoteNode, web, start_server, [Port, MaxConnections]),

 % Send a message to ServerProcess (asynchronously). The message consists of a tuple
 % with the atom "pause" and the number "10".
 ServerProcess ! {pause, 10},

 % Receive messages sent to this process
         a_message -> do_something;
         {data, DataContent} -> handle(DataContent);
         {hello, Text} -> io:format("Got hello message: ~s", [Text]);
         {goodbye, Text} -> io:format("Got goodbye message: ~s", [Text])

As the example shows, processes may be created on remote nodes, and communication with them is transparent in the sense that communication with remote processes works exactly as communication with local processes.

Concurrency supports the primary method of error-handling in Erlang. When a process crashes, it neatly exits and sends a message to the controlling process which can then take action, such as for instance starting a new process that takes over the old process's task.[24][25]


The official reference implementation of Erlang uses BEAM.[26] BEAM is included in the official distribution of Erlang, called Erlang/OTP. BEAM executes bytecode which is converted to threaded code at load time. It also includes a native code compiler on most platforms, developed by the High Performance Erlang Project (HiPE) at Uppsala University. Since October 2001 the HiPE system is fully integrated in Ericsson's Open Source Erlang/OTP system.[27] It also supports interpreting, directly from source code via abstract syntax tree, via script as of R11B-5 release of Erlang.

Hot code loading and modules

Erlang supports language-level Dynamic Software Updating. To implement this, code is loaded and managed as "module" units; the module is a compilation unit. The system can keep two versions of a module in memory at the same time, and processes can concurrently run code from each. The versions are referred to as the "new" and the "old" version. A process will not move into the new version until it makes an external call to its module.

An example of the mechanism of hot code loading:

  %% A process whose only job is to keep a counter.
  %% First version
  -export([start/0, codeswitch/1]).

  start() -> loop(0).

  loop(Sum) ->
       {increment, Count} ->
       {counter, Pid} ->
          Pid ! {counter, Sum},
       code_switch ->
          % Force the use of 'codeswitch/1' from the latest MODULE version

  codeswitch(Sum) -> loop(Sum).

For the second version, we add the possibility to reset the count to zero.

  %% Second version
  -export([start/0, codeswitch/1]).

  start() -> loop(0).

  loop(Sum) ->
       {increment, Count} ->
       reset ->
       {counter, Pid} ->
          Pid ! {counter, Sum},
       code_switch ->

  codeswitch(Sum) -> loop(Sum).

Only when receiving a message consisting of the atom code_switch will the loop execute an external call to codeswitch/1 (?MODULE is a preprocessor macro for the current module). If there is a new version of the counter module in memory, then its codeswitch/1 function will be called. The practice of having a specific entry-point into a new version allows the programmer to transform state to what is needed in the newer version. In the example, the state is kept as an integer.

In practice, systems are built up using design principles from the Open Telecom Platform, which leads to more code upgradable designs. Successful hot code loading is exacting. Code must be written with care to make use of Erlang's facilities.


In 1998, Ericsson released Erlang as free and open-source software to ensure its independence from a single vendor and to increase awareness of the language. Erlang, together with libraries and the real-time distributed database Mnesia, forms the OTP collection of libraries. Ericsson and a few other companies support Erlang commercially.

Since the open source release, Erlang has been used by several firms worldwide, including Nortel and T-Mobile.[28] Although Erlang was designed to fill a niche and has remained an obscure language for most of its existence, its popularity is growing due to demand for concurrent services.[29][30] Erlang has found some use in fielding massively multiplayer online role-playing game (MMORPG) servers.[31]

See also


  1. "Releases - erlang/otp". Retrieved 11 November 2019 via GitHub.
  2. Conferences, N. D. C. (4 June 2014). "Joe Armstrong - Functional Programming the Long Road to Enlightenment: a Historical and Personal Narrative". Vimeo.
  3. "Erlang – Introduction".
  4. Armstrong, Joe; Däcker, Bjarne; Lindgren, Thomas; Millroth, Håkan. "Open-source Erlang – White Paper". Archived from the original on 25 October 2011. Retrieved 31 July 2011.
  5. Hitchhiker’s Tour of the BEAM – Robert Virding
  6. Armstrong, Joe (2007). History of Erlang. HOPL III: Proceedings of the third ACM SIGPLAN conference on History of programming languages. ISBN 978-1-59593-766-7.
  7. "How tech giants spread open source programming love -".
  8. "Erlang/OTP Released as Open Source, 1998-12-08". Archived from the original on 9 October 1999.
  9. "Erlang, the mathematician?".
  10. Armstrong, Joe (August 1997). "The development of Erlang". ACM SIGPLAN Notices. 32 (8): 196–203. doi:10.1145/258948.258967. ISBN 0897919181.
  11. "Concurrency Oriented Programming in Erlang" (PDF). 9 November 2002.
  12. "question about Erlang's future". 6 July 2010.
  14. McGreggor, Duncan (26 March 2013). Rackspace takes a look at the Erlang programming language for distributed computing (Video). Rackspace Studios, SFO. Retrieved 24 April 2019.
  15. "Ericsson". 4 December 2014. Retrieved 7 April 2018.
  16. "Inside Erlang, The Rare Programming Language Behind WhatsApp's Success". 21 February 2014. Retrieved 12 November 2019.
  17. "Erlang – List Comprehensions".
  18. "String and Character Literals". Retrieved 2 May 2015.
  19. "ect – Erlang Class Transformation – add object-oriented programming to Erlang – Google Project Hosting". Retrieved 2 May 2015.
  20. Armstrong, Joe (September 2010). "Erlang". Communications of the ACM. 53 (9): 68–75. doi:10.1145/1810891.1810910. Erlang is conceptually similar to the occam programming language, though it recasts the ideas of CSP in a functional framework and uses asynchronous message passing.
  21. "Erlang Efficiency Guide – Processes". Archived from the original on 27 February 2015.
  22. Wiger, Ulf (14 November 2005). "Stress-testing erlang". comp.lang.functional.misc. Retrieved 25 August 2006.
  23. "Lock-free message queue". Retrieved 23 December 2013.
  24. Armstrong, Joe. "Erlang robustness". Archived from the original on 23 April 2015. Retrieved 15 July 2010.
  25. "Erlang Supervision principles". Archived from the original on 6 February 2015. Retrieved 15 July 2010.
  26. "Erlang – Compilation and Code Loading". Retrieved 21 December 2017.
  27. "High Performance Erlang". Retrieved 26 March 2011.
  28. "Who uses Erlang for product development?". Frequently asked questions about Erlang. Retrieved 16 July 2007. The largest user of Erlang is (surprise!) Ericsson. Ericsson use it to write software used in telecommunications systems. Many dozens of projects have used it, a particularly large one is the extremely scalable AXD301 ATM switch. Other commercial users listed as part of the FAQ include: Nortel, Deutsche Flugsicherung (the German national air traffic control organisation), and T-Mobile.
  29. "Programming Erlang". Retrieved 13 December 2008. Virtually all language use shared state concurrency. This is very difficult and leads to terrible problems when you handle failure and scale up the system...Some pretty fast-moving startups in the financial world have latched onto Erlang; for example, the Swedish
  30. "Erlang, the next Java". Archived from the original on 11 October 2007. Retrieved 8 October 2008. I do not believe that other languages can catch up with Erlang anytime soon. It will be easy for them to add language features to be like Erlang. It will take a long time for them to build such a high-quality VM and the mature libraries for concurrency and reliability. So, Erlang is poised for success. If you want to build a multicore application in the next few years, you should look at Erlang.
  31. Clarke, Gavin (5 February 2011). "Battlestar Galactica vets needed for online roleplay". Music and Media. The Reg. Retrieved 8 February 2011.

Further reading

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.