Erlang/OTP

Definition

Erlang/OTP (Open Telecom Platform) is the standard library and set of design principles distributed with the Erlang programming language, providing battle-tested abstractions for building concurrent, distributed, fault-tolerant systems on top of the BEAM virtual machine. It includes generic server and state-machine behaviors, supervision trees for automatic process recovery, and libraries for distribution, hot code upgrades, and application packaging, forming the backbone of production Erlang and Elixir systems.

Overview

Erlang the language provides lightweight processes and message passing as its concurrency primitives, but building a reliable production system out of raw processes alone means solving the same problems repeatedly: how to structure a server process, how to detect and restart a crashed worker, how to package and deploy a running application. OTP is Ericsson's answer to those recurring problems, a curated set of libraries and conventions extracted from years of building telecom systems, distributed as part of the standard Erlang distribution rather than as an optional add-on. Mechanically, OTP's core abstractions are "behaviors," which are generic implementations of common process patterns that a developer fills in with callback functions specific to their application. `gen_server` provides a standard client-server process structure handling synchronous and asynchronous message passing; `gen_statem` provides a state-machine pattern; and `supervisor` implements the process-monitoring logic behind supervision trees, where a supervisor process watches one or more child processes and restarts them according to a configured strategy, such as restarting just the failed child or restarting all siblings together, when a crash occurs. Applications, another OTP concept, package a supervision tree together with startup and configuration logic into a deployable unit, and OTP's release tooling bundles applications, the Erlang runtime, and configuration into a single deployable artifact. OTP is best understood as the layer that turns BEAM's raw concurrency primitives into a production framework, analogous to how a web framework turns a language's HTTP libraries into a structured way to build applications. Its "let it crash" philosophy, deliberately allowing a process to fail rather than defensively coding around every possible error, and relying on supervision to restart it into a known-good state, is a distinctive design stance compared to the general defensive-programming and try/catch conventions common in most other ecosystems. In practice, OTP behaviors are the default way any nontrivial Erlang or Elixir application is structured: web servers, message brokers, and telecom systems are built as trees of supervisors and gen_servers rather than ad hoc processes. Elixir's own frameworks, including Phoenix, are built directly on top of OTP behaviors and conventions, meaning Elixir developers use OTP even when writing no literal Erlang code. The trade-off is a real learning curve: OTP's behavior callback style and supervision-tree thinking require a different mental model than typical object-oriented or purely functional application structuring, and teams unfamiliar with the "let it crash" philosophy sometimes fight it by trying to prevent every possible failure instead of designing for graceful recovery. For workloads that are not fundamentally concurrent or distributed, the overhead of learning OTP's conventions may not be worth it compared to simpler frameworks on other runtimes.

Key Features

• Provides gen_server and gen_statem behaviors for structured process design
• Implements supervision trees for automatic detection and restart of failed processes
• Packages supervision trees into deployable OTP applications
• Includes release tooling that bundles the runtime and configuration together
• Embeds the 'let it crash' philosophy directly into standard library behaviors
• Supports hot code upgrades coordinated through release handling tools
• Provides distribution primitives for clustering multiple BEAM nodes
• Forms the foundation that frameworks like Phoenix build upon

Use Cases

Alternatives

Frequently Asked Questions

Related in Programming