Hacker News Reader

Comment by SEMW | Hacker News Reader

In the context of the blog post - Erlang - "Let it crash" almost never means "let the entire application crash". It means "let the current [micro-]process crash, then its supervisor will restart it in a known-good state" (and if the supervisor crashes then its supervisor will restart it, and so on).

View on HN

> and if the supervisor crashes then its supervisor will restart it, and so on

Enough of this and it will crash the node. You need to design for this in an Erlang system.

The ever-helpful jlouis has some useful writing on the subject: http://jlouisramblings.blogspot.it/2010/11/on-erlang-state-a...

As well as these: https://github.com/jlouis/fuse

Sadly, this is not discussed as much as it should be in Erlang land.

I agree. AKKA is doing the same in the JVM. Letting an app to crash doesn't mean "crash the whole system", but just a process. It's very handy when dealing with a lot of parallelism and asynchronous code, sometimes is better leave a process to crash instead of trying recover it with error handling. Obviously is not always the case, but for some processes, the crash and a later recover by the system is a better solution in terms of performances, system state and logic.

That's very interesting information. The article itself doesn't say much Erlang specific so I didn't even put it in that context. But you are right, the article is an Erlang article. Thanks for the Erlang lesson!

Reply on news.ycombinator.com