"One way that Erlang differs from OO languages is its emphasis on failure. Any message can fail. Processes don't raise an exception, they fail. Systems are structured as worker processes at the bottom that are likely to fail, with manager processes above them that restart the failed processes. Because programmers expect processes to fail, they"
hah if it wasnt an intentional joke then its a very good accident.
It helped me tremendously to understand error handling in erlang when I realised every line of code was a point of failure
Java forces you to handle things like FileNotFound even if you fully expect the file to be there, erlang you would not handle file not found at all, but you would manage all errors at a higher level for the entire unit of code that expected the file to be there.
Based on the fact that two other people here apparently didn't finish reading the paragraph either before commenting: if it was a joke, it was a bad one. :)
Yeah... probably a very bad one. I finished the paragraph, but thought the typo was so obvious that OP was asking about the contents really, not the silly silly typo.
No, not a typo or a joke, the mentality of an Erlang programmer is to (and this gets beaten to death in books) "Let it crash." It is ok to let processes fail, you build restart strategies for certain processes so that when they do fail, your supervisors know: how often to try to restart, how many times and of course which module.
If your program gets into a funky state, it's much simpler to trash it and start over, than to try to work backwards to a safe state. Sysadmins know this at the os-process and machine level, Erlang brings it to the language level. Erlang was designed for robustness, concurrency was just a happy side-effect of that focus.
It's likely that the idea was either misunderstood or not expressed properly. That paragraph is kind of true... just written in a very weird way that doesn't really show this process in a good light.
Yes, Erlang embraces failure and provides ways do deal with it by design. No, it's not a replacement for exceptions. Especially that Erlang does have exceptions to deal with the typical "could fail, so we'll just `try` it" programming.
"One way that Erlang differs from OO languages is its emphasis on failure. Any message can fail. Processes don't raise an exception, they fail. Systems are structured as worker processes at the bottom that are likely to fail, with manager processes above them that restart the failed processes. Because programmers expect processes to fail, they"