Don't “let it crash”, let it heal

Summary

This is the first of a series on misconceptions about Elixir. These are my opinions. I hope they spark discussion and that maybe we all learn things as a result.A note to the Elixir programmers who commonly say “let it crash”: This phrase gives outsiders and newcomers the wrong idea, and encourages bad habits for those who misinterpret it. If I had my way, we would stop saying it.Elixir runs on the BEAM VM. If you’re familiar, skip to the next paragraph. Otherwise, some necessary context is that on the BEAM, all code is executed in a “process”. This can be thought of kind of like a green thread. Each process is a lightweight, share-nothing unit of concurrency. Processes communicate via message passing. When processes encounter an unhandled error, the process exits. We use supervisors (which are themselves supervised typically), to then restart any given crashed process.When people say “let it crash”, they are referring to the fact that practically any exited process in your application will be subsequently restarted. Because of this, you can often be much less defensive around unexpected errors. You will see far fewer try/rescue, or matching on error states in Elixir code.The “it” in “let it crash” to an Elixir programmer is a process. Not your application. In practice, an Elixir application almost never crashes, even in conditions that would hard-quit in any other system. For those without the context of building Elixir applications, “let it crash” gives the impression of “jank”, of non-elegant code that does not consider user experience or possible failure states. A panic or crash in most languages is a catastrophic event, to be avoided at all costs.Even for Elixir developers with experience, “let it crash” as a practice loses enough nuance so as to be reductive, and I’ve seen it actively impact the quality of code that comes across my desk.First, we’ll talk about why you shouldn’t “let it crash”, and then we’ll talk about what you should do instead.Open a socket ...