3 ms·

>It makes me wonder if there's an even better abstraction out there which will solve this kind of concurrency bug, and what will arise after these are solved.

>It makes me wonder if there's an even better abstraction out there which will solve this kind of concurrency bug, and what will arise after these are solved. You could go the erlang way, which is to give up. Unexpected concurrency bug? Crash, then restart from a sane state. It's highly effective. Your VM is carved up into failure domains that reduce the blast radius of such a crash to the minimum reasonable collection of processes. This is what frameworks like pony don't get. The reason why erlang actors (aka microservices) are so effective is that they declare, define, and decouple failure domains, and assign responsibility over these failure domains to specific bits of code and ultimately specific teams.

staticassertion 6y ago
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.

staticassertion 6y ago

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.