The Pitfalls of Memory Safety Absolutism: Rust, Fil-C, and Zig

Discussions within the programming community about memory safety are taking a new turn. Piotr Sarnacki’s essay, “Memory Safety Absolutists” (published on itsallaboutthebit.com via ekuber, July 25, 2026), posted on Lobsters, serves as both a rebuttal to the trend of labeling Rust developers as “absolutists” and a sharp critique of the disingenuous claims from Fil-C and Zig developers that “Rust is not truly safe.”

The Reality of Absolutism

When hearing the term “memory safety absolutists,” many technologists might immediately think of Rust developers. As Sarnacki acknowledges, this impression is not entirely baseless. Certain factions within the Rust community have indeed been vocal about criticizing other programming languages as “unsafe.” However, the real issue lies in whether these criticisms genuinely aim to enhance safety or are merely a competitive ploy to assert the superiority of one language over others.

The author expresses a desire to believe that most Rust developers are genuinely committed to creating safer software. However, he notes an increase in criticism from other camps, particularly those associated with the Fil-C and Zig projects.

Misconceptions About Rust

Traditionally, debates about memory safety have occurred among system programming languages without garbage collection (GC)—such as C, C++, Zig, and Rust. Rust, by design, prevents the compilation of programs that violate memory safety principles but offers an escape mechanism through the unsafe block. In contrast, C and C++ place full responsibility on the programmer, while Zig provides aids like defer but fundamentally operates in a similar manner.

It is important to note that Rust’s unsafe does not nullify all safety guarantees. The unsafe keyword permits only certain operations, such as dereferencing raw pointers, while other safety mechanisms remain functional. Yet, some critics argue that “as long as unsafe exists, Rust cannot be considered safe.”

The Emergence of Fil-C

The landscape shifted with the advent of Fil-C. This tool compiles C and C++ code, triggering runtime panics in response to invalid memory accesses, such as out-of-bounds access or use-after-free errors. Its mechanism combines GC with InvisiCaps, a method to track memory accessible by pointers.

The creator of Fil-C has openly expressed disdain for Rust on Twitter, claiming that “Rust is not safe because its unsafe keyword allows bypassing safety.” Sarnacki labels this stance as “disingenuous.”

Zig’s Claim of “True Safety”

Inspired by Fil-C, Andrew Kelley, the creator of Zig, announced the introduction of a new compilation mode. The issue title states, “introduce an actually memory safe (unlike Rust) compilation mode inspired by Fil-C.” This phrasing explicitly asserts that Rust is unsafe.

Kelley has long criticized Rust’s unsafe keyword for undermining its reputation for safety, and this announcement further solidifies his position. This move has sparked skepticism not only among the Rust community but also from neutral observers.

The Dishonesty of Criticism

Sarnacki’s central argument is that while Fil-C and Zig developers label Rust as “unsafe,” they simultaneously tout their own solutions as “truly safe,” revealing a double standard. If memory safety is truly of paramount importance, all projects should welcome each other’s contributions.

In practice, even programs compiled with Fil-C can trigger runtime panics, meaning they are not entirely free of safety concerns. Likewise, Zig’s new compilation mode is still in development, and its capacity to effectively prevent vulnerabilities remains unproven. Meanwhile, Rust, with its design philosophy of minimizing unsafe usage and its rigorous type system, has already demonstrated significant achievements.

For instance, as reported on this site, the adoption of Rust-written drivers like Mesa Rusticl (Mesa Rusticl Enables Mali Panfrost by Default) has contributed to a tangible reduction in memory safety bugs. Pursuing absolute safety while dismissing practical safety improvements can be counterproductive.

Editorial Opinion

In the short term, the movements by Fil-C and Zig may intensify debates between the Rust community and other language communities over the definition of “true safety.” This could lead to confusion in development environments regarding language selection, while potentially encouraging C and C++ projects to adopt Fil-C. However, given the performance costs of runtime checks, it is unlikely that all projects will transition to Fil-C.

In the long term, this debate may redefine the fundamental question of what constitutes memory safety. While Rust’s ownership model offers provable safety, Fil-C provides runtime verification. A hybrid approach combining both strategies could emerge as a standard, ultimately enhancing software safety across the board.

From the editorial perspective, the absolutist stance of labeling Rust as “unsafe” risks detracting from the broader goal of improving safety. The focus should not be on the superiority of one language over another but on providing diverse, practical tools to reduce vulnerabilities. By acknowledging that absolute safety is unattainable, the key lies in objectively evaluating which method is most effective in each specific context.

References

• “Memory Safety Absolutists”, by itsallaboutthebit.com via ekuber — Lobsters, 2026-07-25T21:38:29.000Z (ARR)
• Source URL: https://itsallaboutthebit.com/memory-safety-absolutists/