> A channel can be buffered or unbuffered Yes, with predictable results. > it can be closed Yes, by the owner/sender, who then understands it as invalid. The

> A channel can be buffered or unbuffered Yes, with predictable results. > it can be closed Yes, by the owner/sender, who then understands it as invalid. The effect of receiving on a closed channel is well-defined and predictable. > and there's different behavior of [recv/send] whether it's in a select or not I don't think that's true? What do you mean? > And you often end up with multiple channels as well Sure! That's part of their power. > Reviewing code with channels is often more confusing than code that uses mutexes I totally agree that goroutines and channels are often over-used by new Go programmers. If what you're trying to do is simply protect concurrent access to some shared state, a mutex is the far better choice.