[rastignack]

I don’t think channels and goroutines suck. For example their usage in golang’s ssh server implementation is eminently readable.

And performant enough.

Engineers ship with them, and do not care if there’s a purer system elsewhere.

[jeeyoungk]

Definitely agree that goroutines don't suck; it makes go into one of the only languages without "function coloring" problem; True N:M multithreading without a separate sync and async versions of the IO libraries (thus everything else).

I think channels have too many footguns (what should its size be? closing without causing panics when there are multiple writers), thus it's definitely better "abstracted out" at the framework level. Most channels that developers interact with is the `Context.Done()` channel with <-chan struct{}.

Also, I'm not sure whether the go authors originally intended that closing a channel would effectively have a multicast semantics (all readers are notified, no matter how many are); everything else have pub-sub semantics, and turns out that this multicast semantics is much more interesting.

[binary132]

The answer to your question is zero, unless there is a compelling reason for it to buffer, and if there is you’ll know it.

Non-buffering channels are much simpler to reason about and have very useful semantics in pipelines.