I don’t see the relevance to this discussion then.

The discussion is about a project for securing legacy code by machine-translating it to Rust. Fil-C is an alternative way to secure legacy code using a different C implementation. I think that's highly relevant to the discussion.

The kind of errors being protected against are totally different though.

Fil-C protects against a superset of the errors that Rust protects against. It just does it dynamically.

And more comprehensively. There’s no `unsafe` statement in Fil-C. There’s no need for it since dynamic checking is vastly more precise.

Dynamic/runtime checks (and crashes) are VERY different from compile time checks though. Many applications, and especially those that DARPA are focused on, care about ahead-of-time guarantees that code will work correctly, and runtime panic is actually the worst possible failure mode. Think of flight control software, for example.

This DARPA doc isn’t about flight software.

Rust uses runtime checking for array access bounds, which are the most common kind of memory safety vulnerability.

Checking at compile-time is required for some applications and highly desirable regardless.

This is something recent versions of C++ do really well. It is my main reason for using C++ beyond its unparalleled performance in practice.

You’re confusing memory safety with Rust’s specific flavor of static checking.

Totally not the same thing.

Like, notice how DARPA is in no hurry to have folks rewrite Java or JavaScript in Rust. Why? Because even JavaScript is memory safe. It’s not achieving that with dynamic checking rather than static checking.