[erlang-questions] Let it crash + side effects

[Garrett Smith]

On Thu, Mar 7, 2013 at 4:14 AM, Tyron Zerafa <tyron.zerafa@REDACTED> wrote:
> Erlang is impure, functions do have side effects. So how does exactly the
> let it crash philosophy fit in Erlang?
> As far as I know Erlang does not employ any kind of atomic actions or roll
> back mechanisms. What is the best course of action to take for a failing
> function which has side effects?

The best course, I suspect, is to avoid cases where inconsistency
resulting from a failed function will hurt you.

It'll be easier to think about if you have some examples.

But in general, I take this approach:

- Processes worry only about a narrowly defined set of requirements
(external state) and ignore everything else

- If the narrow set of requirements aren't met, the processes refuse
to continue (crash)

- Use other processes to monitor and clean up external state, putting
things in order as needed by other processes

I like to think of the last point as a "cleanup crew" pattern. With
processes focused on routinely cleaning up messes, your primary worker
processes can simply and happily forget about making things right on
failure. The worker processes just do their thing, when they can.

A couple of illustrative operating system patterns:

- Log rotation -- loggers write stupidly to a file, not worrying about
disks filling up -- someone else solves that

- /tmp cleanup -- users of temp file systems just write and leave crap
sitting around -- someone else cleans those up

Operating systems use this "cleanup crew" pattern so extensively, it's
a wonder it's not more established in programming circles!

What's nice about Erlang is that you can spin a cleanup crew process
up very easily. I use e2 tasks for this:

http://e2project.org/tasks.html

Garrett