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.
