EEP proposal - Delayed restarts of supervisor children

[Fred Hebert]

On 06/18, Maria Scott wrote:
>Hi Fred,
>
>let me try to summarize:
>
>1. the number of cases where careless use of restart delays are dangerous is high (meaning a long but certainly not exhaustive list of "Don'ts" in the docs)
>

I don't know if I'd call it "dangerous" -- the most dangerous cases are 
on the client (because we can't control turning them off easily), which 
is less often used for Erlang and Elixir.

It would at least be suboptimal. Mostly because there are known better 
ways of doing things and we'd willingly not be doing them.

>2. the number of use cases where restart delays would be harmless and useful is low
>

Here again, it's mostly that there are known better solutions.

For an analogy, it's not that I think Insertion Sort is harmful, it's 
that we collectively know that Mergesort or Timsort have more desirable 
characteristics, and we're willingly not using them and moving to a 
design that discourages these better approaches. Also I feel the sorting 
function shouldn't be in the supervisor module.

>3. even given (2), users may find the feature lacking (incremental backoffs, jitter, whatnot)
>

Yes.

>4. users (who notoriously don't read any documentation) will see it as a silver bullet for any kind of problem for which it was never meant (and quoting from the last thread on the subject, "i would use backoffs everywhere", you don't seem to be far from the truth)
>

That's an aspect of it. I tend to think that users don't read the 
documentation because they're focusing on something else, and they're 
using a library specifically because they don't have the time to learn 
the other thing.

So if we provide something out of the box, in something that has a 
reputation for being rock solid for decades, it had better be a rock 
solid implementation with very good defaults because people are gonna 
trust it.

>5. in consequence, the "reputation" of supervisors will suffer with 
>nothing gained but technical debt
>

It's not a thing that can be blamed on users nor the maintainers, it's 
an ongoing relationship. I think the "damage" there is a side effect 
that comes out of shipping something suboptimal within components known 
to be rock solid.

It can be mediated by committing to eventually making things better, 
marking them as experimental for the time being, for example. It shows 
progress, and this sort of approach, if followed through properly, can 
increase trust and show vigor in the improvements of the language.

This latter bit is however difficult to do if we decide the current 
proposal is reaching its complexity limits and would be difficult to 
improve, or if these improvements aren't on any roadmap.

>Is that, give or take, a proper summary of your concerns?
>

I think my analogy using sorting algorithms is the core of my 
opposition: it is not the nicest solution we could offer, and it isn't 
in the right module to put them in as far as I'm concerned (for the 
reasons I mentioned in my last email).

Once again though, I think the proposal is well done within the 
constraints of what it tries to do. If we take as granted that we're 
willing to offer the simplest thing possible (i.e. fewer knobs to 
configure) and that the supervisor is the place to put it, I think it 
all holds up. I'm mostly disagreeing with the premise, not the proposal.

Regards,
Fred.