←back to thread

Go channels are bad

(www.jtolds.com)
298 points jtolds | 3 comments | 02 Mar 16 15:40 UTC | HN request time: 0s | source
Show context
hamburglar ◴[02 Mar 16 17:10 UTC] No.11211264[source]▶
Non Go programmer here. Can someone explain the initial goroutine leak that is being addressed? I don't see the issue.
replies(4): >>11211441 #>>11211510 #>>11211514 #>>11211630 #
divan ◴[02 Mar 16 17:53 UTC] No.11211630[source]▶
It's not actually a leak. It's a program explicitly doing 'run goroutine and don't care of it anymore'. If the program logic wants this - it's ok. If author wants it to finish on some condition, but didn't write the condition code (like in this article) - it's a leak, but it's purely author's mistake.
replies(1): >>11211684 #
1. jtolds ◴[02 Mar 16 18:02 UTC] No.11211684[source]▶
There is a deliberate leak in the example program. The author was attempting to illustrate that fixing the leak using just channels would be a challenge.
replies(1): >>11211763 #
2. courtf ◴[02 Mar 16 18:13 UTC] No.11211763[source]▶
Synchronizing access to a memory address isn't really the use-case for channels. I think that's fairly well understood by the Go programmers I work with. This example demonstrates why, but it prefaces the discussion by implying this is the standard practice, which I think is misleading.
replies(1): >>11213854 #
3. jtolds ◴[02 Mar 16 23:17 UTC] No.11213854[source]▶
I perhaps communicated poorly, but the point of that section was to try and explain that the CSP model (only using channels) was untenable in Go (even though it doesn't necessarily have to be in general), and that you'd almost certainly end up not just using channels in a real program, which it seems you agree with.