Zig's Fil-C-Inspired Mode Reignites Memory Safety Debate
28 Jul 2026
Zig creator Andrew Kelley has proposed a new compilation mode inspired by Fil-C — and he didn't mince words about it, titling the GitHub issue a mode that is "actually memory safe (unlike Rust)." The provocative framing has reignited a long-simmering debate in systems programming: is Rust's much-touted memory safety overstated, and can C/C++-style languages catch up without sacrificing performance?
What's happening
Fil-C is an approach that makes C and C++ code memory safe by combining garbage collection (GC) with a technique called InvisiCaps. Its author argues that Rust isn't "truly" memory safe because its unsafe keyword lets developers bypass the language's safety guarantees. Kelley's Zig proposal borrows from this philosophy, suggesting a compilation mode that could retrofit memory safety onto Zig code using similar mechanisms.
No release date or technical specification for the new mode has been shared yet, and it's unclear whether it will become Zig's default behavior or remain an optional mode.
The catch: safety isn't free
Fil-C's approach comes with real trade-offs, according to the report:
- ABI incompatibility — Fil-C-compiled code doesn't interoperate cleanly with programs that weren't compiled the same way, complicating integration with existing codebases.
- Garbage collection overhead — GC can affect performance predictability, a concern for systems programming where deterministic behavior often matters.
- Slower execution — Fil-C code can run several times slower in some cases due to its GC and safety mechanisms, though no specific benchmark numbers are provided.
The data complicates the narrative
Here's where the story gets interesting. While Fil-C's and Zig's authors both frame Rust's safety as theoretically incomplete, real-world data tells a different story. Google's Android codebase — roughly 5 million lines of Rust — has had just one potential memory safety vulnerability found and fixed before release, translating to an estimated vulnerability density of 0.2 per million lines of code. Compare that to historical C/C++ vulnerability density, estimated at roughly 1,000 per million lines.
Sources differ on how to interpret this. Fil-C's and Zig's authors argue Rust's unsafe keyword undermines its memory-safety claims in principle. But Android's production data suggests that, in practice, Rust dramatically outperforms C/C++ on actual vulnerability outcomes — raising the question of whether theoretical safety purity matters as much as real-world track record.
Why founders should care
For early-stage founders building or evaluating systems-level infrastructure, this debate has practical stakes, even if the outcomes remain uncertain:
- If Zig's Fil-C-inspired mode matures, it could likely offer teams a path to retrofit memory safety onto existing C/C++-style code without a full rewrite — potentially useful for startups with legacy low-level codebases.
- The public sparring over what counts as "truly" memory safe may plausibly shift how startups market their tech stack's security posture, especially to security-conscious enterprise customers or investors.
- Performance costs tied to GC-based safety mean founders evaluating memory-safe alternatives should carefully weigh safety gains against runtime overhead — particularly for latency-sensitive or resource-constrained systems.
- The Android data suggests that real-world vulnerability outcomes may matter more than language-purity arguments when it comes to hiring decisions, security audits, or technical due diligence — a signal that founders should prioritize empirical track records over marketing claims when choosing a language or evaluating vendor claims.
What's still unknown
Several open questions remain: there's no benchmark data comparing Fil-C-style performance against standard C/C++ or Rust, no clarity on real-world production adoption of Fil-C, and no concrete definition of what "actually memory safe" means beyond the marketing language used by its proponents. Until Zig's new mode ships with technical specifics, founders should treat the claims — on both sides — as directional rather than definitive.