On Tuesday 29 October 2024 at 11:31:19 UTC+1 tapi...@gmail.com wrote: > https://github.com/golang/go/issues/21985 > https://github.com/golang/go/issues/28017 > > Personally, I think this is an interesting idea.
Hi, thanks for sharing. I never knew you don't have to close channels, see: https://github.com/golang/go/issues/27544#issuecomment-419515859. Been using go for several years at this point, lol. This changes a lot, in my opinion. Many times, each sender can just stop sending the channel and have it get garbage collected, when all are done. It may be even the preferred, way. Closing the channel more more like a broadcast and not a resource freeing operation. Now this sentence makes a lot more sense to me: https://pkg.go.dev/sync#Cond wrote: > For many simple use cases, users will be better off using channels > than a Cond (Broadcast corresponds to closing a channel, and Signal > corresponds to sending on a channel). After learning that you don't have to close channels, I think more like rob pike says it in the github comment below. https://github.com/golang/go/issues/21985#issuecomment-331622588: > If a program sends on a closed channel, it's not managing resources > correctly. You could argue that your proposal makes it easier to do > that, but I would counter that it makes it too easy to construct poor > concurrent structures. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/d41a0b4b-1fa4-4d2b-8cd4-6b30a1075295n%40googlegroups.com.
