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

[Jacob Carlborg via Digitalmars-d]

On 2017-03-03 03:11, Moritz Maxeiner wrote:

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

So we need operating systems and the core libraries to be built from the 
ground up with memory safety in mind in these kind of languages.

-- 
/Jacob Carlborg