This is a curious misunderstanding of what “let it crash” means.

“Let it crash” is the observation that if something unexpected, maybe spurious happens in a distributed, ever-changing system, it’s a good approach to crash the unit of work in a structured way and have the supervisor of that unit figure apply a strategy. e.g. if you are connecting to a socket, doing some work and then close - and the connection doesn’t work, the task should crash. The supervisor could then retry 3 times and then propagate the error. It’s a philosophy for error handling and structuring errors in a concurrent system, at far more high level then the example in the code.

That approach is very inspired from how init systems are doing things. Say, you run a cleanup task using your init system - it fails once because of a spurious connection error. The init system tries it 5 more times. If it fails 5 times, it then marks the task faulty. Same philosophy: your init system is a supervision system.

“Let it crash” does not mean “your code can be faulty”, it encourages crashing as a strategy for handling of spurious, hard to predict errors.

To summarise as fairly as I can: the author sees people trying to write correct code via unit testing. They are puzzled by this because Erlang isn’t supposed to be correct, it’s supposed to have bugs and then do some work to isolate those bugs, to be able to crash but the whole system keeps mostly running in the face of that crash.

But like… wouldn’t you like to do both? Not have the bugs, and also safely crash when you have the bugs? I can’t tell if this is meant to be ironic or not.

There’s some truth to this: ‘let it crash’ does in general decrease the cost of a programming error, and it does shift the cost/benefit curve of writing tests.

As a practical example of this, when someone writes a new assist/fixit for rust-analyzer, the bar for testing is really low: just a couple of “happy path” tests. Assists are often contributed by non-core contributors and are a fiddly thing to write, so they often contain bugs and trigger panics at runtime. This isn’t a problem though, as, by design of the whole system, buggy assists can’t corrupt any data, and the faults in them are isolated (imperfectly, as Rust lacks true let-it-crash infrastructure). This is appropriate approach, because this allows us to quicker deliver 80% feature to the user, and also encourages contribution.

That being said, I don’t think that “decreasing programming errors” is the primary benefit of the tests. My response here is the same as to some lispers’ claim that “REPL is a substitute for tests”. The bulk of value of tests in typical programs comes from preserving programs behavior over time, when the code of the program itself changes. It’s not “is my code correct”, it’s “does this change accidentally break something else”. For this, let it crash doesn’t really help.

“let it crash” is recognized as being perfectly acceptable in any safe language, because the safe option to take in the face of something unexpected happening is to stop. This is not unique to Erlang. Rust does this. Haskell does this. Hell this is the approach webkit takes and that’s C++. Sure, the environment Erlang operates and its common usage means that you idiomatically write code knowing that it is possible for errors to occur unexpectedly, and to make sure that the system as a whole isn’t taken out by a failure in one component, but “things can crash, deal with it” is far from unique.

No part of “let it crash” means “don’t worry about writing correct code, we’ll find it in production”.

But let’s be honest, the core concept of the post - “requiring tests is an attack on ’let it crash;” - is nonsense. There is a world of difference between “the code is wrong” and “the code crashes”, and pretending that testing is solely the latter is bizarre.

Finally, the example:

maybe_write() ->
    {ok, U} = file:open("/path/to/file.txt", [write]),
    file:close(U),
    ok = file:write(U, <<"foo">>),
    ok.

You are correct, no amount of analysis would detect this error. That’s why you use your type system to ensure that this code would not even compile. Though I am loathe to do it let’s imagine trying in rust - rather than any horrific C++ horrorscape using forced moves :D

fn main() -> Result<(), std::io::Error> {
  let mut file = File::create("/path/to/file.txt")?;
  drop(file); // The closest option to explicitly closing a file
  write!(file, "wat")?;
  return Ok(());
}

this does not compile because closing/“dropping” the file consumes the ownership and so subsequent usage is an error. Obviously idiomatic rust that wanted to force earlier closing would probably just create a scope, which would make it more overtly obvious that what was being attempted wasn’t possible.

