liveBook · Manning

Erlang

As explained in Elixir in Action, Third Edition

Erlang is a general-purpose development platform for building scalable, concurrent, distributed, fault-tolerant, and highly available systems.

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

Figure 1.1 Concurrency in the Erlang virtual machine
CH01_F01_Juric3

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

How Elixir in Action, Third Edition covers it

How deep it goes
Explains processes, message passing, BEAM scheduling, platform components, and trade-offs, but stops short of comprehensive language-reference coverage.
Examples
Uses a gen_server addition example, production web-server requirements, and comparisons between Erlang concurrency and microservices.
What you can do after
Evaluate Erlang for highly concurrent services and understand how BEAM processes, OTP, and distribution address production failures.
How it connects
Connects Erlang with BEAM, OTP, concurrency, message passing, fault tolerance, distribution, high availability, server-side systems, and microservices.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Elixir in Action, Third Edition. The section links point to the parts of the book it draws on.