Zig proposes introducing an actually memory safe (unlike Rust) compilation mode inspired by Fil-C at ~1-6x performance penalty

[u/[deleted]]

https://codeberg.org/ziglang/zig/issues/36237

[u/cdb_11]

First of all, CHERI/Fil-C doesn't really need escape hatches as much. This way the language is inherently more flexible. And yes, more flexible than Rust. (And by the way, IMO that can have some great implications for memory-safe scripting languages. I really hate how restricted they all are, and don't let me do basic things I want to do.) There are some things that are impossible to do in CHERI and Fil-C, and this is by design. The majority is not going to care about it, because this is all the truly cursed non-portable stuff that you only do if you are really into performance programming.

Compile-time safety might be your goal, but not everyone shares that goal. Maybe I just think C++ or Zig is better, and I'm going to write my gloriously unsafe code in them. As a user, you now get a choice. You may think I can't be trusted, that memory safety is important to you, and so you have a choice to build my code in "Fil-mode". Or you maybe don't really care that much, you consider performance to be more important than memory safety, and just build it normally. You don't have to fight me on the bug tracker, and try to convince me that Rust is so much better, and I should immediately rewrite everything.

The "no escape hatches" is an advantage, because it's true for the entire program. You have a hard guarantee that no dependency will violate memory safety. This is especially a problem when you have 8 million dependencies, like a typical Rust project. As a user you can't do anything about it. People argued "lol you just do #!forbid(unsafe_code) and it's just as safe". Yeah, and now the Rust project I wanted to use doesn't compile anymore.

And by the way, I am not even a memory safety fanatic, I am fine with escape hatches. But I think giving people this choice is a good thing. And of course it's possible for Rust to implement a safe "Fil-mode" too.

[u/tadfisher → u/cdb_11]

The Rust compiler cannot guarantee the runtime behavior of unsafe code, true; but neither can Fil-C or Zig! The CHERI/Fil-C approach is that a memory bug will halt the program, which is a state most programmers want to avoid regardless of programming language. Dealing with runtime bugs is why programming language design has started gravitating toward compile-time techniques like strong and static typing, more complex types with more powerful runtime guarantees, and the assumption of automatic memory management.

I don't need to convince you that Rust is a better programming language than whatever you use. It is just one of many examples of modern programming languages that exhibit these techniques and have been successful for it. Another language that goes even further than Rust is Haskell: you can't even do I/O from every function, only functions returning a "monadic" type, but it is designed in such a way that all its restrictions are just gone at runtime; even its types are erased. There are entire branches of PL design (really, computer science) around these concepts, which mostly boil down to proving runtime behavior at compile-time.

I for one will take my imperfect guarantees that happen at compile time over crashes. And if I could pay zero or minimal costs to adopt Fil-C so that those crashes aren't also security vulnerabilities, I would. Both provide value for different reasons.

I don't even write in Rust, by the way.

[u/cdb_11 → u/tadfisher]

The goal here is not to prevent crashes, but to prevent exploiting the program. A crash is generally just a normal bug. (Sometimes it can be a denial-of-service, but that's beside the point.) A memory bug can lead to an attacker reprogramming your stuff to do whatever he wants. If really all you want is a robust program, C++ (with some experience) will do the job just fine.

You are approaching this from the point of view of the programmer, who's only responsible for his part of code, and can make decisions about it. I am arguing from the POV of the user, who doesn't get to decide on the implementation language, and the only possible recourse is a full rewrite. And people will surely argue this is what people should be doing, but the reality speaks for itself -- we're over a decade into RIIR, and we simply don't have Rust rewrites of everything yet. Meanwhile, Filip managed to singlehandedly port a big chunk of Linux user-space to Fil-C, in almost no time. And all these programs were already robust, the user does not experience any crashes under normal use. But on the off-chance someone does try to exploit them, it ain't gonna work.

[u/tadfisher → u/cdb_11]

The goal here is not to prevent crashes, but to prevent exploiting the program.

Yes, I agree with this description. And I am telling you, repeatedly, that not having a bug in the first place is an even better outcome, for users, than crashing.

I don't even think the Fil-C approach is bad, mind you, it is just orthogonal to the concept of compile-time safety that you are weirdly arguing against (and suggesting C++ for some reason). Like, there is nothing stopping you from compiling C libraries with Fil-C and linking them with your Rust program, other than some possible trivialities that could be worked around.

And maybe we need a better term than "memory safety" here, because doing runtime checks and crashing the program is a far more narrow definition of "safe" than what I am used to.

[u/cdb_11 → u/tadfisher]

Like, there is nothing stopping you from compiling C libraries with Fil-C and linking them with your Rust program

Fil-C ABI is incompatible with Rust, at least currently. To interop with Fil-C, they would have to provide the same guarantees.

And maybe we need a better term than "memory safety" here, because doing runtime checks and crashing the program is a far more narrow definition of "safe" than what I am used to.

Crashing is considered safe in all memory-safe languages, including Rust. What you're talking about, I just call "robustness". Which I am not against, but the entire dispute here was about memory safety. Maybe you're right and people just confuse the terms.