‘Let It Crash’ under attack

I can’t go a few days before I see a post about Erlang testing, improving your tests, or making sure your tests cover all your Erlang code.

Now, to be fair, I don’t write enterprise OTP software, nor do I have upper management telling me that nothing will ship until all tests glow green.

With that said, I just don’t understand the obsession with testing in Erlang? Did we lose sight of the essence of Erlang? Or are some of us Erlangutans bored, need to fill in the day with busy-work, and thus spend too much time writing tests in Erlang?

Testing in all its forms

Erlang has property testing, unit testing, dialyzer (static analysis), coverage diagnostics, and integration testing frameworks to name a few.

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

...

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

...

Now, sure, if you were unit testing, you’d catch this, but here, a whole genre of code guarantees (via typing) would fail you, even though advocates of typing turn themselves inside-out insisting that Erlang needs static typing.

‘Let It Crash’

In the early days of Erlang, telecom companies were fined for every minute of down-time that occurred. This culture dictated the design of the Erlang language with a key takeaway being the following: ‘There’s going to be bugs. Better to just have these errors happen in isolation than try to make the systems correct.’

In other words, ‘Let It Crash,’ and let OTP handle the errors as they come up.

(OTP is a lot of things, but one thing it is not is portable to other languages. Just because Erlang can ‘Let It Crash,’ doesn’t mean that language ‘foo’ can simply do the same. Sorry.)

Erlang is different

Tests could be helpful to many code-bases, but I never saw how tests were a necessity in Erlang. When you write clear code with modestly-sized routines, how are tests not just absurd dingleberries in a given OTP project?

Erlang has immutable variables and processes that share nothing (mostly).

With that, global memory is something we never have to worry about as shared state only happens deterministically via sending messages around from process to process.

Moreover, thanks to OTP, Erlang has supervisors that can restart and log buggy code.

So, why all the tests? Are some Erlangutans missing the point of using Erlang?