> How is this different from an app dying because of an unhandled exception in Java or Python?
It isn't different, which is my point: Supervisors don't magically make running apps with year-long uptime "easy". You're agreeing with me but in a tone (hard to tell, obviously) that says you aren't.
Restart forever w/backoff isn't the most unreasonable or complicated behaviour to provide. In some cases, writing rigid code can be simpler to test, read and maintain. Go-like error checking / matching can be excessive when you expect something to work 99.9% of the time, and just dying and restarting [until the network restablishes itself, or a human can look into it] can often be preferred.
Otherwise, people who point to my exaggerated example and say "you're doing it wrong", seem to be implying that supervisors are great as long as you write bug-free code and consider every possibility upfront.
> It isn't different, which is my point: Supervisors don't magically make running apps with year-long uptime "easy".
Well, ok, supervisors are not magic, but they are a convenient tool for handling the specific problem of initializing and shutting down a concurrent system.
> Restart forever w/backoff isn't the most unreasonable or complicated behaviour to provide.
Yes, and you can easily provide it yourself by writing your own supervisor and plugging it into the tree, or even just running it linked to some other process. That's for backoff - the "forever" part you can get by simply using infinity as timeout and max restarts I think.
> seem to be implying that supervisors are great as long as you write bug-free code and consider every possibility upfront.
I don't think I understand what you mean. There's nothing stopping you from cutting a particular supervision tree branch off by not linking it, but monitoring instead. The restarts will then be contained to that subtree.
It isn't different, which is my point: Supervisors don't magically make running apps with year-long uptime "easy". You're agreeing with me but in a tone (hard to tell, obviously) that says you aren't.
Restart forever w/backoff isn't the most unreasonable or complicated behaviour to provide. In some cases, writing rigid code can be simpler to test, read and maintain. Go-like error checking / matching can be excessive when you expect something to work 99.9% of the time, and just dying and restarting [until the network restablishes itself, or a human can look into it] can often be preferred.
Otherwise, people who point to my exaggerated example and say "you're doing it wrong", seem to be implying that supervisors are great as long as you write bug-free code and consider every possibility upfront.