The four things I miss about go
blog.merovius.de
blog.merovius.de
Note that the dead goroutine example seems to be incomplete. It needs to send something to the "done" channel in order to cause the goroutine to break.
I think Go just wants to be explicit here, but it is too easy to leak goroutines. The channel semantics feel a bit broken, too. It's too easy to end up with a channel that is either closed or nil, both of which can cause bugs.
You'd think a concurrency-oriented language like Go would give you more tools for doing things like dealing with multiple workers. Work queues invariably result in boilerplate; short-circuiting processing on errors requires the experimental ErrGroup; and it seems way too much effort is needed making sure defer blocks are completely correct with respect to sequencing and cleanup.
But what I perhaps miss the most in goroutines is the ability to forcibly terminate a goroutine. In other words, I wish goroutines were more like Erlang processes. If a caller can't kill a goroutine, you can't really implement something like supervisor trees.