Hacker News Reader

Comment by tptacek | Hacker News Reader

I think it's important to keep the scope of the debate well-defined, because memory-safe languages completely stomped out memory-unsafe languages more than 20 years ago; almost all new code is written in languages that are unshowily memory safe (like Java and Python).

We're really talking about resistance to memory safety in the last redoubts of unsafety: browsers and operating systems.

View on HN

> We're really talking about resistance to memory safety in the last redoubts of unsafety: browsers and operating systems.

And control systems, c++ (along with PLCs ofcourse) dominates in my experience from developing maritime software and there doesnt appear to be much inclination towards change.

> browsers and operating systems

And the VMs for the two languages that you mentioned above (edit: though to be fair to your comment, I suppose those were initially written 20+ years ago).

To be fair, there's a pretty clear difference between achieving memory safety with a garbage collector and run-time type information, versus achieving it through static analysis.

Static analysis is worse and limits the programs you can write in annoying ways?

I like dynamic typing, but the point wasn't about holy warring. The point is simply that it's different.

There’s also google, yandex, baidu, and bing, which are incredible amounts of c++ code

And probably lots of robotics, defense, and other industries

Granted, those aren’t consumer problems, but I would push back on the “last redoubts”.

We should absolutely move toward memory safe languages, but I also think there are still things to be tried and learned

> We're really talking about resistance to memory safety in the last redoubts of unsafety: browsers and operating systems.

.. and other performance critical areas like Financial applications (HFT), High Performance Computing (incl. AI/ML), embedded, IoT, Gaming/Engines, Databases, Compilers etc.. Browsers and OS are highly visible, but there is a gigantic ton of new C++ code written everyday in spite of the availability of memory safe languages.

People keep coming up with all these examples of things still written in C/C++. Sure. So are most AAA games. But so far nothing that's been identified --- maybe excepting databases, but vulnerabilities there are still rare --- that is a meaningful component of insecurity, which is what "memory safety" addresses.

> that is a meaningful component of insecurity, which is what "memory safety" addresses.

There are plenty of people, though, who argue that everything must be memory safe (and therefore rewritten in Rust :) I personally don't agree with that sentiment and it seems like you don't agree either.

It would be better for everyone if everything on a forwardgoing basis was written in a memory-safe language.

What difference does it make for a video editor or DAW?

iphones have already CVEs from memory safety issued in image formats. is entirely plausible that a similar issue could exist in video or audio codecs

The parser is attack surface, but that's the only part of something like Photoshop that has to be secure. The actual editing features can be insecure.

and cryptographic code.

My favorite crypto bug was not a memory safety issue: https://i.blackhat.com/us-18/Wed-August-8/us-18-Valsorda-Squ...

Was a fascinating detective story to illustrate it.

Reply on news.ycombinator.com