So when i first watched the presentation from Rob Pike about Go Concurrency Patterns i was kinda intrigued by channels. I did not really grasp the difference to queues. Most likely because i did not correctly understand the implications of select.

Thanks to all the fuzz about core.async and to David Nolans usage examples for core.async i think i finally got some of it. First Channels mostly behave like blocking queues wiht no buffer (in Java this would be a SynchronousQueue). Go functions are workers which run asynchronously (and behave like they run on a thread pool which i do not have to manage myself, of course other methods of asynchronizity are also possible). Inside of the go function i can access the channel and the code looks like sequential/synchronous access. All blocking and resuming is handled by the system behind it, which as i understand is in the case of Go the Go runtime and in clojure a macro. And finally select/alts allows me to attach a single worker to multiple queues.

• Channels are mostly synchronized blocking queues without a buffer
• Go functions are workers which can look like synchronous access to channels (read and write)
• select/alts! allows me to attach one worker/go function to multiple channels

So in the end the production, transport and consumption of asynchronous messages are all first class citzens in the environment. As always first class citizens, which you can manipulate in every way, open opportunities for awesome reduction of duplication, boilerplate and bullshit in itselfs (That’s why Java feels so bad, because a lot of stuff in the language is not a first-class citizen).

I was always intrigued by queues/executorservices because they decouple a lot and you do not have to worry much, the one thing which i missed the most, now that i know it could be available is select/alts!

For me select/alts! is the most complexity-reducing novelty behind this. Next up i should read the complete CSP book.