4 ms·

To me it sounds like Erlang's biggest departure from the mainstream is http://c2.com/cgi/wiki?LetItCrash http://c2.com/cgi/wiki?LetItCrash, casually letting pro

To me it sounds like Erlang's biggest departure from the mainstream is http://c2.com/cgi/wiki?LetItCrash http://c2.com/cgi/wiki?LetItCrash, casually letting processes die and be recreated. When I put effort into actually using a niche language (as opposed to merely learning it for fun) I expect it to enable me to write software that's less embarrassingly defective than everyone else's, where Erlang only seeks to reduce the pain from my doing bad work.

Jtsummers 13y ago
Let it crash isn't about having the program crash, it's about the processes. It's a vocabulary issue for a lot of people, however. In erlang your program consists of multiple concurrent processes (well, that's the intention at least). When an individual process fails (say it's a parser and has been given bad input), the erlang way is to fail and let the supervisor/spawner figure out the corrective action. It's the same question we face when writing in java/c#/etc languages with exception handling. Where do I catch the exception? A search example. You have several search algorithms given your input. Run all in parallel, if they crash it's fine. If all crash then the search was a bust, but if one succeeds you terminate the remainder and have your answer.
bjourne 13y ago
That doesn't mean you shouldn't handle errors if you can. However, there are always more errors and coding bugs left than what you think. Systems with 0 bugs just doesn't exist in the real world. So if you are writing a critical system that is supposed to run 24/7 and your code encounters a "one in a million" bug that got through testing, such that a obscure race condition or something, then to handle it the best strategy is to reset the involved processes and try again. It's Erlang's answer to the question "What if there is a bug in the system?" Most languages doesn't answer it ("just dont write buggy code!") but Erlang does and tries to come up with a reasonable solution.

Jtsummers 13y ago

Let it crash isn't about having the program crash, it's about the processes. It's a vocabulary issue for a lot of people, however. In erlang your program consists of multiple concurrent processes (well, that's the intention at least). When an individual process fails (say it's a parser and has been given bad input), the erlang way is to fail and let the supervisor/spawner figure out the corrective action. It's the same question we face when writing in java/c#/etc languages with exception handling. Where do I catch the exception? A search example. You have several search algorithms given your input. Run all in parallel, if they crash it's fine. If all crash then the search was a bust, but if one succeeds you terminate the remainder and have your answer.

bjourne 13y ago

That doesn't mean you shouldn't handle errors if you can. However, there are always more errors and coding bugs left than what you think. Systems with 0 bugs just doesn't exist in the real world. So if you are writing a critical system that is supposed to run 24/7 and your code encounters a "one in a million" bug that got through testing, such that a obscure race condition or something, then to handle it the best strategy is to reset the involved processes and try again. It's Erlang's answer to the question "What if there is a bug in the system?" Most languages doesn't answer it ("just dont write buggy code!") but Erlang does and tries to come up with a reasonable solution.