I do not believe this. Most C code by far is not written in a way that makes it easy to formally guarantee memory safety, so the lowest effort path will necessarily involve refactoring it until it does.

And that means that rewriting it altogether into a new language has very few drawbacks, and some additional benefits.

Yes, you can rewrite everything in Elm, PureScript or even anything that is more similar to JS, but step by step conversion to TS enables a significant quality improvement for large codebases (I personally think it doesn't fare so well on small codebases, where there are some people who use it even for one-off scripts, but at least we can agree on large codebases I think)

I'm not sure that's what you meant, but interoperability between C and Rust does seem to be a selling point of Rust (like TS and JS), and allows C codebases to be oxidized gradually rather than rewritten from scratch.

By the way, I love rust, but I just don't understand the "rewrite all the things" hype. Being battle tested means a lot for low-level libs. You can't guarantee that you ported everything exactly, with bugs and all. Pragmatic solutions like "Checked C" prove a lot in that regard.

You actually can “just” turn C into Rust with something like c2rust. But you haven't gained any safety without refactoring.

Is that not also the case for Checked C?

No, because while some refactoring is necessary, it is virtually always local. E.g. if the sound checker can't prove that an access is within an arrays bounds, adding a dynamic test just before it (assuming you don't want to add annotations to help the checker) will make it provable.

Rewriting in a new language is certainly one way to reduce or eliminate memory errors, but if your goal is to reduce or eliminate memory errors in existing codebases, there are other ways that are cheaper, more proven, less risky and are applicable to more environments. These tools are already much more heavily used in safety- and security-critical codebases than any new language, so people are slowly getting good experience with them.

I'm still not convinced the new languages (Rust & Zig) will change the overall situation.

Why? Simple example in Rust:

    "LOL! I need to get stuff done."
    
    unsafe {
        Really nasty hacks here to circumvent any obstacles.
    }

    "LOL! I need to get stuff done. Tests? What tests???"

    zig build-exe example.zig -O ReleaseFast

So we really need other means to erase those bug classes. Which ones I don't know.

I'm not sure I follow, it seems to me like it's actually a freaking high-hanging fruit. The amount of engineering and design that goes into creating a safe, fast, low-level programming language (i.e. Rust in this case) is enormous and it requires huge amounts of upfront investment.

The only reason the industry has largely resorted to unsafe languages is because there's many other lower-hanging fruits, e.g. fuzzing, rigorous unit testing, static analysis tools. These help immensely but at the end of the day only take you so far.

Will they do things in that way? Heck, let’s just ask: are they doing things in those ways?

crickets

Just meaningless rhetoric (“being done fast and/or cheaply”) and unfounded hypotheticals.

The interesting thing about C is that it is one of the few languages which has been able to survive without massive changes throughout the years. All these hyped-up modern languages are in flux ALL THE TIME.

Ah, it’s simple, then. We will await eagerly for the non-forthcoming links to all those efforts/implementations.

Or would you like to walk that back to “in principle suitable for automated detection”?

Outside Bell Labs, operating systems were being written in safer systems programming languages, and one of the reasons why Unisys still has enough customers that care to pay for ClearPath MCP, which has a security level no UNIX clone is capable of, thanks NEWP.

Although I wouldn't mind if Pascal or Ada swings back to mainstream's attention.