On Friday, 24 February 2017 at 13:38:57 UTC, Moritz Maxeiner
wrote:
This isn't evidence that memory safety is "the future", though.
This is evidence that people do not follow basic engineering
practices (for whatever seemingly valid reasons - such as a
project deadline - at the time).
Writing a program (with manual memory management) that does not
have dangerous memory issues is not an intrinsically hard task.
It does, however, require you to *design* your program, not
*grow* it (which, btw, is what a software *engineer* should do
anyway).
If the system in practice does not bear any resemblance to the
system in theory, then one cannot defend the theory. If, in
practice, programming languages without safety checks produces
very common bugs which have caused millions of dollars in damage,
then defending the language on the theory that you might be able
to make it safe with the right effort is untenable.
Why is it that test CIs catch bugs when people should be running
tests locally? Why is it that adding unittest blocks to the
language made unit tests in D way more popular when people should
always be writing tests? Because we're human. We make mistakes.
We put things off that shouldn't be put off.
It's like the new safety features on handheld buzzsaws which make
it basically impossible to cut yourself. Should people be using
these things safely? Yes. But, accidents happen, so the tool's
design takes human behavior into account and we're all the better
for it.
Using a programing language which doesn't take human error into
account is a recipe for disaster.
