[erlang-questions] Question about Erlang and Ada

Richard Carlsson carlsson.richard@REDACTED
Tue Dec 15 10:49:34 CET 2015

> I still insist that there is need for both: "let it crash" and "correct by
> construction". You wouldn't want to let your fly-by-wire system controller
> crash during landing, one meter above the runway. But you also wouldn't
> want to build a correct feature poor in-flight entertainment system.

If restarting is fast enough (e.g. sub-millisecond), then yes, I do want
the fly-by-wire system controller to crash and get back to a clean state,
rather than make a poor guess at what to do to fix the problem, or lock up.

The adage "let it crash" doesn't mean you're allowed to write sloppy
incorrect code in a mission critical system. It just means that 1) Very few
complicated programs are ever completely correct (both in implementation
and specification) and complete (prepared to handle all situations that may
occur in production), 2) When an unexpected error occurs, the code itself
will typically not know what to do to correct the problem, and any attempts
at doing so may just mask the problem or make things worse.

It is then best to let it crash - under the assumption that you have a
supervisor or heart that can restart the failed subsystem so that it can
resume its work. (Or for offline systems, you can restart it manually after
checking the logs.) Parts of the program state may need to be stored
persistently (e.g. in Mnesia) in order to survive a restart - for a flight
controller, the last known position and velocity would probably be good to
have - but the more you make persistent, the greater the risk that a
corrupted state will not be fixed by the restart.

So yes, both are good to have, but don't trust "correct by construction"
too much, and don't underestimate how many situations a clean quick restart
can fix.

    /Richard C
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20151215/92d2370a/attachment.htm>

More information about the erlang-questions mailing list