concurrency-patterns | examples helping to understand the key design | Reactive Programming library

In both cases, the select is done to avoid blocking — if the reader isn't reading from our output channel, the write might block (maybe even forever), but we want the goroutine to terminate when the done channel is closed, without waiting for anything else. By using the select, it will wait until either thing happens, and then continue, instead of waiting indefinitely for the write to complete before checking done.

As for the other question, "why are we not returning here?": well, we could. But we don't have to, because a closed channel remains readable forever (producing an unlimited number of zero values) once it's been closed. So it's okay to do nothing in those "bottom" selects; if done was in fact closed we will go back up to the top of the loop and hit the case <-done: return there. I suppose it's a matter of style. I probably would have written the return myself, but the author of this sample may have wanted to avoid handling the same condition in two places. As long as it's just return it doesn't really matter, but if you wanted to do some additional action on done, that behavior would have to be updated in two places if the bottom select returns, but only in one place if it doesn't.

If one of the channels is a timeout, odds of your work being done and the timeout firing at exactly the same time are so small they make no sense to consider.

The statement "... It chooses one at random if multiple are ready." is applicable when you actually have a viable reason for this to happen - when you have a select case on multiple job channels that you're processing with a single goroutine, for instance.