Go: Process isolation rediscovered as a programming pattern

I think providing a language construct to help you do something badly and covering up your mistakes by rebooting is a step in the wrong direction.<p><i>Surely, you can debug your programs, but catching slow leaks in complex software is hard, even in Go.</i><p>I don't think this warrants restarting your goroutines. Go is still a young language, who knows what tools for debugging will come along in the future.

Are the concepts described in the article the same as Erlang or Erlang/OTP, or is there more to it?

The author seems to have rediscovered the advantages of managed operating systems.<p>Here's a relevant article for those not familiar with the concept:<p><a href="http://research.microsoft.com/apps/pubs/?id=69431" rel="nofollow">http://research.microsoft.com/apps/pubs/?id=69431</a>

Cool stuff. I think it's similar to custodians in Racket (the artist formerly known as PLT Scheme):<p><a href="http://docs.racket-lang.org/reference/eval-model.html#(part._custodian-model)" rel="nofollow">http://docs.racket-lang.org/reference/eval-model.html#(part....</a>

If the problem looks like memory management, then perhaps something that looks like garbage collection is the answer?<p>Of course, it doesn't map trivially, since there are no existing references to goroutines. But, it may possible to determine if a goroutine cannot communicate with anyone - it is garbage - if there is no one listening to any of its channels. The one exception to this rule I can think of are daemon-style goroutines that would interact with the system through external calls. Such goroutines could be labeled as such at the creation site, indicating that the goroutine manager should not manage them.

Discussion on go-nuts mailing list: <a href="https://groups.google.com/d/msg/golang-nuts/ar3QSMI4ooE/9LGKtLcyragJ" rel="nofollow">https://groups.google.com/d/msg/golang-nuts/ar3QSMI4ooE/9LGK...</a>

I see what the author is getting at, but I don't see the reason for a language to provide this isolation. Why not just use an OS-level process? Why not create a library or framework to do this?

I think it's a good idea. Slow resource leaks are very hard to debug. Sometime it's easier and cheaper to just restart the process. I seem to remember some fighter jet subsystems can do fast reboot. When they crash, it can be restarted in a faction of a second. If the rebooting approach works in a realtime environment like that, it sure would work in the day-to-day environment.

My first reaction is that this is a terrible idea.<p>Very often you create a goroutine to send messages down channels. Those messages are objects. Those objects may go to multiple other goroutines.<p>Kill the originating goroutine and you've just messed up all of the other goroutines that thought that they had objects.

Seems loosely similar to how I'm using .Net4's Tasks from the Task Parallel Library. I didn't particularly focus on the effects of the garbage collector when I came up with my approach, but it does at least achieve point A in his opening paragraph (<i>(a) is simpler to use</i>)

Getting this article in text/plain.