←back to thread

Go channels are bad

(www.jtolds.com)
298 points jtolds | 4 comments | | HN request time: 2.158s | source
Show context
hamburglar ◴[] 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 #
1. divan ◴[] 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 #
2. jtolds ◴[] 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 #
3. courtf ◴[] 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 #
4. jtolds ◴[] No.11213854{3}[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.