Microsoft, Google, and other companies have all determined that about 70% of CVEs are memory-related. Here's the US government's take: https://www.cisa.gov/news-events/news/urgent-need-memory-saf...

These memory-related exploits disappear with Rust aside from in "unsafe" blocks (possibly the worst named keyword in any language... it should have been called "trusted"), and that means you have a smaller and more easily auditable attack surface for these types of memory-related exploits. Some code (e.g., FFI) can't be verified as memory-safe by the Rust compiler at compilation time so "unsafe" is there as an escape hatch. I've written a bunch of Rust since 2014 building things like webservers, realtime futures processing algorithms, MEV bots, etc., and I've only had to use "unsafe" a few times.

I've also worked in security on products at Fortune 100 companies, and C is a constant nightmare for CVEs. I think I have PTSD from having to update libcurl. The more software we have written in memory safe languages, the better off we all are.

Both for sure, and which one is a bigger deal depends a lot on context.

Cybersecurity issues make Rust a good choice for writing parsers for example. File format parsers handle scary data from the internet (JPEG, X.509, etc), and those often contain addresses and offsets that turn into raw pointers in the implementation, so they're a common source of security bugs. At the same time, they're usually isolated behind a reasonably tight API, so it can be practical to rewrite them in Rust even when all the calling code is still C or C++ or even Python.

On the other hand, fewer-mistakes-sucking-up-dev-time is an especially big deal in multithreaded code. There was a story from Mozilla about how they'd tried to add threading to part of Firefox (I think it might've been the CSS engine?) and failed multiple times, but then they succeeded in Rust. Threading bugs tend to be painful to reproduce, and Rust's compile-time checks are extremely valuable there.

Both. On the one hand, what Rust essentially forces you to do is just to program according to proper RAII principles that an experienced C++ programmer would already know and should already be using (especially once polonius lands), it's just better at checking failure to do so than any sanitizer or linter could ever be, so it's a way to avoid having to deal with annoying, hard to track down memory bugs. And in fact, the greater confidence static lifetime guarantees give you allows you to do things like using move semantics more where C++ programmers would have to use copies out of defensive programming. That's predominantly why I personally use it, as far as memory safety goes. On the other hand, [around 60-70% of serious security bugs have been proven to be caused by memory safety across many different projects](https://alexgaynor.net/2020/may/27/science-on-memory-unsafet...) so if you do care about security in what you're doing, it's a boon there too.

Mostly from a less-dev error standpoint but I think you gain in cybersecurity as well, as the language won't let you write code that accesses memory in places it's not supposed to.

Both, and they're related in the sense that software errors can become exploitable vulnerabilities. This is a handy summary by the NSA: https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...

Tomato, tomato.