4 ms·

I agree with all of your post except for the premise - concurrency bugs won't necessarily lead to a crash, but often just a bad result.

• dnautics 6y ago
  that's not the premise. Maybe I should reframe it this way: you should detect inconsistent results and use "crash" as a strategy to restore consistency. Also of importance is to log these events and work towards fixing the concurrency bug by addressing the root cause in the long run with application monitoring.
  • staticassertion 6y ago
    Ah, ok sure.
  • senderista 6y ago
    That’s one thing about Erlang that took me too long to grok: “let it crash” applies to bugs, not expected errors.
    • dnautics 6y ago
      Haha also i guess you might also decide that correctness is unimportant. How often does this bug happen? Is it a once-a-week thing with no user-facing effect? Just let it ride until you're scaling hard. Your labor as a programmer is expensive, no need to chase down every possible bug.
  • yencabulator 6y ago
    But that is then again just sweeping bugs under the rug. The fact that you haven't detected an invalid state doesn't mean you haven't corrupted data. You need tooling that helps to avoid the corruption, not tooling that sweeps it under the rug. Erlang's crash-on-trouble style is ok if 1) your design only loses "one phone call" on a crash (and not anything more persistent or valuable) and 2) you're willing to lose that "phone call" every now and then.