> they don’t really seem to solve the problems I have with concurrency. They feel like baked-in message queues. You’re right about the baked in message queues.

> they don’t really seem to solve the problems I have with concurrency. They feel like baked-in message queues. You’re right about the baked in message queues. But that’s actually one of the key ingredients to designing simple scalable concurrent architectures. Once you get the message queues right, it factors away the concurrency primitives you normally would have to work with, such as critical sections and mutexes. This is demonstrated in the two references below. The message queue design is simple and yet crucial to making the simple scalable designs. Alan Kay said “The key in making great and growable systems is much more to design how its modules communicate.” The two references below explain how Go approaches concurrency in a way that makes it easier. 1. Don't communicate by sharing memory. Share memory by communicating. 2. There’s an amazing video with Rob Pike explaining how to produce concurrent designs that are simple and scale. Message queues is one of the 3 major components. [1] https://blog.golang.org/share-memory-by-communicating https://blog.golang.org/share-memory-by-communicating [2] https://youtu.be/cN_DpYBzKso https://youtu.be/cN_DpYBzKso