delayed child restart with incremental back-off

Nicolas Martyanoff khaelin@REDACTED
Mon May 3 11:04:30 CEST 2021


Ingela Andin <ingela@REDACTED> writes:

> Erlang-patches is legacy, we use GitHub instead, and yes erlang-questions
> is still a place for discussions.
Got it. It would make sense to send an email to people posting on
erlang-questions to inform them (instead of just telling them that the
mailing list is "moderated").

> Well, this was some time ago so I am unsure of how it was
> communicated. But the conclusion was that we did see merit in the idea
> but that we were not able to include something that would be backwards
> incompatible by default. To be able to change defaults we need to have
> a phasing out mechanism and period of testing what problems it might
> cause legacy code. We also did not have an immediate own use case for
> this that could motivate it to be prioritized for us to put much of
> our own time into it, and hence it requires a bigger effort from the
> contributor to motivate and test and think through all scenarios.

Thank you for explaining.

While I understand your point, I fear that this line of reasoning leads
to lots of developers having to skip various OTP components because they
simply cannot be patched. Backward compatibility is important; but
pushed to the extreme, it is tentamount to stagnation and death.

In this case, I am going to have to write a new supervisor module and
apparently I'm not the first one to do so. In addition of a new
gen_server so that I can get the right types and the infinite call
timeout by default, among other things.

The more I use Erlang, the more I realize I would love to have a
distribution containing only the language and related standard libraries
without most of OTP, because it simply does not match my needs and it is
almost impossible to change anything.

-- 
Nicolas Martyanoff
http://snowsyn.net
khaelin@REDACTED


More information about the erlang-questions mailing list