If you needed any more evidence that memory safety is the future...

[Jack Stouffer via Digitalmars-d]

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.