4 ms·

Reading your comment made me think of Erlang, where the guiding principle is the opposite: large systems will contain errors, and will fail. That is what fault-

by erikbye 10y ago

Reading your comment made me think of Erlang, where the guiding principle is the opposite: large systems will contain errors, and will fail. That is what fault-tolerant is, you design your software (language, libraries and end program) in a way that will handle unforeseen errors and failures. Because in large systems there will always be bugs. http://erlang.org/download/armstrong_thesis_2003.pdf http://erlang.org/download/armstrong_thesis_2003.pdf

enqk 10y ago
That does sound rather interesting! (And anti-fragile, to use a talebian neologism)
- oldsj 10y ago
  Possibly, but is the system getting stronger on each failure(like a human muscle), or is it just recovering?
  - erikbye 10y ago
    It's resilient and fault-tolerant. Not antifragile according to Taleb's definition. Though, no reason you could not spawn 2 (or more) new processes for every 1 that crash.
staticassertion 10y ago
I'm also a fan of this approach, and am currently learning Erlang because of it. However, I do not feel that the approaches are exclusive. Erlang is dynamically typed and it is robust because Actors act as isolation boundaries and are managed by supervisors. So the approach is "bugs happen, always recover". You can also use type annotations in Erlang to get "bugs happen less, always recover".
- erikbye 10y ago
  Perhaps not mutually exclusive, all programmers try to introduce as few bugs as possible; but the philosophy is in fact "let it crash", then you reset to a stable state. Not only is the programmer unburdened of the cognitive load of trying to imagine every single point of failure, but also of the workload of a lot of defensive programming. The whole reasoning behind this is what I said before: in large systems there will always be bugs, errors and failures will happen (some even outside of your code, e.g. power failure). Imagining every point of failure is impossible, so don't try to. Don't write preemptive code. Yes, Erlang is dynamically typed, but not weakly typed.

by erikbye 10y ago

enqk 10y ago

That does sound rather interesting! (And anti-fragile, to use a talebian neologism)

oldsj 10y ago
Possibly, but is the system getting stronger on each failure(like a human muscle), or is it just recovering?
- erikbye 10y ago
  It's resilient and fault-tolerant. Not antifragile according to Taleb's definition. Though, no reason you could not spawn 2 (or more) new processes for every 1 that crash.

staticassertion 10y ago

I'm also a fan of this approach, and am currently learning Erlang because of it. However, I do not feel that the approaches are exclusive. Erlang is dynamically typed and it is robust because Actors act as isolation boundaries and are managed by supervisors. So the approach is "bugs happen, always recover". You can also use type annotations in Erlang to get "bugs happen less, always recover".

erikbye 10y ago
Perhaps not mutually exclusive, all programmers try to introduce as few bugs as possible; but the philosophy is in fact "let it crash", then you reset to a stable state. Not only is the programmer unburdened of the cognitive load of trying to imagine every single point of failure, but also of the workload of a lot of defensive programming. The whole reasoning behind this is what I said before: in large systems there will always be bugs, errors and failures will happen (some even outside of your code, e.g. power failure). Imagining every point of failure is impossible, so don't try to. Don't write preemptive code. Yes, Erlang is dynamically typed, but not weakly typed.