Hacker News Reader

Comment by reactordev | Hacker News Reader

Except it itself is exposed via a public API. Context interface also exposes a chan

   Done() <- chan struct{}

What are you trying to say? That using a chan as a function argument can shoot yourself in the foot? The whole idea behind channels is to not shoot yourself in the foot with mutex's, deadlocks, etc. What are you trying to say? Wrapping a chan in a type handle is safer than passing a chan of a type? Nope.

View on HN

That's not at all what I was referring to. It's not merely having channels as function arguments. Channels broadly have footguns around how closed and nil channels are treated and you can run into work contention/starvation issues accidentally, since they do have their own throughput limits. And wrapping them in your own handle types that's specific to the library's use case allows you to deal with those issues and swap out the implementation of the cross-goroutine bits without breaking the downstream API.

Channels broadly have footguns around how closed and nil channels are treated

I appreciate your concerns but one could say similar things about nil pointers or accessing slices out of range. Anything you use should be handled with care.

exactly.

you can't abstract over channels easily unless you're missing the point of channels.

I think the rule is: don't use a channel unless at some point you need a select with 2+ branches. The context.Done is a case in point. You're not just waiting around for a context to finish. You do two things: try some network request and wait to see if the context cancels before it finishes. Because it's made to work in a select block like that, there wasn't another, better thing to use than a channel for context.Done. But for just iterating through some stream, you take a context in and return an iterator object that will do all the channel stuff internally.

Reply on news.ycombinator.com