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.

Processes are in Erlang terms are lightweight threads. So when a "process" crashes, that's not the whole system crashing.

Learning a bit more than “absolutely nothing” about Erlang would make a conversation more productive. The Wikipedia page [0] has some material relevant to your question under the “‘Let it crash’ design philosophy” heading.

[0]https://en.m.wikipedia.org/wiki/Erlang_(programming_language...

I think by crash they mean program stopping execution and being unable to continue, so by that metric Erlang didn't fully crash.

Erlang is designed with a mechanism that makes it easy for external processes to monitor for crashes (or hardware failures), rather than an in-process mechanism like exception handling used in many other programming languages.

Erlang was designed with the aim of improving the development of telephony applications.

The Erlang runtime system provides strict process isolation between Erlang processes (this includes data and garbage collection, separated individually by each Erlang process) and transparent communication between processes on different Erlang nodes (on different hosts).

The "let it crash" philosophy prefers that a process be completely restarted rather than trying to recover from a serious failure. Though it still requires handling of errors, this philosophy results in less code devoted to defensive programming where error-handling code is highly contextual and specific.

Erlang has its own notion of process — the comment should be understood as equivalent to “when running Typescript, some Promises could error and be restarted without the software crashing”.

The idea behind Erlang’s error handling is that completely avoiding crashes and errors is practically impossible, so the language is designed to gracefully handle crashing "processes" (lightweight threads) and restarting them instantly without the rest of the software being affected. It doesn’t mean the entire program crashes, in fact that’s what this approach prevents.

"but it literally does crash and restart" No, think of it not as blue screening and reboot, but as a form of automatic error detection and handling. This keeps the system up and responsive, even if unrecoverable errors happen.