"Like other languages, it has a concurrent queue abstraction, and it has some syntax sugar to make using the concurrent queue nicer than some other languages. B

"Like other languages, it has a concurrent queue abstraction, and it has some syntax sugar to make using the concurrent queue nicer than some other languages. But like other languages, you end up in concurrency hell with mutexes and condition variables and semaphores and deadlocks." It is true that technically, Go does not force good multithreaded code. What it has is good community practices, and libraries that work with those good community practices. And there is a good case to be made that a stronger language (like Rust, or Erlang, perhaps Pony) is still necessary to really make multithreaded code take off. However, if you got yourself caught in "concurrency hell with mutexes and condition variables and semaphores and deadlocks", it is because you weren't programming with the community's best practices. I mean, I know there's a certain vacuity to "just do it right", but in this case, you really didn't do it right. And maybe you would be better off in a language that wouldn't permit you to do it wrong (Erlang, Pony) or a language that tells you to stop it you can't do that (Rust), but there was almost certainly a better way to get it done.