4 ms·

Interesting about channels. I had been wondering why, despite always being touted as a core feature and reason for Go being awesome, I find them quite rare when

Interesting about channels. I had been wondering why, despite always being touted as a core feature and reason for Go being awesome, I find them quite rare when looking at other people's code. I've only found them particularly useful for communication between goroutines on one project (filtering events, sending them to the correct workers), and the rest of the time mostly used to implement timeouts (and wishing for some syntactic sugar there, since it can be non-obvious how to to avoid leaking the timers).

fpoling 8y ago
Channels in Go do not allow to prioritize messages and proper support for cancelation is highly non-trivial. Both are necessary in complex software. With mutexes one can build all these things, but lack of language support for mutexes sucks.
shabbyrobe 8y ago
That's a really good point actually, I hadn't thought directly about this before. I've just evolved a position on it without articulating it directly: I almost never include them in my public APIs, almost never see them in the better APIs, and tend to count it as a strike against a package if I see that they're used without strong justification. I find there's a lot you have to do manually to handle them correctly and it's easy to miss details. I think they're best cordoned off behind isolated, encapsulated parts of a channel-free public interface. To walk back a tiny bit from my earlier "80%" claim, I reckon channels are probably more like 50% complete. The existence of "context.Context", itself very much half-baked, is a symptom of that. You have to think long and hard about cancellation and blocking every time you interact with them (even if you decide you don't ultimately need to), and the results, once you've (hopefully) handled all the corner cases can degenerate into a tangled mess that's hard to reason about, harder to test, and impossible to change. I like to call this kind of code "channel soup". I'd be interested to see proposals for what the 80% version of channels would look like. What we have now is a great start, but it's not great yet.

fpoling 8y ago

Channels in Go do not allow to prioritize messages and proper support for cancelation is highly non-trivial. Both are necessary in complex software. With mutexes one can build all these things, but lack of language support for mutexes sucks.

shabbyrobe 8y ago

That's a really good point actually, I hadn't thought directly about this before. I've just evolved a position on it without articulating it directly: I almost never include them in my public APIs, almost never see them in the better APIs, and tend to count it as a strike against a package if I see that they're used without strong justification. I find there's a lot you have to do manually to handle them correctly and it's easy to miss details. I think they're best cordoned off behind isolated, encapsulated parts of a channel-free public interface. To walk back a tiny bit from my earlier "80%" claim, I reckon channels are probably more like 50% complete. The existence of "context.Context", itself very much half-baked, is a symptom of that. You have to think long and hard about cancellation and blocking every time you interact with them (even if you decide you don't ultimately need to), and the results, once you've (hopefully) handled all the corner cases can degenerate into a tangled mess that's hard to reason about, harder to test, and impossible to change. I like to call this kind of code "channel soup". I'd be interested to see proposals for what the 80% version of channels would look like. What we have now is a great start, but it's not great yet.