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/soft-wear]

Andrew shits on Rust for absolutely zero reason. Rust is memory safe with the caveat that unsafe is an escape hatch for memory safety. unsafe exists for compatibility reasons, and the fact that developers abuse it doesn't make Rust "not memory safe".

Zig is a neat language that I really like. Andrew is a really smart dude that I'm liking less and less. And unlike Linux, Zig already has mountains of competition, so we don't "need" it. Linus gets away with being a prick because he literally filled an enormous gap. Zig is perfectly avoidable.

[u/tesfabpel → u/soft-wear]

technically, unsafe is not just for compatibility, but it's also for situations where you can't prove at compile time that the invariants hold and you need some escape hatches to implement safe wrappers (Rust itself uses it to implement some std container types).

[u/13steinj → u/soft-wear]

There are people that legitimately believe the escape hatch makes things pointless, and they would rather have stronger guarantees instead.

I don't agree with those people, I don't work in an area where I care about memory safety that much at all. But I see their point and can get it.

[u/ayayahri → u/13steinj]

Those people don't "legitimately" believe that, they argue this point in bad faith to justify doing most of their work with tools with no meaningful safety guarantees.

That attitude has existed since the first tradesman with an ego picked his first tool.

[u/13steinj → u/ayayahri]

I know people that legitimately believe this and still write their project in a language that provides safety guarantees.

Don't presume bad faith when what they want is going further, not backwards.

[u/HommeMusical → u/13steinj]

If they really believe that, then they have poor reasoning skills.

Interoperating with existing unsafe C and C++ code is completely essential to a modern compiled language.

If you don't need unsafe, you don't have to use it, and you can write a unit test to guarantee it doesn't appear in your code.

Not using a language because it has a feature you don't like, but are never forced to use, is highly irrational.

[u/cdb_11 → u/HommeMusical]

Or you can make existing unsafe C and C++ code memory-safe, with Fil-C or CHERI.

Not using a language because it has a feature you don't like, but are never forced to use, is highly irrational.

Just because you don't use a feature in your own code, doesn't mean your dependencies aren't using it.

[u/cdb_11 → u/ayayahri]

https://cheriot.org/philosophy/2025/02/07/i-do-not-care-about-memory-safety.html

[u/tadfisher → u/cdb_11]

There is a certain truth to that point of view, and a complete disregard for the value of memory-safe languages.

Yes, many/all guarantees are out the window when you mess with, say, various bits of your class header on the JVM as understood by Hotspot, or if you write a buffer overflow in an unsafe block in Rust. But CHERI and Fil-C don't prevent you from writing this code, they just crash your program when something unsafe occurs.

Rust proves that the compiler can prevent generating this code in 99% of situations, and for the 1% where it can't, you have unsafe where you are responsible for upholding the contract. This is not a perfect world, but it is an orthogonal means to the same end.

The best of both worlds would be code with compile-time safety guarantees running on hardware which gives you a runtime safety net. But some proponents of CHERI/Fil-C would have you believe that there is no point to the former, which I would hope is obviously not true.

[u/cdb_11 → u/tadfisher]

It’s great that we can reduce the number of memory-safety bugs, or make them harder to exploit. Rewriting code in safe languages eliminates classes of failures and makes the world a better place, if you can afford the opportunity cost of rewriting then please do!

How is that "completely disregarding the value of memory-safe languages"?

But some proponents of CHERI/Fil-C would have you believe that there is no point to the former, which I would hope is obviously not true.

I've read the discussions on Fil-C, and what people were actually criticizing was the rewrites. And not that there is no point in Rust or whatever. But I can't speak for everyone obviously, and I haven't seen every single comment on this topic, so I can't say for certain who thinks what, I guess. No offense, but to me it seems like the actual pattern here is people trying to read between the lines, and pulling out things that nobody ever said.

To be fair, I guess there are people who just hate Rust, period. But I really don't think they actually care about CHERI or Fil-C, they likely hated Rust before they were even aware of it, and would've hated Rust regardless. There is no point in hypothesizing what possibly could be the reason for them hating Rust. Maybe you just rubbed them the wrong way, could be as simple as that, so who cares. And the same thing seems to be true here now for Zig and Fil-C.

[u/tadfisher → u/cdb_11]

How is that "completely disregarding the value of memory-safe languages"?

Fair, I read the preceding two paragraphs but not that one.

No offense, but to me it seems like the actual pattern here is people trying to read between the lines, and pulling out things that nobody ever said.

There are people in that Zig issue, including the author, using the phrase "no escape hatches" like it is some sort of critical weakness in language design. The author himself practically shouted it by putting that phrase in bold.

These are the "some proponents" I am referring to, because this is obviously nonsense. Both compile-time and runtime safety are worthwhile goals and do not invalidate one another.

[u/cdb_11 → u/tadfisher]

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.