Memory Safety

The article would only “invalidate” what I wrote if the sudo-rs vulnerability was a result of memory safety. That isn’t what these vulnerabilities are.

By the way, the data on this is so clear and readily available about the real world reduction in memory safety issues Rust has in the real world I really don’t understand how you’re doubling down on your flawed position: https://security.googleblog.com/2025/11/rust-in-android-move....

This is literally empirical validation of the theoretical expected result. And Microsoft has also presented they’re seeing similar results. This is literally scientific evidence for the blinking neon sign that Rust achieves a significantly meaningful higher bar of memory safety than C/C++ regardless of any concerns you’ve raised (valid or otherwise). Rust isn’t evaluated in a vacuum against a hypothetically perfect alternative.

Unsafe rust behind harder to work with also doesn’t mean that unsafe in sudo-rs instantly runs into such issues. You can see the vast majority of the unsafe here is invoking syscalls. That isn’t what people are typically referring to as “unsafe is hard”. Basically you seem to not actually understand the issues at play and are cherry picking sound bites you think support the predetermined position you’re really set on taking. Thats what I mean by being lazy - you claim the existence of unsafe in sudo-rs makes it memory unsafe when that’s not at all necessarily the case - it just means there’s a risk there. Same with the Vec example - it’s highlighting how there can be issues but it doesn’t mean the vast majority of unsafe runs into it.

Is rust as memory safe as Java? No, it’s not. Is it substantially closer to Java safety than C/C++? Yes and it looks like it’s about at least an order of magnitude better than C/C++ while offering the same performance profile (and actually often better because it’s aliasing rules can be more aggressive and the standard library is more modern). An order of magnitude fewer vulnerabilities for the same performance is an insane jump in the Pareto frontier.

I'm certainly not going to say that nothing better could emerge, but nevertheless it's effort towards improving something that isn't memory safety.

In other words, I don't really agree that there's a "singular focus" on memory safety. Memory safety rewrites/projects get headlines, absolutely, but that doesn't mean everyone else has dropped what they were doing. Generally speaking, different groups, different projects, etc.

> It's kind of the opposite of that.

I don't think I quite agree? What I was thinking is that there have been efforts to make memory-safe dialects/variants/etc. of C/C++, but none of them really got significant traction in the domains Rust is now finding so much success in. I'm not saying this is because Rust is easy, but (at least partially) because it took concepts from those previous efforts and made them easy enough to be accessible to ordinary devs, and as a result Rust could become a plausible more-secure replacement for C/C++ where those earlier efforts could not.

> The problem with WordPress isn't that it's designed for performance over security. It's not fast, and a replacement with a better design could easily improve performance while doing significantly more validation. And it's full of low-hanging fruit in terms of just removing a lot of the legacy footguns.

Sure, and I'm not denying that. My point is just that unlike Rust vs. C/C++, as of this moment we don't know what an analogous plausible replacement for WordPress could be (or at least I don't know; perhaps you're more in-the-know than I am). Again, it's the difference between having a plausible solution for a problem in hand vs. sitting at the drafting desk with some sketches.

> In general when you come up with some new construction methods that are better able to withstand earthquakes, you apply them whenever you build a new building, and maybe to some specific buildings that are especially important or susceptible to the problem, but it's not worth it to raze every building in the city just to build them again with the new thing.

I feel like perhaps where the analogy breaks down is that unlike rebuilding a building, the Rust version of something can be built while the old version is still being used. Rust 4 Linux didn't require Linux and/or driver development to halt or for existing drivers to be removed in order to start and/or continue its development, Dropbox didn't have to tear out its old sync engine before starting work on the new one, etc.

And because of that, I feel like in general Rust is already mostly being used for new/important things? Or at the very least, I don't think "raze every building in the city just to build them again with the new thing" is an apt description of what is going on; it's more akin to building a "shadow" copy of a building in the same space using the new techniques with the possibility of swapping the "shadow" copy in at some point.

Or maybe I'm just too charitable here. Wouldn't be the first time.

> After all, what happens when you get the new new thing? Start all over again, again?

If the cost-benefit analysis points in that direction, sure, why not?

Ah, my apologies for misreading the original comment I replied to then.

> This was mostly because they didn't solve the performance problem. In the domains where that matters less, other languages did make significant inroads. Java, Python, etc. have significant usage in domains that before them were often C or C++.

Which is true! But even after Java/Python/etc. made their inroads the memory-safe dialects/variants/etc. of C/C++ still didn't attract much attention, since while Java/Python/etc. made memory safety easy enough for devs, as you said they didn't make performant memory safety easy enough, which left C/C++ their niche. While Rust is far from a perfect solution, it seems to have made performant memory safety easy enough to get to where it is today.

> If you really wanted to rebuild every building in the city, you could build a new building on every available empty lot, move the people from existing buildings into the new buildings, raze the buildings they just moved out of to turn them into empty lots and then repeat until every building is replaced.

I took "raze every building in the city just to build them again with the new thing" as specifically implying a destroy -> rebuild order of operations, as opposed to something more like "replace every building with the new thing". Too literal of a reading on my end, I guess?

> The reason that isn't done is that building a new thing from scratch requires a significant amount of resources, so it's something you only force outside of its natural replacement cycle if the incremental improvement is very large.

I mean, that's... arguably what is being done? Obviously different people will disagree on the size of the improvement, and the existence of hobbyists kind of throws a wrench into this as well since their resources are not necessarily put towards an "optimal" use pretty much by definition.

> The point is that it doesn't. Rewriting a large amount of old C code, especially if it doesn't have a lot of attack surface exposed to begin with, is a major cost with a smaller benefit. Meanwhile there are many other things that have medium costs and medium benefits, or large costs and large benefits, and those might be a better use of scarce resources.

That's a fair conclusion to come to, though it's evidently one where different people can come to different conclusions. Whether one stance or the other will be proven right (if the situation can even be summed up as such), only time will tell.

And again, I feel like I should circle back again to the "solution in hand vs. sitting at the drafting table" thing. Maybe an analogy to moonshot research a la Xerox PARC/Bell Labs might be better? One can argue that more resources into a WordPress replacement might yield more benefits than rewriting something from C to Rust, but there are much larger uncertainty bars attached to the former than the latter. It's easier to get resources for something with more concrete benefits than something more nebulous.

By the same token can I say your comment here is representative of all HN comments?