> particularly in Go where everyone crams everything into single-func interfaces which are almost exclusively far worse
Depending on scope, I've grown to prefer the single func interface.
For a smaller scope use, say filepath.Walk, absolutely, pass in a closure, good stuff.
For larger stuff, like say a chain of http middleware and handlers, I think it can be very limiting.
you get a big benefit from using the interface over a function: the underlying type _can_ have more methods and implement.
this gives room to implement a parallel interface, for example, to collect all possible routes, or to trace what handlers a request would pass through.
I don't think there's a one-size-fits all approach, use whatever gives the effort:utility tradeoff you're looking for.
Auto restarting is actually intended to hide problems! ...from the user. The user, who probably isn't you if you're developing or administrating a service.
Any supervisory process, systemd, supervisord, kubernetes, etc should absolutely be making those restarts visible to the administrator so that they can resolve it.
The restart is just in hopes to keep the service available (symptoms in check) until the problem is actually fixed (disease is cured).
My father had schizophrenia, and my wife has tourettes.
It's a completely different scenario. Someone with tourrettes knows what just happened. They're probably deathly embarrassed and apologetic.
In the schizophrenic case, they're being aggressive, hurtful, belligerent -- no one is obligated to sit through that. There's no reasoning with them, there's not even a discussion happening.
Likewise, (ThingDoerImplemetation{}).DoThing is a valid func reference
Hence I say there's not really a one size fits all, there are a options for different circumstances.