4 ms·

> Frankly, most 35 y/o engineers don't truly appreciate the intricacies of intra-thread concurrent algorithms, unless it's their specialized area. Frankly thos

• AndrewKemendo 4y ago
  Knowing that though only comes from having an understanding of the uses and limitations thereof
  • ilyt 4y ago
    Yeah, it's way too easy to get some new knowledge then just use it everywhere you can because you want to play with your newly gained skill, instead of dozing it in only where it is beneficial. I've created many spaghettis because of that before I realized that.
• myrmidon 4y ago
  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.
• ReflectedImage 4y ago
  Rust is really good at this sort of thing.
• 698969 4y ago
  > If I have a choice of making single job faster vs just running 64 jobs in parallel on CPU I'd pick the second every time I can because code will be simpler and less buggy every single time. I maybe misunderstanding what you're trying to say, don't you mean you'd pick the first one every time? Make the single job faster instead of introducing concurrency with 64 parallel jobs?
  • myrmidon 4y ago
    I think he is arguing in favor of multiple concurrent processes ("single thread each"), instead of messing around with low-level threads + synchronization primitives (which would achieve a single fast process that uses multiple CPU cores by itself).
• elwell 4y ago
  Or just use Clojure and slap a `p` on your `map` function.