I read “unlike Rust” as a half-joke. What’s wrong with dissing other languages a little bit? The way some people are behaving, you’d think he said that Rust is a horrible language and nobody should ever use it. In the context of memory safety, it makes perfect sense to compare Rust and Zig, two newer systems level languages. I don’t understand what is intrinsically bad about comparison.
Responses like “is this bait?” are far more provocative than the issue title. Saying these reactions are ZSF’s fault, or
would be misleading, since the escalation was unprecedented. Andrew never insulted anyone’s intelligence in the first place. Moreover, the technical analysis he gave afterwards, which I’ll paraphrase as “runtime is bad for a systems language, stay in your lane, I know what makes Zig good and you don’t”, was neither new or nuanced enough to keep on the issue page, which needs to keep a good signal-to-noise ratio.
Aside from that, if there is value in Fil-C in c/c++ then there will, depending on the quality of the implementation, undoubtedly be value in a similar implementation for Zig as well. The question remains whether it is worth the effort, and how to keep it aligned with the mission/philosophy. I see some people arguing that the use case is too niche to be worth the effort, which deserves its own discussion.
Please read linked article before commenting on a post about it. The issue states
This proposal is to keep the existing optimization modes , while introducing an additional ABI (“fil”) alongside musl, gnu, msvc, etc.
No. The proposal adds an optional Fil ABI, usable with any optimization mode, which would enforce memory safety at runtime. Andrew believes most of it can be done on the compiler/STDlib side, with an estimated performance penalty of 1-6x depending on the codebase.
With Fil-C, programs such as OpenSSH, curl, CPython, Emacs and Wayland can be compiled with few/no source changes while receiving whole-program runtime memory checking. A similar implementation in Zig would be valuable for things like:
- network-facing services
- desktop applications
- security-sensitive tools
- running legacy C/C++ dependencies
- builds where performance is secondary
This would not necessarily compete directly with Rust. Rust is chosen for compile-time memory safety with minimal runtime overhead. If we’re talking about things like FMS for planes, rockets, mars-rovers, applications where lives are on the line and performance is critical, people will still prefer Rust. On the other hand, it is fair to say though that release-safe Zig is MUCH safer than C in many ways, and we got by with C in everything in the past. The proposal instead occupies a space closer to managed languages such as C# or Java, while retaining Zig’s native-code model, low-level control, and ability to compile existing C/C++ dependencies.
Currently we see well written code in languages like C# or Java being within a 0-2x performance range from languages like C++ in things like n-body and spectral norm. It’s too early to tell but if Zig were to take a 1-6x performance penalty it would likely be on par with or slightly slower than those dedicated GC languages. But Zig encourages you to write better code than the other languages do so it is uncertain how it would play out in practice.
Regardless, I’m happy to see the ZSF focusing on memory safety.