|
> 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'. |
Which gets handled by the container scheduler