I'm coming predominately from other languages, so it took me a hot minute to figure out what the various bug were.
• channels are by default "unbuffered", in that a send needs a waiting recv to actually do the send, and blocks until such. The addition of the buffer prevents the block & permits the goroutine to progress (and eventually exit, and thus, not leak) … so long as the buffer is sufficiently large enough.
• channels do not, AFAICT, realize when the receiver is gone, and will block indefinitely even when there is no receiver. (It is the same "chan" object, I think, in both sender/receiver / there is no distinction. So, the single object is never GC'd.)
• goroutines are not GC'd. (& the code doesn't/can't hold like, a reference or a handle to a goroutine / there is no "join" primitive.)
"<-chan TYPE" is the receive end, "chan<- TYPE" is the send end, "chan TYPE" without an arrow can be used for either.
close() on a chan is "indicate end-of-transmission"; you should only ever use it from the send end. There is no way to explicitly "close" the receive end.
You can use `select` to do a non-blocking sends/receives, but yeah normal sends/receives are blocking.
(2) has a bit more nuance to it: you can close channels… but the langage is designed for that to only be ok on single senders, a receiver can gracefully handle a closed channel (an iteration will just stop, a receive can use the 2-valued form to get the information), a sender will always straight up panic. Aka go channels are designed for fan-out.
And not closing channels is also considered idiomatic, per a tour of go:
> Channels aren't like files; you don't usually need to close them.
I'm coming predominately from other languages, so it took me a hot minute to figure out what the various bug were.
• channels are by default "unbuffered", in that a send needs a waiting recv to actually do the send, and blocks until such. The addition of the buffer prevents the block & permits the goroutine to progress (and eventually exit, and thus, not leak) … so long as the buffer is sufficiently large enough.
• channels do not, AFAICT, realize when the receiver is gone, and will block indefinitely even when there is no receiver. (It is the same "chan" object, I think, in both sender/receiver / there is no distinction. So, the single object is never GC'd.)
• goroutines are not GC'd. (& the code doesn't/can't hold like, a reference or a handle to a goroutine / there is no "join" primitive.)
"<-chan TYPE" is the receive end, "chan<- TYPE" is the send end, "chan TYPE" without an arrow can be used for either.
close() on a chan is "indicate end-of-transmission"; you should only ever use it from the send end. There is no way to explicitly "close" the receive end.
You can use `select` to do a non-blocking sends/receives, but yeah normal sends/receives are blocking.
(2) has a bit more nuance to it: you can close channels… but the langage is designed for that to only be ok on single senders, a receiver can gracefully handle a closed channel (an iteration will just stop, a receive can use the 2-valued form to get the information), a sender will always straight up panic. Aka go channels are designed for fan-out.
And not closing channels is also considered idiomatic, per a tour of go:
> Channels aren't like files; you don't usually need to close them.