According to that blog post (https://security.googleblog.com/2024/09/eliminating-memory-s...), the vulnerability density for 5 year old code in Android is 7.4x lower than for new code. If Rust has a 5000 times lower vulnerability density, and if you imagine that 7.4x reduction to repeat itself every 5 years, you would have to "wait" (work on the code) for... about 21 years to get down to the same vulnerability density as new Rust code has. 21 years ago was 2004. Android (2008) didn't even exist yet.

Remember that there are other types of vulnerabilities too. If there are less of them in old code then it may make up for more memory issues.

I also feel like this is good advice when making a language shift, or any _other_ shift, even a stylistic one.

A lot of my coworkers get in this situation where, when a change in direction is made, they feel like we have to stuff the roadmap with work to rewrite everything. That work is... 0 value, in most cases, unless the decision we have made is intended to directly solve an issue in the existing code.

Many times I find that if you just do new work in the new thing, you'll "naturally" prioritize rewriting at the right rate. When we do it that way, we end up replacing, rather than rewriting, those legacy systems, which avoids the pitfall of trying to reproduce prior behavior, down to the bugs it may have had.

>So it makes more sense to write new code in Rust than to rewrite old code in Rust.

This is a general result regardless of what language you're talking about (unless you're really downgrading to assembly or something crazy). This of course presumes that the overall Rust (or other new language) situation is better than the existing one. It's not generally.

Thing is, from security point of view, if it is part of the ISO C++ PDF one can buy in Geneva, compiles with a C++ compiler in C++ mode, it is C++.

That argument can be applied to unsafe Rust as well. There are code reviews, coding standards and other checks for a reason.

Though, I suppose something like C++ profiles, just for modernization, might make it much easier to enforce and track that modern C++ is used.

The difference is that with Rust one can prevent unsafe in the compiler build settings.

Or any language with unsafe code blocks, which people keep forgetting also exist, while complaining about Rust, as if there isn't any other memory safe language.

With C++ you need external tooling to disable C like code, that a large part of the community refuses to adopt.

With that line of argumentation there are no safe languages, we should all go back to Assembly.

Wrong, for any reasonable definition of memory safety, languages like Java and Javascript are memory safe. Java has escape hatches, but the necessity and prevalence of those escape hatches are way, way less than that of Rust. Consider for instance a standard library implementation of a collection in Java and Rust. In Java, there would typically AFAIK rarely ever be even a single usage of escape hatches. For Rust, the collection implementations in the Rust standard library are typically riddled with the unsafe keyword, even for simple collections. Java handles performance by generally relying on JIT.

This is not a theoretical exercise. https://materialize.com/blog/rust-concurrency-bug-unbounded-... .

AWS started an initiative to formally verify the Rust standard library, based on volunteer effort and maybe bounties. I think that is interesting, but I looked once at one of the issues for tracking what they had verified, and as I remember, even though they had marked it as fully verified, the main person verifying had called to attention in a post that he had not verified everything that the issue covered.

And even for memory-unsafe languages like Rust, there are trade-offs.

> Wrong, for any reasonable definition of memory safety, languages like Java and Javascript are memory safe. Java has escape hatches, but the necessity and prevalence of those escape hatches are way, way less than that of Rust.

What definition of memory safety are you using where (supposed) "necessity" and "prevalence" are factors, and at what thresholds for those two factors do languages cross from unsafe to safe or vice versa?

> In Java, there would typically AFAIK rarely ever be even a single usage of escape hatches. For Rust, the collection implementations in the Rust standard library are typically riddled with the unsafe keyword, even for simple collections. Java handles performance by generally relying on JIT.

So you have Rust, which uses unsafe code for performant collections, and Java, which uses unsafe code via its JIT for performant collections. I'm not sure I see a substantial difference here.

> But Rust is obviously not a memory safe programming language. Unsafe's prevalence and difficulty, no_std, and arguably also the bugs and holes in the type system of Rust that have not been fixed for many years by now, make this clear.

Everything else aside, why is no_std included here?

no_std for instance does not protect the stack completely. That means that, if you for instance have a simple stack-overflow bug in a Rust program when using no_std, even if the program has absolutely no usage of the unsafe keyword, you can get undefined behavior.

And one does not even need esoteric code to trigger stack-overflows, dependent on coding style, a simple recursive call that has bugs like proper lack of constraints relative to resources or bugged infinite recursive calls without tail-call optimization, can do it.

> no_std for instance does not protect the stack completely. That means that, if you for instance have a simple stack-overflow bug in a Rust program when using no_std, even if the program has absolutely no usage of the unsafe keyword, you can get undefined behavior.

I think you're technically correct, though I also think the picture is a bit more complicated than you paint it. From my understanding, stack overflow protection needs cooperation between (at least) a language, its runtime (if present), and the environment the program is run in. In other words, I'm not sure any language can "protect the stack completely" without knowledge of the environment it's going to be run in, so at least technically speaking I don't think Rust is any different here.

That being said, rustc will insert stack probes even when compiling with no_std, so in environments where stack probes are sufficient to protect against stack overflow/stack clashes no_std is safe with respect to that particular issue.

For example, this short program:

    #![no_std]
    #[inline(never)]
    pub fn f() -> u8 {
        let v: [u8; 16384] = [1; 16384];
        v.iter().sum()
    }

Produces stack probes on e.g., x86_64-unknown-linux-gnu [0]:

    example::f::hb88315ca0b28f303:
        sub     rsp, 4096
        mov     qword ptr [rsp], 0
        sub     rsp, 4096
        mov     qword ptr [rsp], 0
        sub     rsp, 4096
        mov     qword ptr [rsp], 0
        sub     rsp, 4096
        mov     qword ptr [rsp], 0
        push    rax
        lea     rdi, [rsp + 8]
        mov     edx, 16384
        mov     esi, 1
        call    qword ptr [rip + memset@GOTPCREL]
        <further assembly omitted>

[0]: https://rust.godbolt.org/z/rcdvj8j4K

BTW; Do you know if it is possible to track new comments to Hacker News threads?

I used https://hnreplies.com/