That's true but misleading. I'm pretty sure the question was why a normal reference is bad. You don't need `addr_of_mut!()`, but you do need `&raw mut`.
Like everything, it's about trade-offs. C is really unsafe. Rust is almost entirely safe, and breaks the ecosystem just a little bit. Fil-C is entirely safe, and breaks the ecosystem entirely.
If you go by this metric (has a RCE and not known to have RCE), I'm pretty sure the actual statistics are more like 1 in 2, at least. And probably more than one RCE.
I absolutely agree learning C is a good thing! In fact, there are two camps of Rust people: one that argue that you should not learn C before learning Rust, and one that argues that you should.
Also, while such data structures/algorithms are rare, and more importantly, they can be written once and used many times, someone still needs to write them!
Fil-C is an amazing, marvelous even, and useful, concept. Useful for all legacy code that will not be rewritten and/or is not performance-sensitive, that is. The only problem is that Zig has no legacy code, so Fil-C is useless there. If you can afford the performance penalty, there are much better an easier languages to choose from.
Totally unrelated; The trusting trust attack was about downloading a malicious compiler because malicious code was injected into it in some early version.
(And if you ask me, it was indeed overrated, but that's unrelated).
Considering that you often run the code after you compile it, it might not matter. Anyway, like it or not, most compilers don't consider themselves security sensitive and will not consider malicious code that is able to hijack the compiler a security vulnerability.
Hardening is definitely possible, we've had sanitizers in C/C++ for a long time. It's not full memory safety though. Miri is the same.
SeL4C is formal verification, and while it can prove memory safety (and much more) it is much more difficult, to the point that you're basically programming in a different language.
Ada/SPARK is your best example, and also the example I know the least of, so I won't comment on.
I have picked private fields as an example of feature that is needed because it is very simple. You're right that you can build an analyzer (with additional code annotations) to support that, but it's only one example.
Take another example: unsafe traits. They are fundamental to some safety encapsulations, most famously concurrency (`Send`/`Sync`). Here you cannot just build an analyzer to mark something unsafe, because Zig has no traits, its generics are duck-typed.
You can, of course, add traits. But at this point you're essentially creating your own language that compiles to Zig, with all problems this entails (e.g. bad ecosystem support). It's also hard to claim that Zig can be memory safe then.
Most compilers do not consider themselves a security boundary, and will not try to limit malicious code from hijacking the compiler. E.g. LLVM is explicitly not designed to handled malicious code (https://llvm.org/docs/Security.html#what-is-considered-a-sec...).
> Nowadays when you can just point an agent at release notes and have it update everything
Except that means that not only you lose compiler bugfixes, you also pretty much has no access to the ecosystem. For most production codebases, this is a deal breaker.
No, it's exactly the sort of projects slop is not appropriate. If you're going to use this in production, at least using LLMs (maybe) allows you to deliver faster.
E.g. you cannot translate `#[repr(C)] struct Foo { v: i32, u: i32 }` to `typedef struct { int32_t v; int32_t u; } Foo;` because in Rust it's entirely valid to take a `&Foo` and view it as `&[i32; 2]`, while in C this is UB.
A Rust rewrite would have an easy way to expose an API, something they're still debating how to do and deferring to 7.1.
But the team has already choose. They explained their reasoning and IMO it makes sense: they didn't want a rewrite, they wanted a bug-for-bug file-by-file translation. With a borrow checker and no GC, Rust sometimes forces you to structure things differently (especially in a compiler that usually has a lot of circular structures), so it was not worth it.