
The four things I miss about go - ngrilly
http://blog.merovius.de/2014/09/12/the-four-things-i-miss-from-go.html
======
lobster_johnson
Should have "(2014)" in the title, although everything mentioned is still
relevant.

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.

------
zimpenfish
"Dynamic loading of Go code" is (partially - only seems to work on Linux,
maybe Darwin) covered by
[https://golang.org/pkg/plugin/](https://golang.org/pkg/plugin/) in 1.8.

------
ngrilly
Like the author, I'm wondering why "dead" goroutines are not garbage-
collected?

