On 17/06/2021 19:36, Fred Hebert wrote:
On Thu, Jun 17, 2021 at 10:22 AM Maria Scott
<[email protected] <mailto:[email protected]>>
wrote:
Hi Fred,
> I am against this proposal, for similar reasons I have opposed
similar ones in the past. Most of my opposition has been written up
before so I'm just going to link to it here:
https://ferd.ca/it-s-about-the-guarantees.html
As Loic (sorry, no idea how you put those double dots over an i
^^;;;) pointed out, just because a feature exists does not mean that
it must be used, or that it is a good fit for everything, or that it
has to be the one way by which all things have to be done. The
feature takes away nothing.
My view of this is that the feature creates an expectation. It is going
to be seen as the blessed implementation and the one people default to
because the language provides it as a feature of its core component of
its core framework. When maps are added to the language, it's expected
that they're going to meet a level of quality and contain an inherent
level of trust given to it by the community.
I can't properly put into words the sort of impact saying "oh the
supervisor, the one thing that is so core to OTP? it's actually not that
good and you should just use parts of them" would have. Even if there's
absolutely no good way to measure it, OTP has always represented this
solid core I know I can definitely build on /in any stateful application
I ever worked on in Erlang over the last decade/. This is less and less
true as we add features that are not that useful to everyone and not
that solid, just because maybe sometimes it's good and convenient. This
is the core of the whole robust state management structure here.
I agree in general, but then you also have the many variants of
supervisor2 and gen_server2 that were created over the years.
The supervisor2 in RabbitMQ in particular provides mainly two things:
the feature that became the "significant" property in OTP 24, and a
feature to delay restarts, that is used only for the processes of
plugins (shovel and federation) that move messages between queues. The
other changes are small and likely of no big consequence.
If the delay feature is accepted, great! We can likely move to the plain
old supervisor down the line. If not, that won't be a deal breaker,
it'll just take more work to get rid of it.
The gen_server2 on the other hand is much bigger, with prioritization of
messages probably being the stronger point, allowing to process
important messages earlier than others (which involves reading from the
mailbox and deferring the messages, because priorities are given in a
callback, not via a selective receive). I'd love to go back to plain
gen_server but that one's going to be a tough one.
So yeah. I think there are some use cases for delays in the supervisor,
and would appreciate having the feature around for those cases, but I
don't feel strongly about it either way.
Cheers,
--
Loïc Hoguin
https://ninenines.eu
_______________________________________________
eeps mailing list
[email protected]
http://erlang.org/mailman/listinfo/eeps
