←back to thread

Problems with Go channels (2016)

(www.jtolio.com)
159 points mpweiher | 4 comments | 13 Apr 25 05:43 UTC | HN request time: 1.202s | source
Show context
dingdingdang ◴[13 Apr 25 19:20 UTC] No.43675165[source]▶
If channels are the wrong way to do things in Golang, what is the right way?
replies(1): >>43675386 #
1. fpoling ◴[13 Apr 25 19:55 UTC] No.43675386[source]▶
In Go in many cases channels are unavoidable due to API. As already was pointed out in other threads a good rule of thumb is not to use them in public method signatures.

The valid use case for channels is to signal to consumer via channel close in Context.Done() style that something is ready that then can be fetched using separated API.

Then if you need to serialize access, just use locks.

WorkGroup can replace channels in surprisingly many cases.

A message passing queue with priorities implemented on top of mutexes/signals can be used in many cases that require complex interactions between many components.

replies(1): >>43676393 #
2. dingdingdang ◴[13 Apr 25 22:44 UTC] No.43676393[source]▶
Cheers for clear summary, I take it you mean sync.WaitGroup and not WorkGroup? As a beginner I started up with WaitGroup usage years ago since it was more intuitive to me.. worked fine afaict.
replies(1): >>43678195 #
3. fpoling ◴[14 Apr 25 04:58 UTC] No.43678195[source]▶
Yes, WaitGroup of cause.
replies(1): >>43699866 #
4. pdimitar ◴[15 Apr 25 23:59 UTC] No.43699866{3}[source]▶
I am here to lengthen your suffering: of course**