3 ms·

Completely, 100% agree. I believe this also happens because often the most accessible/obvious form of concurrency is the super problematic "shared data by defa

Completely, 100% agree. I believe this also happens because often the most accessible/obvious form of concurrency is the super problematic "shared data by default" kind (C/C++/Java "Threads"), which is basically ASKING for trouble. Also programming education sometimes even reinforces this in a very harmful way from what I've seen. Telling a student about mutexes/semaphores/atomicity is actively harmful IMO if it is not accompanied by strong discouragement and actual practice in finding subtle race conditions.

Izkata 4y ago
> because often the most accessible/obvious form of concurrency I dunno, I reinvented message-passing concurrency with multiple processes before I knew the terminology or had any formal programming training. It came completely naturally and it was nearly a decade before I understood why people thought concurrency was difficult to get right.
kps 4y ago
Agreed. Many years of effort went into building TSAN because nobody can get shared-memory concurrency right, and whenever someone thinks they can get shared-memory concurrency right, TSAN comes along and proves them wrong. Concurrency needs the same rule of thumb as cryptography: do not try to roll your own.
- galangalalgol 4y ago
  Rust talks about fearless concurrency, and IME, if you avoid async await it does provide it, potentially at a cost of lovks or mutex that might not be strictly necessary for your actual use case. Actually IME async await isn't a problem either but I've read it can be an issue. In C++ the patterns I don't see bugs in is thread pools for processing large batches of heterogeneous data, and fine grained parallelism for stuff like vector and matrix operations. But in the latter case it is all library driven, and in the former, it is a really simple pattern.
  - kps 4y ago
    Yes, these are alternatives to (and/or implemented on top of) shared-memory parallelism, and mostly much better to work with. To continue the cryptography analogy, it's using experts' cryptography libraries. Sometimes you do need to juggle the razor blades yourself (it's not actually turtles all the way down) but it shouldn't be done lightly.
  - ilyt 4y ago
    Barely related rant but I think async/await type of concurrency is the worst of the bunch and outright malady on the code that infected the mass's brain by its proliferation in JS ecosystem. Even crude message passing leads to far cleaner code architecture.

Izkata 4y ago

> because often the most accessible/obvious form of concurrency I dunno, I reinvented message-passing concurrency with multiple processes before I knew the terminology or had any formal programming training. It came completely naturally and it was nearly a decade before I understood why people thought concurrency was difficult to get right.

kps 4y ago

Agreed. Many years of effort went into building TSAN because nobody can get shared-memory concurrency right, and whenever someone thinks they can get shared-memory concurrency right, TSAN comes along and proves them wrong. Concurrency needs the same rule of thumb as cryptography: do not try to roll your own.

galangalalgol 4y ago
Rust talks about fearless concurrency, and IME, if you avoid async await it does provide it, potentially at a cost of lovks or mutex that might not be strictly necessary for your actual use case. Actually IME async await isn't a problem either but I've read it can be an issue. In C++ the patterns I don't see bugs in is thread pools for processing large batches of heterogeneous data, and fine grained parallelism for stuff like vector and matrix operations. But in the latter case it is all library driven, and in the former, it is a really simple pattern.
- kps 4y ago
  Yes, these are alternatives to (and/or implemented on top of) shared-memory parallelism, and mostly much better to work with. To continue the cryptography analogy, it's using experts' cryptography libraries. Sometimes you do need to juggle the razor blades yourself (it's not actually turtles all the way down) but it shouldn't be done lightly.
- ilyt 4y ago
  Barely related rant but I think async/await type of concurrency is the worst of the bunch and outright malady on the code that infected the mass's brain by its proliferation in JS ecosystem. Even crude message passing leads to far cleaner code architecture.