Erlang is a general-purpose development platform for server-side systems that must remain responsive, scalable, distributed, fault-tolerant, and highly available. It targets operational problems such as rising load, component failures, dropped connections, hardware crashes, and software upgrades without requiring system-wide downtime. section 1.1 section 1.1.1
Use the concurrency diagram to see how BEAM schedules isolated Erlang processes across available CPU cores. section 1.1.2
Erlang addresses system-level demands through several connected mechanisms:
- Runs thousands or millions of lightweight Erlang processes rather than relying primarily on heavyweight operating-system threads or processes. section 1.1.2
- Isolates process memory, so one process can crash without directly crashing its peers; failures can then be detected and replacement processes started. section 1.1.2
- Communicates through asynchronous messages instead of shared memory and locks, simplifying coordination among concurrent activities. section 1.1.2
- Uses the same process-communication model locally and across remote BEAM instances, supporting distribution and horizontal scaling. section 1.1.1 section 1.1.2
- Keeps performance predictable through preemptive scheduling, frequent context switches, graceful degradation, and expansion across additional hardware. section 1.3.1
The platform has four parts: a functional language with concurrency primitives, the BEAM virtual machine, the general-purpose OTP framework, and cross-platform tools. OTP supplies established patterns for concurrency, distribution, error recovery, packaging, deployment, and live code updates. section 1.1.4
A concurrent server process
A small server process can encapsulate state and respond to messages; the Erlang implementation for adding two numbers uses gen_server callbacks for startup, calls, casts, informational messages, termination, and code changes. The pattern is verbose, but it exposes the production structure behind a concurrent service. section 1.2.1
Erlang suits systems that serve many clients while managing background work, long-running requests, shared in-memory state, persisted data, and crash recovery. Its fine-grained process model offers stronger isolation than using a small number of microservice processes, although CPU-intensive workloads and ecosystems requiring abundant libraries may favor other technologies. section 1.1.3 section 1.1.5
