Zig makes a lot of small choices that pile up to push you towards safety/correctness in your code.

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.

Thanks for the response. I look forward to seeing how the type system evolves.

- 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.

To be fair we are pushing up against the limits of my experience here. I'll do the best I can to address your points, but someone more experienced could probably do a better job.

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 curious to see how Zig approaches the hard problems and hopeful it produces something remarkable enough to make me jump ship (like Rust has for some of my projects).

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.

Oh shit, I totally forgot about comptime lol. To be fair it doesn't really have anything to do with memory safety, but I think it's part of what contributes to the excitement. Instead of a macro system you can just write Zig that executes at compile time. Cool idea. I think Johnathan Blow is doing something similar in Jai, it actually may have been the inspiration for Zig's comptime.

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.