Ive been writing Go for over a decade and I still feel like I never quite "got" channels. Every time I use them I need to go consult the manual, and none of the patterns feel obvious which is weird considering the rest of the language feels very obvious.
Too many years of Java and managing Threads and Runnables probably rotted my brain.
Channels are honestly one of the most over-used things in Go. I've been writing Go professionally since 2015 and I honestly rarely use them. Programmers new to Go love to shovel them in everywhere because "why use Go if you're NOT going to use channels?" and I have to say sorry, no - write it serially, then determine if it breaches your SLOs, THEN determine if concurrency fixes it.
Using Go since 1.0, agree wholeheartedly. Newcomers read the docs and start throwing channels everywhere because why not.
I always ask/tell people to write without channels, and only add them when you have justification for doing so. That leads to much more sane code.
One pattern I see often because random blogs mention it is starting X long lived goroutines, then passing them data via channels, then receiving responses via channels, then handling. In my experience, it's 100x less error prone to just use a semaphore to start a goroutine per data, and have them do their own handling. No channels involved.
voidfunc · · focus · HN ↗
Too many years of Java and managing Threads and Runnables probably rotted my brain.
vrosas · · focus · HN ↗
silisili · · focus · HN ↗
I always ask/tell people to write without channels, and only add them when you have justification for doing so. That leads to much more sane code.
One pattern I see often because random blogs mention it is starting X long lived goroutines, then passing them data via channels, then receiving responses via channels, then handling. In my experience, it's 100x less error prone to just use a semaphore to start a goroutine per data, and have them do their own handling. No channels involved.