La filosofía let-it-crash

Most languages encourage catching every possible error. Erlang takes the opposite view: let it crash. A process that hits an unexpected state should die and be restarted into a known-good state.

A crash is a clean, well-defined failure. Trying to limp along in a corrupted state often causes worse, harder-to-debug problems later.

Erlang processes share nothing. One crashing process cannot corrupt another's memory, so a failure stays contained.

Because supervisors handle failures, you write only the success case. No tangle of defensive checks.

The match {ok, Data} = fetch(...) doubles as an assertion: if fetch returns anything else, the process crashes immediately rather than continuing with bad data.

A supervisor (covered earlier) watches workers and restarts them per its strategy. Let-it-crash works because supervision provides recovery.

Keep risky operations in worker processes that may crash, while a stable supervisor process holds the recovery policy. This separation keeps both simple.

Expected, recoverable conditions (a user typing a bad value) are not exceptional. Handle those normally; crash only on truly unexpected states.

A runtime error (like a failed match) crashes the process with reason {badmatch, ...}. You can also crash deliberately with exit/1 to signal an unrecoverable problem.

When a process dies, OTP logs a crash report with the reason and stack. SASL and logger capture these so failures are observable even though you did not catch them.

Let-it-crash plus supervision yields systems that self-heal from transient faults and stay running for years. Code is smaller, clearer, and focused on the real work.

You learned the let-it-crash philosophy.

• Crash on unexpected state instead of coding defensively
• Process isolation contains failures
• Supervisors provide recovery
• Still handle expected, recoverable cases normally