There's a problem lurking behind this "simple" model: the goroutine you park on that blocking IO operation can't be collected reliably itself. I care about col

There's a problem lurking behind this "simple" model: the goroutine you park on that blocking IO operation can't be collected reliably itself. I care about collecting goroutines, and would advocate that everyone should care about this. There's been a litany [1] of blogs about this recently, if anyone doesn't consider this self-evident. It's just systematically sane. Letting goroutines spin off into the distance with no supervision is extremely likely to represent either a resource leak, a missing error handle path, or an outright logic bug. In a dream world, we might have Erlang-style supervisor trees so this can all be done with less boilerplate. It's almost even possible to do this as a library in go! ... except for this blocking IO problem, which throws a wrench in things: any supervisor of a goroutine that may be IO-blocked may itself be indefinitely stuck, and so on up-tree, making the concept unworkable. --- [1] Some recent articles hammering the point of "collect your goroutines": - https://dave.cheney.net/2016/12/22/never-start-a-goroutine-without-knowing-how-it-will-stop https://dave.cheney.net/2016/12/22/never-start-a-goroutine-w... - https://rakyll.org/leakingctx/ https://rakyll.org/leakingctx/