> The channel [buffer] size needs to match or exceed the number of producing goroutines This is not true, for the reasons I outlined. > The example in the art

> The channel [buffer] size needs to match or exceed the number of producing goroutines This is not true, for the reasons I outlined. > The example in the article is a common issue that comes up in go programs, and the suggested fix is what is usually recommended. That may be, but it doesn't change the fact that go programmers that take this advice are creating a kind of cargo-cult around channels and goroutines that will hold them back. > The other way to solve it would be to read the first error and then up another goroutine to read the remaining error, but that seems more complicated to me. If all you ever do with channels and goroutines is simulate threads, you're missing out. Erlang programmers might more-easily appreciate this given that they have to go through an incredible contortion to get this feature that go provides for free.