Let it crash means the beam system tolerates program failure and is unlikely to take the whole runtime down. It does not guarantee the program will be usable when it’s constantly crashing. I’m failing to understand the point they’re trying to make. Do they advocate fixing bugs on the go watching crashes? That doesn’t work if the program has users or interfaces with programs that have users. My unsolicited advice is stop looking for excuses and test your programs. You will gain confidence applying patches. Then crash whenever there’s really nothing left to do or you want to make a firm assertion preventing the execution from proceeding. And test that too.

But with all that, as Joe Armstrong once jeered, no amount of type checking would catch the following bogus code:

It is worth to note that the stated problem, of accessing a file after it is closed was addressed in the Phd thesis by Joe Armstrong in which he suggested a solution for exactly this problem by introducing a new testing & development methodology he named “protocol checkers” (9.1 Protocols, page 195). Relevant quote from the thesis:

Given a protocol which is specified in a manner similar to the above it is possible to write a simple “protocol checking” program which can be placed between any pair of processes.

The protocol is a state machine, which would detect the attempt to write to a file after it was closed.

Tangential, but “Erlangutan” is absolutely my favorite name for members of a programming language community, and I thought “Rustacean” would be impossible to beat.

Also, there should be a word for these words. Maybe “daemonym” as a pun on “demonym” and “daemon” as a CS term?

I always found the “Let it crash” very convincing. One of the most convincing talks I know is not even about Erlang. But I’ve never actually coded anything substantial in either Erlang or Elixir myself. I went the other way instead with Rust and static typing.

But I’m curious, for those of you who do work on such systems, does it deliver on its promise? Is it simpler? More robust? And is modern Elixir done in the same vein of “Let it crash” and very few tests or verification?

The author feels like something is off, but can’t quite put their finger on it. They try to tie test culture to the language, claiming erlang is different. But I think the main diference is the mindset. The technical means to let it crash were perfected in erlang, no doubt, but the principle could stand for any programmer.

Testing as a religion is the direct negation of a culture of thriving to produce well written code and well architected software. Instead, fewer people look at the code or analyse it critically, we just throw test coverage at it. Management assess software quality and engineering skill by direct measuring test coverage. “John doe is such a great engineer, he always writes tests”.

Testing histeria boils down to impose the principle that any code is equally well written and equally error prone. And the only mitigation strategy is writing tests. This is a quite obvious mix of non sense and mediocrity culture. Of course we should thrive to write code with as few errors as possible, as in any other job. An accountant doesn’t open excel every day thinking he is randomly going to mix up all the salaries of his fellow employees. He knows he, like anyone else, can make mistakes and can even have a double check routine, but of course he thrives to not make those mistakes, naturally.

IMO, the sweet spot for testing in Elixir and Erlang is “Does the pretty path work?” and “If this section fails, does it do so elegantly?” I’ve definitely seen over-tested Elixir code, but no tests just means you end up doing tedious by-hand testing. So the example the author gave should definitely be caught by testing, because that functionality is just strictly absent from the program now, but you don’t need to crawl down every combination of branches trying to find every failure condition. Just have a test that murders the process and make sure the failure state is acceptable.

My (admittedly outsider) understanding of ‘let it crash’ is:

• You can never anticipate every failure mode of a complex system
• Thus, for reliability, you must be robust in the face of unknown failures

Testing is largely orthogonal to this - it’s largely intended to interrogate correctness. You (ideally) write tests which make assertions about the behavior of the code under test, which allows you to make inferences about known properties of the code, so that things like refactors can be assessed for whether these properties are maintained, or to prevent undesirable outcomes regressing, etc.

Take the cited code snippet from the article:

maybe_write() ->
    {ok, U} = file:open("/path/to/file.txt", [write]),
    file:close(U),
    ok = file:write(U, <<"foo">>),
    ok.

As the author notes, unit testing does catch this failure (assuming correctly written tests are present), which is dismissed in favor of discussing the failure of static typing to catch this issue (itself a contentious point, but one for another time). However, “let it crash” does not enhance the correctness of the application here - it allows the failure to be isolated to whatever process made this problem, but the code does not work correctly, and usually customers are still annoyed if the application loses data, even if it didn’t crash catastrophically in the process.

This article seems a little dismissive - just because “let it crash” means Erlang applications can be robust against failure, it doesn’t mean you shouldn’t be taking steps to guard against knowable failures.