[apta]

His comment makes sense. golang "goroutines" are finicky compared to other ways of doing concurrency (e.g. Futures/Tasks in Scala/C# or Java's upcoming green threads). There are several reasons to this, not limited to the fact that it's trivial to mistakingly ignore return values (especially errors) when executing `go foo()`. Also, there's a lot of boilerplate involved if you want to start several of them and wait until they're completed, or if you want to compose them. The other languages I mentioned, which have superior abstractions to golang, solve the issue in a much better way.

[Groxx]

I'd also label it that much of go concurrency control is intrusive, in that you need to write control-flow code into whatever it is you're trying to accomplish, or (typically) give up type safety or understandability. That's unavoidably more error-prone than not writing your own control-flow code, and I spend quite a lot of time discovering and fixing issues around it in libraries, even from some very skilled and careful teams.

Of course there are ways to achieve both in any language, but the massive educational pressure of the official docs and tutorials and examples cannot be ignored, and has profound impacts on what the community ends up building in the language.

---

It's roughly equivalent to manual memory management, IMO. Terabytes have been spilled claiming that C is safe if you're careful enough or use safe patterns, and CVE after CVE provides evidence that nobody is sufficiently careful. It has its benefits, but it also has its downsides.