liveBook · Manning

BEAM

As explained in Elixir in Action, Third Edition

The Erlang runtime system is the execution environment that runs Erlang and BEAM-based applications.

BEAM is the virtual machine and execution environment for Erlang-based systems. It runs compiled bytecode, schedules lightweight Erlang processes across CPU cores, and provides process isolation, messaging, distribution, and responsiveness. Elixir also compiles to BEAM-compatible bytecode and can cooperate with Erlang code. section 1.1.2 section 1.2

BEAM’s operational model addresses production problems directly:

  • Runs thousands or millions of isolated processes that share no memory, so one process crash need not terminate others. section 1.1.2
  • Uses asynchronous message passing instead of locks, mutexes, or semaphores for communication between concurrent entities. section 1.1.2
  • Extends the same process-and-message model across connected BEAM instances, making local and remote process communication location-transparent. section 12.1 section 12.1.2
  • Favors predictable responsiveness over maximum benchmark throughput through preemptive scheduling, frequent context switches, and graceful degradation under load. section 1.3.1

A small distributed BEAM system

Start two named instances with `iex --sname node1@localhost` and `iex --sname node2@localhost`. Connect them with `Node.connect(:node1@localhost)`, then use `Node.spawn/2` to run work on node2 and send `{:response, 3}` back to node1. The same primitives support a clustered to-do service: changes become visible through the other node, and a replacement process can restore state after one node stops. section 12.1.1 section 12.1.2 section 12.2.4

BEAM is part of a broader Erlang/OTP platform rather than an isolated runtime. OTP supplies concurrency, distribution, recovery, packaging, deployment, and live-update patterns; accompanying tools compile code, start instances, create releases, and connect remote shells. Production clusters still require deliberate node naming, cookies, firewall configuration, and netsplit planning. section 1.1.4 section 12.3.2 section 12.3.4

Figure 1.1 Concurrency in the Erlang virtual machine
CH01_F01_Juric3

Use the concurrency diagram to see how BEAM schedulers distribute isolated processes across available CPU cores. section 1.1.2

How Elixir in Action, Third Edition covers it

How deep it goes
Explains schedulers, process isolation, messaging, clustering, and deployment boundaries, while treating full distributed-system design only selectively.
Examples
Uses named nodes, remote spawning, mailbox inspection, clustered to-do servers, remote shells, and standalone releases.
What it assumes
Assumes basic Erlang or Elixir programming and introduces runtime processes, nodes, messaging, and OTP responsibilities.
What you can do after
Operate BEAM nodes, connect clusters, exchange messages, run remote shells, and package standalone releases.
How it connects
Connects Erlang processes, message passing, OTP, Elixir, nodes, GenServer, and distributed-system fault tolerance.

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.