An analogy: The BEAM process model is to "developers know what they are doing" as the Rust borrow checker is to "C developers know how to write memory safe code."

In other words, your program will have bugs. Your program will not correctly handle every failure mode. Your program will fail. The BEAM process model makes it so that a failure in one process won't take down all processes. And furthermore, after a process fails, there's always a deterministic way to recover from that failure without you the programmer having to think about it too hard.

The system is so robust that having processes fail on error conditions is encouraged. Once you really internalize this "let it crash" way of thinking and writing code, you only program for the happy path and let the process system handle the rest. The code ends up being much shorter and easier to understand. It's the complete opposite of writing code in something like Go, or I imagine Rust, where you explicitly handle or punt every error you can think of at every step.

And interestingly enough, despite not handling errors at every step, the share-nothing process model ends up being much more resilient in the face of errors.

Note that Rust does not have green threads (RFC 230: https://github.com/rust-lang/rfcs/blob/master/text/0230-remo...), so without using the coroutine crate (which most developers don’t know how to use; the truth is that most people don’t know how to use threads).

The features that I talked about have nothing to do with preventing out-of-memory errors—they don’t really help with that. For non-external resources, the features described prevent memory contention (no shared memory).

Much like it’s hard to understand the Rust borrow checker quickly, the "example" you’re asking for is not possible in a comment on HN. I recommend looking over Joe Armstrong’s thesis, for which I provided you a link.