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

[Moritz Maxeiner via Digitalmars-d]

On Friday, 24 February 2017 at 14:35:44 UTC, Jack Stouffer wrote:
> 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.

Since I have not defended anything, this is missing the point.

>
> 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?

These are fallacies of presupposition.

> Because we're human. We make mistakes.

I agree, but still missing the point I made.

> We put things off that shouldn't be put off.

Assumption, but I won't dispute it in my personal case.

>
> 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.

Quite, but that's not exclusive to memory bugs (though they are 
usually the ones with the most serious implications) and still 
misses the point of my argument. If you want *evidence of memory 
safety being the future*, you have to write programs making use 
of *memory safety*, put them out into the wild and let people try 
to break them for at least 10-15 years (test of time).
*Then* you have to provide conclusive (or at the very least hard 
to refute) proof that the reason that no one could break them 
were the memory safety features; and then, *finally*, you can 
point to all the people *still not using memory safe languages* 
and say "Told you so". I know it sucks, but that's the price as 
far as I'm concerned; and it's one *I'm* trying to help pay by 
using a language like D with a GC, automatic reference counting, 
and scope guards for memory safety.
You *cannot* appropriate one (or even a handful) examples of 
someone doing something wrong in language A as evidence for 
language feature C (still missing from A) being *the future*, 
just because feature C is *supposed* to make doing those things 
wrong harder.
They are evidence that there's something wrong and it needs 
fixing.
I personally think memory safety might be one viable option for 
that (even if it only addresses one symptom), but I've only ever 
witnessed over-promises such as "X is the future" in anything 
engineering related play out to less than what was promised.

>
> Using a programing language which doesn't take human error into 
> account is a recipe for disaster.

Since you're going for extreme generalization, I'll bite: Humans 
are a recipe for disaster.