English for Erlang Developers

Erlang conversations revolve around a concurrency model that looks alien to developers coming from thread-based languages, so the vocabulary centers on isolated processes, fault recovery, and explaining why crashing is often the correct behavior rather than something to prevent at all costs.

Key Vocabulary

Let it crash — the Erlang philosophy of allowing a process to fail immediately on an unexpected error instead of defensively catching every exception, relying on a supervisor to restart it into a known-good state. “We stopped wrapping every call in try/catch and adopted let it crash — the supervisor restarts the process faster than we could have recovered it manually.”

Supervision tree — the hierarchical structure of supervisor and worker processes that defines restart strategies, so that a failure in one branch is contained and repaired without affecting unrelated parts of the system. “The supervision tree only restarted the failing worker, so the rest of the application kept serving requests during the incident.”

Message passing / mailbox — the mechanism by which Erlang processes communicate exclusively through asynchronous messages delivered to a per-process mailbox, with no shared memory between processes. “Since there’s no shared state, all coordination happens through message passing — each process just reads from its own mailbox.”

Hot code swapping — the BEAM’s ability to load a new version of a module into a running system and migrate live processes to it without stopping the node or dropping connections. “We shipped the fix via hot code swapping, so the telecom switch never went down during the deploy.”

Process isolation — the guarantee that each lightweight Erlang process has its own memory and garbage collector, so a crash or memory spike in one process cannot corrupt or stall another. “Process isolation is why one misbehaving connection handler doesn’t drag down the other ten thousand connections on the node.”

Common Phrases

• “Should this error be handled defensively, or is this a case where we just let it crash?”
• “What’s the restart strategy for this branch of the supervision tree — one-for-one or one-for-all?”
• “Is this state coordinated through message passing, or are we accidentally sharing something?”
• “Can we ship this fix with hot code swapping, or does it require a full node restart?”
• “Are we actually relying on process isolation here, or did we introduce a shared resource?”

Example Sentences

Explaining a design decision to a teammate: “We deliberately let it crash on a malformed packet instead of trying to parse around it — the supervision tree handles the recovery.”

Reviewing an incident postmortem: “Process isolation contained the fault to a single connection handler, which is exactly why the outage only affected one customer instead of the whole node.”

Describing a deployment strategy: “Hot code swapping let us patch the billing module during business hours without dropping a single active call.”

Professional Tips

• Explain let it crash as a strategy, not negligence — it only works because of the supervision tree behind it, so always mention both together.
• Use supervision tree when discussing failure blast radius — naming the restart strategy (one-for-one vs one-for-all) shows you understand containment, not just recovery.
• Reach for message passing when someone assumes Erlang has shared mutable state — it’s the fastest way to correct a common misconception from thread-based backgrounds.
• Mention hot code swapping carefully in interviews — it’s a genuine BEAM differentiator, but be ready to explain its operational risks, not just its benefits.

Practice Exercise

1. Explain the “let it crash” philosophy and why it depends on a well-designed supervision tree to be safe.
2. Describe how message passing and process isolation together eliminate a whole category of concurrency bugs.
3. Write two sentences describing a scenario where hot code swapping would be valuable in production.