Re: [go-nuts] Channels vs Callbacks in API

In some cases, a synchronous callback can be a fine choice: consider filepath.Walk . A synchronous callback does not require any extra goroutines, and if the caller needs to adapt it to work with a channel (or perform longer-duration processing in

Re: [go-nuts] Channels vs Callbacks in API

On a semi-related note, I think there is a fair amount of wisdom in the "Synchronous Functions" section of the Code Review Comments golang wiki page (including it is not written as an absolute and starts with the word "Prefer"). https://github.com/golang/go/wiki/CodeReviewComments#synchronous-f

Re: [go-nuts] Channels vs Callbacks in API

1 - I should emphasize that the API in question is concurrent by nature (inbounds at any time which might need replies). 2 - All points made are good valid points in general. Thanks! 3 - With 1 in mind, still IMHO, channels should be preferred. Draining on either side, needs goroutines. But consu

Re: [go-nuts] Channels vs Callbacks in API

Some counterpoints: * In the question of "Channels vs. Callbacks", the best choice is "neither". Write a blocking API with a fixed number of items and a Scanner-like Iterator for an unknown number of items. * It requires spawning a Goroutine even if none is necessary * It adds syntactic overhead t

[go-nuts] Channels vs Callbacks in API

The statement being made here: a receive only channel, as a return value of a function, in an API, is not bad. Reasoning: - can not be closed - can not be set to nil - it's more clear than callbacks - if signaling is the desired behavior, callbacks for sure are the wrong choice