An Erlang process is a userland construct, but unlike “green threads” (e.g. goroutine, tasks, …) they have little to no shared memory, and the language is built

An Erlang process is a userland construct, but unlike “green threads” (e.g. goroutine, tasks, …) they have little to no shared memory, and the language is built around immutable values. Erlang’s “let it crash” philosophy is based around supervision trees, where a system is composed of a number of (erlang) processes, with “supervisors” overseeing worker processes, and worker crashes are automatically reported to the supervisors. As such it is common to do little to no error handling in workers, instead the worker crashes and the supervisor handles the error condition. This is nothing you couldn’t do in other languages, but because the entire thing is built into the language and the runtime, and includes tooling to make structuring an application that way easier (“behaviours”), it’s very normal to build Erlang applications that way. This further extends to entire machines.