4 ms·

This has to be depended on the pipeline you want to have.

• Thaxll 5y ago
  It depends but saying it's very complicated and it's easy to deadlock is pure bs. Where is the complexity in Go to have a pool of workers looking for jobs on a channel exactly?
  • ackfoobar 5y ago
    > Where is the complexity in Go to have a pool of workers looking for jobs on a channel exactly? This is just one kind of pipeline. If this is all you have done, you may have the impression that concurrency (in Go) is easy. BTW, this is worth reading: Understanding Real-World Concurrency Bugs in Go https://songlh.github.io/paper/go-study.pdf https://songlh.github.io/paper/go-study.pdf
    • Thaxll 5y ago
      I know that paper and it's indeed a good one but I still don't agree with OP that "Go concurrency model to be extremely bug prone".
      • BobbyJo 5y ago
        I agree. Pointing out the difficulty of concurrency as a general premise doesn't invalidate Go's model. For the use cases it was designed for (asynchronous services) it's model is probably the best. For use cases it wasn't designed for, it probably sucks.
  • kubb 5y ago
    > pool of workers looking for jobs on a channel It really feels like the design was driven by this one example only.