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.
_______________________________________________
eeps mailing list
[email protected]
http://erlang.org/mailman/listinfo/eeps
