Google's take on memory safety

[H. S. Teoh]

On Wed, Mar 06, 2024 at 09:19:20AM +0000, RazvanN via Digitalmars-d wrote:
> I stumbled upon this. Here is the abstract:
> 
> "2022 marked the 50th anniversary of memory safety vulnerabilities,
> first reported by Anderson et al. Half a century later, we are still
> dealing with memory safety bugs despite substantial investments to
> improve memory unsafe languages. [...] We see no realistic path for an
> evolution of C++ into a language with rigorous memory safety
> guarantees that include temporal safety. As a consequence, we are
> considering a gradual transition of C++ code at Google towards other
> languages that are memory safe.
[...]

Called it. Since years ago. It's been clear then, and becoming even
clearer now by the day, in today's landscape of bots that constantly
scan the net for systems with memory vulnerabilities, that the days of
memory-unsafe languages like C or C++ are numbered.  Software systems
have developed to the point that manually managing memory just doesn't
cut it anymore.  Systems have become too large, too complex, and memory
issues have become intractibly difficult to handle manually.  It's time
to let go of the illusion of total control over one's memory usage and
make use of real solutions.  Like the GC. ;-)  Or any of the various
automated memory management schemes.

Also, when is D gonna get @safe by default?!  Seriously, it's been
years.  Why are we still stuck at the same old stalemate over something
so irritatingly trivial like having extern(C) *not* default to @safe?!
It should have been a 5-minute decision, yet at the rate things are
going it will soon be a 5-year decision. If even that. Let's hope it's
not going to be a 50-year decision(!). :-/


T

-- 
Making a boat out of stone would be a hardship.