GoKawiilWritten by Piotr Sarnacki
on July 28, 2026
Memory Safety Absolutists
When seeing the title of this post, I bet in some people's minds, the first thought was "Rust devs!". This connection is not unfounded. Rust devs tend to be passionate about memory safety. Some of it, I'm sure, may have been caused by a classic language wars attitude: my language is better than yours, and here is why. I'm hoping, though, that most of the Rust devs, who say they care about memory safety, genuinely care about making software safer, and not just criticizing languages that compete with Rust.
The article, surprisingly, is not about Rust devs.
Until recently, most of the memory safety related discourse had a relatively simple basis, at least when considering non-GC, systems programming languages, like C, C++, Zig, and Rust. Rust aims to disallow compiling programs that may introduce memory safety issues (at a cost of sometimes disallowing a program that would have been safe), with an escape hatch in the form of unsafe that allows, among other things, dereferencing raw pointers. C and others leave ensuring memory safety to the programmer. The amount of help from the language differs, for example there is RAII and smart pointers in C++, or defer in Zig, but for the most part nothing stops you from violating memory access.
The situation today is a bit different with a new way to make C, C++, and in the future maybe also Zig, code memory safe: Fil-C. C and C++ code compiled with Fil-C will panic on invalid memory access, like out of bounds access, or use after free. It achieves it by combining GC and InvisiCaps - a way to track memory accessible by a pointer. Zig's author recently announced a new compilation mode for Zig inspired by Fil-C. Fil-C is a very interesting project and I sincerely hope it will succeed and at least some popular C and C++ projects will provide Fil-C compiled releases.
In an ideal world both Rust programmers and C/C++/Zig programmers that care about memory safety would be happy that there are more ways to minimize memory safety vulnerabilities, but alas, we're not living in an ideal world and I can't shake the feeling a lot of the criticism towards Rust recently is disingenuous. If you read Fil-C's author opinions on Twitter, it's blatantly obvious that he dislikes Rust and I've seen him claiming Rust is a memory unsafe language because of ability to bypass some of the Rust guarantees when using unsafe . Andrew Kelley, Zig's author, seems to have a similar stance demonstrated in the fil compilation mode issue title: "introduce an actually memory safe (unlike Rust) compilation mode inspired by Fil-C". Meaning: Rust is unsafe and only Fil-C or Zig's "fil" compilation mode will deal with memory safety related vulnerabilities.
In discussions related to Rust and Fil-C, I've often seen a claim similar to: "if Rust folks really cared about memory safety, they would promote Fil-C and ditch Rust as Fil-C is safer, otherwise they just care about their new shiny language, and not memory safety". That includes Fil-C's author himself. I'm not sure about Andrew Kelley, but the issue title I mentioned earlier feels awfully close. These kinds of arguments are, in my opinion, ignoring reality, and feel like fanaticism and cult-like behaviour that often Rust devs are accused of.
If Fil-C was a drop in replacement with absolutely zero trade-offs, I would maybe partially agree with the sentiment, but it has trade-offs: it's ABI incompatible with non-Fil-C compiled programs, it may be a few times slower in some cases, and it introduces GC. None of these things is a deal breaker for some programs. A lot of programs you use daily could be a few times slower than they are, and you wouldn't even notice. A lot of them also don't link anything dynamically, so the ABI compatibility doesn't matter. But not every software program is a simple utility. There are lots of popular projects, where GC and ABI incompatibility are an issue and there is no way they would ever start using Fil-C like technology, or at least not in a current form. Crucially, the kind of programs that can't use Fil-C are often a good fit for Rust.
... continue reading