[cube2222]

Why would you want a supervision tree?

This would suggest using an actor-like model, which is pretty senseless for single-machine usage. It's totally understandable for Erlang, where the VM spans multiple machines, so everything is unreliable, but in Go, I take it for granted, that my goroutines won't "just crash".

I'm not sure, but I think this also ends up being good for modelling interactions with good performance, as you know where you do network calls, where you have reliability, and where you have instant local calls. Though not to say that Erlang applications aren't blazingly fast too.

[dozzie]

> It's totally understandable for Erlang, where the VM spans multiple machines, so everything is unreliable, but in Go, I take it for granted, that my goroutines won't "just crash".

Supervision tree gives a structure to put whole subsystems somewhere, including their boot initialization and shutdown (not just restarting it at crash), allows to spawn workers while keeping usual logging/crash monitoring for free, gives a way to inspect the system at runtime (much easier debugging), and allows to run several different applications in the same VM space, which is a flexible way of combining code. I can, for instance, run a CouchDB instance with bolted on my own HTTP server that exposes monitoring data or an administrative interface. It cannot be done in Go (or any other language, barring maybe Lisps) without modifying source code.

And no, none of this "spans multiple machines", it all works and helps on just one single node. Maybe except for debugger, where you spawn a shell node from which you operate.

And yes, your goroutines will "just crash" in situations you haven't expected, as every non-trivial daemon experiences crashes on transient bugs. Though in Erlang transient bugs don't bring the whole daemon down. Saying `my goroutines won't "just crash"' means `my code and code I use as libraries doesn't have bugs, ever'.

[cube2222]

No, it's saying: if my goroutines crash it's the same as if my main thread crashed, which means: game over, application down.

Which gets handled by the container scheduler

[dozzie]

So every unrelated request that happened to be currently processed is thrown away because of a rare corner case, and with no way to intercept shutdown and save state, flush buffers, or anything. Yes, totally right granulation.

Not to mention that you have just introduced a very complicated piece of software to run a single daemon.

[Vendan]

Or, you just catch the panic in a defer up the call chain, log the error, and then exit that goroutine. Like: https://golang.org/src/net/http/server.go#L1694

[ramchip]

Idiomatic Erlang involves handling only errors that are expected (read: part of the program’s specification), and crashing on any other kind of error. This keeps the error handling out of the business logic and makes the app code simpler and more reliable.

For instance, you can’t forget to close a socket, release a lock, or log the actor state and stacktrace, since these things are handled by the VM and supervisors when an actor dies. These are nice properties to have even in a single-node system if you’re aiming for high reliability.

I do agree though that a supervision tree doesn’t make as much sense in Go, since the VM does not provide the cleanup guarantees and strong process isolation that make the Erlang model really workable.

[spc476]

Wow! My network daemon at work, written in Lua (which uses Lua coroutines for processing, which are similar enough to Go routines/channels for this comparison) has a supervision tree. It can log the unexpected death of Lua coroutines and keep going, which is nice for the unexpected bit of input [1]. It's also helpful when testing new code as unexpected errors are logged (stack dump, so the location of the crash is reported) in development/QA.

[1] Yeah yeah, all input should be well specified. Could you please inform the vendors that their programs are spewing unspecified crap at me? Thanks.

[Vendan]

Go can do almost the exact same thing, in fact, it's baked into the stock http server library.