Why is 90% enough?
How about compile speed? Are you willing to wait an extra second to get 100%? How about 10 seconds? A minute? 10 Minutes? An hour?
Rust is notoriously slow at compiling and people have been banging on it for a while. At some point, you have to accept that the language, itself, has properties that make compilation slow.
Rust is 100% memory safe in specific places yes, but much less so when you have to dip into unsafe Rust. Unsafe memory access will always exist, you can't do anything about it. If you need to interact with the underlying system it's just something you have to deal with it.
Zig on the other hand isn't 100% safe in any one part, but it's 90% safe in nearly all parts. Zig recognizes the outside world exists, and makes it easy to write safe correct code given that reality.
Time will tell, but on average I suspect Zig and Rust will produce equally safe and correct software. The further away you get from the hardware the bigger Rust's advantage is, the closer you get to the hardware Zig has the edge.
No hidden allocations is a big one. If something allocates you have to explicitly give it an allocator. This makes tracking allocations much simpler. Combined with the test allocator you can also detect memory leaks.
Allocators also simplify memory management patterns. For example, it's trivially ease to use an arena. Then all your little allocations can be freed all at once, eliminating the need to track each individual allocation/free.
The defer keyword allows you to place the free call near the allocation (same with other resources that require closing). This isn't always possible of course, but it is a lot of the time and makes it easier to track.
Bounds checking is another big one. While loops/for loops with capture groups means you'll basically always see Zig programs iterating through arrays/slices in a manner that ensures you can't go out of bounds.
In terms of general correctness you have explicit nullability. If something can be null you have to mark it as such directly in the type. Then when accessing it you have to unwrap it and deal with the null case.
Same for errors. If something can return an error it's indicated in the return type. The error has to be unwrapped and then thanks to tagged unions you have to deal with all the different possible cases.
There are language conviences like the try keyword that let you side step some of the explicit handling, but even those are easy to track. And you know you're doing something that might bite you.
All of that adds up with a dozen other design choices to produce a language that makes it a lot easier to produce correct code.
Edit: In terms of concurrency I have to give you that one. The language is still pre 1.0 so we'll have to see what happens.
- No hidden allocations: Other languages already provide abstractions for this. Are hidden allocations really a significant issue in modern systems languages, even when managing memory manually? This concern is distinct from memory leaks or general memory safety problems.
- Allocators: It's easy to use an arena in C++ or C.
- defer keyword: Similar constructs have existed in other languages and even as a GNU C extension for many years.
- Bounds checking: Not an issue in Rust. The real source of risk has always been raw pointer manipulation, which Zig doesn't (cannot?) solve. How is it better than address sanitizer? Rust solves this at the language level.
- Nullability: GCC has long supported non-null attributes and unused-result annotations and Clang provides _Nullable. C++ goes further with type-level guarantees via std::optional, gsl::not_null and related abstractions.
- Errors: Zig’s approach is clean but equivalent mechanisms exist in C++ (std::expected) and Rust (Result and error types). It’s mainly cumbersome in plain C.
All of these are useful quality-of-life improvements but they don’t address my problems in systems programming (such as efficient and composable data structures, data movement, scalable concurrency, safe memory management ...and boiler-plate, lots of boiler-plate). These problems are easier to solve with a type system that allows me to make strong correctness guarantees and extend those guarantees.
Lastly, I’m unsure that any potential boilerplate reduction would be significant if implemented in Zig.
I don't think explicit use of allocators is distinct from memory leaks/safety. In Zig you will always know with 100% certainty that something is allocating memory. Making it easier to track what needs to be freed. This isn't always the case with C/C++. Also, as I said before, thanks to the way allocators work, Zig can provide a testing allocator which actively helps detect memory leaks. Their may be tools to help with this in languages like C/C++, but in Zigs case it's build right into the testing framework (which is also provided by the language).
To your point about arenas, or other memory management techniques, it's not that they aren't possible in other languages. Obviously they are. But I think it's safe to say that the default memory management mechanism in C/C++ is malloc/free. This leads a lot of people down the path of lots of little allocs that all have to be tracked and paired with a call to free. In Zig, by design, any method that can allocate should take an allocator as an argument (or you pass one when the struct is created and it uses it, but this style is falling out of favor with the community). This pushes developers towards alternative methods of memory management, encouraging them to not just fall back on mallow/free. Arenas, fixed buffers, and other mechanism aren't just possible in Zig, they are first class citizens.
I think there is a huge different between "defer" being part of the core language and being part of an extension. By being relegated to an extension it's usage is naturally going to be greatly reduced. The only two other languages I can think of that have this feature are Odin and Go, and Go is garbage collected.
Yeah, in Zig you're directly manipulating pointers. That's just how the language is designed. It tries to make it safer, but it doesn't eliminate it, because it's not trying to. If you think this is a bad thing, that's fine. I'm not going to try to change your mind on that point.
For nullability, everything you describe is opt in, and tool specific. It is baked into the type system in Zig the same way it is in Rust. It's just handle in (imo) a simpler and more straightforward way.
Zig's errors as value approach isn't that much different from Rust's in spirit, and I think both Zig and Rust outclass anything in C++ in this regard. It's an option in C++, but mandatory in Rust and Zig, which I think is where the real power comes from.
Ultimately, if you prefer Rust I'm not trying to change your mind. I was just trying to address your question. I don't think any of Zig's individual choices haven't been made in other languages, but I think the way Zig composes them all produces something novel and intriguing. All these little choices push developers in the right direction at every turn. Zig is still young, and it has plenty of rough edges to sand down, but I'm interested to see where it goes.
Like I said previously, I think in the long run will see the average safety/correctness of Zig programs be on par with Rust's. I think the two will just fill different niches.
I'm not trying to change your mind either; I'm just trying to understand the enthusiasm around Zig. There's a lot of it! To this day, I still don’t see what hard problems it would help me solve (that other languages make solving easier). At least for me, there’s little novelty or technical intrigue in that sense for any "systems" problem I've worked on.
- Explicit use of allocators: In my experience, hidden allocations rarely cause memory leaks. The real issues are forgetting to free memory, freeing the wrong pointer or managing overlapping objects. Some systems I’ve worked on also use different allocators or representations for the same types (e.g., for succinct encoding). Stronger type systems and optional automatic memory management make life easier when available.
- Arenas: malloc and free are as first-class as any other allocation mechanism in C. In C++, using alternative allocator types takes a bit more finesse. It’s an opt-in model rather than the default but still a relatively light lift.
- defer: I agree that its use would be significantly reduced but it’s easy to opt into. Many languages provide similar functionality either natively or through libraries, including Rust, C++, Python, C#, Java, D and Swift. Even C has this through GNU extensions (for fun, check out how far the Linux kernel takes this concept).
- Pointers: I love pointers but what helps performance more is explicit typing, stronger provenance and alias analysis.
While I'm not specifically advocating for Rust here, I don’t believe the average safety or correctness of a Zig program will match that of Rust. Rust is memory-safe by design, whereas Zig is not, and Rust also provides elegant solutions to several genuinely hard problems from memory management to events to scalable concurrency and an expressive type system.
I honestly don't think Zig is doing anything big and flashy, or highly revolutionary, the same way Rust (or even a project like Mojo) is. The stated goal was essentially to produce a modern C that pushed developers towards writing reliable software. I think it's hard to explain the enthusiasm because it's kind of greater then the sum of it's parts in some ways.
There's other stuff we haven't talked about here too, outside memory safety. It has incredible interopt with C, and the Zig build system is ridiculous. I don't know any other build tool that has the ability to handle cross platform builds for not only itself, but also C, in the way Zig does.
To be honest, I think a little of it might be the backlash to Rust as well. Portions of the Rust community (not all of it of course) are down right exhausting. And treat memory safety like it's some kind of moral imperative. I think there is a group of people who aren't enthused by Rust, and annoyed by the vocal minority of the community, that are glad to have something that is more suited to their sensibilities.