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 si

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.