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

[Moritz Maxeiner via Digitalmars-d]

On Thursday, 2 March 2017 at 23:00:34 UTC, Guillaume Piolat wrote:
> On Friday, 24 February 2017 at 13:38:57 UTC, Moritz Maxeiner 
> wrote:
>> On Friday, 24 February 2017 at 06:59:16 UTC, Jack Stouffer 
>> wrote:
>>> https://bugs.chromium.org/p/project-zero/issues/detail?id=1139
>>>
>>> [...]
>>
>> This isn't evidence that memory safety is "the future", though.
>
> Completely agreed.
> This only shows that memory safety is not the present. Not that 
> it is "the future".

For what it's worth: I do hope memory safety becomes a common 
feature and what languages like D and Rust do on that front is 
great (even though both D's still heavily integrated GC as well 
as Rust's static analysis have their downsides).
My major gripe, though, is still that people tend to create 
"safe" wrappers around "unsafe" (mostly) C libraries, which (in 
the sense of safety) doesn't really help me as a developer at all:
Now I not only have to trust that the C library doesn't do 
horribly stuff (or audit its source), I *also* have to extend the 
same trust/time to the wrapper, because since it must interface 
with C all possible compiler guarantees for what that wrapper 
actually *does* are null and void (-> D's @system / Rust's unsafe 
blocks).
Great, if I *truly* care about safety my workload has increased 
significantly compared to just using the "unsafe" C APIs myself 
(which is easy in D and a PITA in Rust)!
In reality, of course, I just use the wrapper and die a little 
inside about the fact that I have to trust even more people to 
get things right when all evidence shows that I totally shouldn't.
TL/DR: I wish people would write more native libraries in safe 
languages, but who has the time for that?