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

[Ola Fosheim Grøstad via Digitalmars-d]

On Friday, 24 February 2017 at 17:18:03 UTC, Jack Stouffer wrote:
> Neither do I. But, the progenitor of that idea is that 
> languages have understood use-cases, and that using them 
> outside of those areas is non-optimal.

The way I see it system level programming is usually not well 
supported by languages. What I want is not "memory safety", but 
adequate tools for doing dangerous stuff like pointer arithmetics 
to and from SIMD representations on the stack with less chances 
of making mistakes. But I don't want any 
performance/flexibility/memory layout sacrifices or code bloat.

I don't really buy that bullet-proof and under-performing 
solutions is improving on system level programming. It is an 
improvement for application level programming and performant 
libraries.

A language that prevents me from using dangerous constructs is a 
non-solution. A language that detects that I spuriously might en 
up overwriting an unintended stack frame/storage is a solution. 
Of course, the latter is also a lot harder to create (requires 
formal proofs).

> I've come to believe that any program that handles personal 
> user data made in a language without memory safety features is 
> not only non-optimal, but irresponsible.

Maybe, but most personal user data is at some level handled by 
programs written in C: database engines and operating systems. 
Although I've noticed that the current trend is to focus less on 
performance and more on scaling, e.g. cochroachdb is an 
implementation of a Spanner like SQL database in Go.