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

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.