Memory Safety Absolutists
by drogus on 7/25/2026, 6:08:52 PM
https://itsallaboutthebit.com/memory-safety-absolutists/
Comments
by: himata4113
My biggest problem with the refusal to be memory safe is the fact that those problems end up becoming my problems when I am forced to use these applications and I have to think about how there might be a zero-click zero-day that uses an overflow in some random codec. Not as a software developer, but a regular person I want my application to be written in rust or at least use fil-c at bare minimum.<p>Now as a software developer I feel like this is even more important because I use libraries maintained by thousands of other developers that might also use applications that have these exploits which get their systems compromised pushing malware to thousands of other developers which end up compromising even more libraries.<p>I believe that memory safety should be the standard for software that thousands if not millions rely on and that it shouldn't be some political issue of X is better, Y is that, Z is something else.<p>But then again, social engineering is the primary source of malware spread so I don't know.
7/25/2026, 8:56:54 PM
by: inigyou
I don't think you need to be an absolutist or only use memory safe languages but it's very obvious that we need to do a whole lot better than we actually do. Rewriting in Rust or any other language is one way to do that, but not a perfect one. I'll accept C++ when most C++ software has 1 in 50 chance of an RCE and not just a 1 in 50 chance of a <i>known</i> RCE. I think we can get there but we are not currently there.<p>Coreutils has a good track record. Ffmpeg doesn't. They should have rewritten ffmpeg in Rust, not coreutils.<p>There are other approaches though like formal verification.
7/25/2026, 9:28:06 PM
by: bloaf
As long as rowhammer is still out there, aint none of your memory safe. Fixing rowhammer is the memory safety absolutism I want to hear more about.
7/25/2026, 9:27:29 PM
by: noelwelsh
Good article. Not much to add to it, other than I think more people should look at modal type systems like found in Scala 3 and OxCaml. If you want safe arena allocation they are a lot more ergonomic than Rust's approach.
7/25/2026, 9:12:42 PM
by: hmry
It's annoying how many comment sections online are now just Rust vs Fil-C / Zig flamewars, and the creators of those languages are deliberately fanning the flames.<p>I also feel there's a second dimension to the politics, where Rust is the "woke" language and C / Zig / Odin are now the "anti-woke" languages. At least, going by their most vocal online communities.<p>I'm sure offline there's still engineering decisions being made (I hope).
7/25/2026, 9:16:14 PM
by: leni536
Fil-C is basically an alternate ABI and libc runtime. Otherwise it is not tied to C and I see no reason it couldn't be targeted by Rust or Zig.
7/25/2026, 8:58:27 PM
by: kmeisthax
I was not aware of the antagonism from the Zig / Fil-C people to Rust, but it makes absolutely no sense.<p>Like, <i>of course</i> you can prevent all memory safety errors by using a garbage collector. That has been known since the 90s. In fact, there was a good two decades after Java released where all the research on memory safety just stopped, because the standard answer became "use a GC". If you couldn't use GC, you were stuck with languages made prior to Java - which in practice meant just C - or the one language everyone tried to staple every new programming paradigm onto, C++.<p>In fact, part of <i>why</i> C++ became such an untameable beast of a language is <i>because</i> it became load-bearing for non-GC projects. Anything not in the ISO C++ standard was, in practice, something you just couldn't do in native code. Oh, <i>of course</i> you can't introspect structs in a compiled language, of course macros are useless and unhygenic, of course templates have to be monomorphized and bloat your binary size. And so the pressure for C++ to be an all-singing, all-dancing, all-dressed language grew.<p>Rust's big story is memory safety, but the more Rust I wrote, the more I realized that the memory safety is only part of the picture. Rust has a very nicely curated selection of features that allows the language to remain understandable despite the sophistication of the compiler. Memory safety is a selling point, sure, but it is also the lubricant that makes working with those features pleasant.<p>If you want a real complaint about Rust, it's that some features are oversimplified in ways that make certain scenarios harder and make some features way more "magic" than they should be. Have you ever tried writing Futures code without making use of the async keyword? It's nearly impossible, for several reasons; the main being that Rust's type systems cannot express self-referential borrows. This also makes returning a reference to something in an Rc or RefCell you own more difficult[0]. And there are numerous other states memory can be in that are hidden from Rust's type system. Rust can't even represent a real destructor fn. Dropping a value multiple times, or using it after it's been dropped, is explicitly forbidden; but Drop impls still can't take values out of themselves because Rust doesn't have an "owned reference" - i.e. memory you can take values from but can't deallocate.<p>But none of this compromises memory safety - it just makes certain things harder than they should be.<p>[0] Strictly speaking, there's an owning_ref crate that manages this; stdlib is also working on a "mapped mutex guard" type that would do the same thing without a dependency.
7/25/2026, 9:13:34 PM
by: rowanG077
Something that is much more important to me is that it's caught at compiler time. A memory issue is a logic bug. Fil-c simply moves that from undefined behavior/security issue/incorrectness to a crash. That's better than what it was. But I generally don't want my programs to crash. Having memory safety at compile time is infinitely more worthwhile imo.
7/25/2026, 9:12:07 PM
by: throwlifeaway
Pizlo is not a memory safety absolutist. His rhetoric towards rust is a tactic specifically designed to draw more attention to him and his project. It is amplified by people who already had a bone to pick with rust and take joy in giving rust folk "a taste of their own medicine," so to speak. Articles like this are taking the bait.
7/25/2026, 9:10:27 PM
by: hkalbasi
Someone should fire up an AI and create Fil-Rust by connecting the Fil-C llvm backend to rustc, ending this flamewar. I guess it is well within the capabilities of a Fable class model, even if the driver doesn't have experience in compiler development.
7/25/2026, 9:26:10 PM
by: blurgrin
> Our historical data for C and C++ shows a density of closer to 1,000 memory safety vulnerabilities per MLOC.<p>Unfortunately, I've never seen a version of this data targeting modern C++ (>=11, with smart pointers, already 15 years old).
7/25/2026, 9:34:31 PM