People are missing a key insight about channels, which is that close is a write. Typically, you want one piece of code reading, and another piece of code writi

People are missing a key insight about channels, which is that close is a write. Typically, you want one piece of code reading, and another piece of code writing, and that's where their code goes wrong. A panic is appropriate in this case, as it's always a bug. The underlying feature that people are looking for is a TCP-like "either side can kill the other side" feature. This is what contexts are. func read(ctx context.Context, c <-chan any) { for { select { case <-ctx.Done(): return case x, ok := <-c: if ok { fmt.Println(x) } else { return } } } } func write(ctx context.Context, c chan<- any) { for i := 0; i < 10; i++ { select { case <-ctx.Done(): close(c) return case c <- i: } } } In this example, the type system prevents the read function from writing to the channel (avoiding the panic in the writer if the reader were to close the channel), and the context causes both sides to exit cleanly. You can plumb in the cancel function returned from context.WithCancel/context.WithCancelCause to allow the reader to kill the writer. (Incidentally, the reason you have to do this is because context.Done() is type <-chan, not type chan, so you can't just close(ctx.Done()).) The writer can still kill the reader by closing the channel, because closes are writes.