Cloud Parts

Erlang

A dynamically typed functional language from Ericsson, built for systems that must never stop: lightweight processes that share nothing, supervisors that restart what fails, and code that can be upgraded while it runs.

What it is
Programming languages (run on a virtual machine)
Type
Open source
Made by
Ericsson (Erlang/OTP team)
License
Apache 2.0
Facts checked
8 October 2026
Website Source code

What it is

Erlang is a functional language whose variables are bound by pattern matching, and whose unit of concurrency is the process: a lightweight process owned by the runtime, not the operating system. Processes share no memory and talk only by sending messages, which the receiver picks out of its mailbox with receive and patterns. When a process dies, it sends an exit signal to the processes linked to it, so failures are handled by other processes instead of with defensive code at every step. Erlang/OTP, the distribution, turns that into structure: supervisors are processes that watch workers and restart them, arranged in supervision trees, and behaviours such as gen_server and supervisor supply the generic half of common process types so you write only the callbacks.

The compiler erlc produces .beam files that run on BEAM, the Erlang virtual machine, which schedules processes preemptively across all cores, collects each process’s heap separately and can load a new version of a module while the old one is still running. Several Erlang runtimes on different machines can be joined into a cluster of nodes, and sending a message to a process on another node looks the same as sending one locally. Types are checked at run time; Dialyzer, a static analysis tool shipped with Erlang/OTP, finds definite type errors and unreachable code.

Why teams pick it

  • Concurrency is the core of the language: a new process costs 327 words, so one per call, connection or device is normal
  • Fault tolerance by design: links, exit signals and supervision trees restart failed parts instead of letting errors spread
  • Hot code loading and built-in distribution, both part of the language and runtime rather than add-on libraries
  • Decades of production use in telecom, with OTP behaviours that encode proven patterns for servers, state machines and supervisors

Watch out for

  • Dynamic typing: type errors surface at run time unless you run Dialyzer, which reports only errors it can prove
  • Messages are copied between processes, so sharing large data structures between processes is expensive
  • Number crunching is not its strength: BeamAsm translates instruction by instruction with hardly any optimisation across them

Alternatives

What all run on a virtual machine have in common →
C#Open sourceMicrosoft’s statically typed, object-oriented language for .NET, which made `async` and `await` mainstream and gains a new version every November.ClojureOpen sourceA dynamic Lisp hosted on the JVM, built around immutable persistent data structures and interactive development at the REPL.ElixirOpen sourceA dynamic, functional language on the Erlang virtual machine, created by José Valim: Erlang’s processes, supervisors and hot code loading, with modern tooling, macros and gradual types being added to the compiler.F#Open sourceA functional-first language from the ML family that runs on .NET, with type inference, immutable data by default and computation expressions.JavaOpen sourceA statically typed, object-oriented language that compiles to portable bytecode for the Java Virtual Machine, with a new release every six months.ScalaOpen sourceA statically typed language that fuses object-oriented and functional programming, compiles to JVM bytecode and calls Java libraries directly.

How it fits with other technologies

A counter that keeps its state in its own process · erlang

%% counter.erl
-module(counter).
-export([start/0, loop/1]).

start() -> spawn(fun() -> loop(0) end).

loop(N) ->
    receive
        {incr, From} ->
            From ! {count, N + 1},
            ?MODULE:loop(N + 1);   % fully qualified call: moves to new code after a reload
        stop ->
            ok
    end.

%% in the shell (erl):
%% 1> c(counter).
%% {ok,counter}
%% 2> Pid = counter:start().
%% 3> Pid ! {incr, self()}, receive {count, C} -> C end.
%% 1
%% 4> Pid ! {incr, self()}, receive {count, C2} -> C2 end.
%% 2

See it in a real stack

No architecture uses Erlang yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from1986–2021

Erlang started in 1986 at the Ericsson Computer Science Laboratory with one goal: “to provide a better way of programming telephony applications.” A switch handles tens or hundreds of thousands of calls at once, must keep working when parts fail, and must be upgraded without being switched off. The first version was an interpreter written in Prolog, which is where its dynamic typing comes from. In 1989 Joe Armstrong, Robert Virding and Mike Williams built JAM, a virtual machine about 70 times faster.

Ericsson formed a product unit, OTP (Open Telecom Platform), to support Erlang; it shipped the first Erlang/OTP release in 1996 and became a separate unit in 1997. The AXD301 switch, announced in March 1998, was possibly the largest program ever written in a functional language. Yet in February 1998 Ericsson Radio banned Erlang for new products. That ban led indirectly to Open Source Erlang in December 1998, after which most of the original team left to found Bluetail, and Erlang began spreading outside Ericsson.

Why it’s built this way

Processes in the language, not the operating system
Telephone systems are concurrent by nature. Making processes lightweight and part of the language, a minority view at the time, let programs model each call or device as its own process.
No shared memory between processes
Error recovery is impossible if the data needed for it sits on a machine that has crashed. Every process keeps enough local information to carry on when another part fails, and mutexes over shared data were too hard to get right in a distributed system.
Handle errors in another process
A fault-tolerant system needs at least two computers that watch each other, because the one that failed can’t repair itself. Erlang applied the same idea inside a program: a dying process sends an exit signal to linked processes, which recover for it.
Dynamic types
Erlang started life as a Prolog interpreter and kept a dynamic type system. Later attempts to add static typing proved very hard, so checking was left to optional tools such as Dialyzer.

Timeline

  1. 1986

    Erlang work starts at the Ericsson Computer Science Laboratory

  2. 1989

    JAM virtual machine, about 70 times faster than the Prolog prototype

  3. 1996

    First Erlang/OTP release, R1B

  4. 1998

    AXD301 announced in March; Open Source Erlang released in December

  5. 2021

    Erlang/OTP 24 adds the BeamAsm JIT compiler

Sources11 · facts checked 8 October 2026

Improve this page on GitHub