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?

> 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

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".

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.

> pool of workers looking for jobs on a channel

It really feels like the design was driven by this one example only.