On Wednesday, 11 July 2018 at 22:35:06 UTC, crimaniak wrote:
The people who developed Erlang definitely have a lot of
experience developing services.
Yes, it was created for telephone-centrals. You don't want a
phone central to go completely dead just because there is a bug
in the code. That would be a disaster. And very dangerous too
(think emergency calls).
The crucial point is whether you can depend on the error being
isolated, as in Erlang's lightweight processes. I guess D
assumes it isn't.
I think if we have a task with safe code only, and
communication with message passing, it's isolated good enough
to make error kill this task only. In any case, I still can
drop the whole application myself if I think it will be the
more safe way to deal with errors. So paranoids do not lose
anything in the case of this approach.
Yup, keep critical code that rarely change, such as committing
transactions, in a completely separate service and keep
constantly changing code where bugs will be present separate from
it.
Anyway, completey idiotic to terminate a productivity application
because an optional editing function (like a filter in a sound
editor) generates a division-by-zero. End users would be very
unhappy.
If people want access to a low-level programming language, then
they should also be able to control error-handling. Make
tradeoffs regarding denial-of-service attack-vectors and 100%
correctness (think servers for entertainment services like game
servers).
What people completely fail to understand is that if an assert
trips then it isn't sufficient to reboot the program. So if an
assert always should lead to shut-down, then it should also
prevent the program from being run again, using the same line of
argument. The bug is still there. That means that all bugs leads
to complete service shutdown, until the bug has been fix, and
that would make for a very shitty entertainment experience and
many customers lost.
