Channels

[OLUWAMUYIWA]

Hi Ben. I love your clear and simple expositions. They've helped me a lot. I found myself going back into the finished parts of the project I'm working on after discovering your posts. Thank you for always keeping clarity and performance in mind!
I would love to see you write about channels, especially from the POV of an applications developer, that kind of practical view that you always express. Thank you once again!

[benbjohnson]

Thanks! I'm glad to hear it's been helpful. As for channels, I generally don't use them from an application development perspective. I find they're difficult to use and clean up from easily and there's usually better concurrency constructs at the application level. I do use them sometimes for lower level code but many times I'll just use a mutex or wait group or some of the constructs in the sync package.

For application development, I find I use errgroup a lot. I find a lot of concurrency at the application level is for fanning out calls in parallel and errgroup fits that pretty well. Channels can also be used for throttling but there's other higher level constructs like semaphore or a token bucket implementation.

Folks also tend to use channels as a form of queue but their main downside is that they lack persistence. For example, you might want to run a "job" of some sort and if you queue it in a channel then it won't persist across restarts. Many of the uses of channels at the application level end up being moved to something like Kafka or a message queue server that's more robust.

[OLUWAMUYIWA]

Wow! Thank you very much for this clear reply. I'll look more closely into errgroup and the semaphore package. It's the cleaning up that I sometimes find hard to reason about. I'll look into the other options you mentioned and see how they can be of use to me.Thank you once again!