A Rust Developer Tries Zig: 'I Found the Resulting Code Less Readable'
What Zig felt like, coming from Rust
After seven years writing Rust, a developer reimplemented his jsonpath-rust library in Zig to see how the language feels. He found Zig's lack of IDE support pushed him to a CLI workflow, its flat file structure kept the project compact, and its explicit allocators made memory management tedious compared to Rust's automatic Drop. While Zig's manual approach caught leaks via TestAllocator, he ultimately found the code less readable than its Rust counterpart.
All told, this reflects each language’s design goals and target domain, and it’s a reasonable trade-off but subjectively, I found the resulting Zig code less readable than its Rust counterpart.
- torginus
Personally while I'm somewhat pragmatic about Rust, I do have to admit it fills a niche that no other language does currently: that of a high-performance, zero runtime memory-safe language.
By memory-safety I mean the basic 'no crashes and corruption' version, that's fulfilled by Java, Go etc., but not by C++ and Zig.
I'm a C++ dev among other things, and I have enough experience to know, you really can't hand C++ to a novice dev (even one who uses smart pointers correctly), and expect an app with no memory related crashes/issues.
For this reason only, I generally thing C/C++/Zig is a language for typical professional projects/applications (which are written usually in GC languages nowadays).
I think it's a hard cutoff criteria. Most programmers/orgs simply cannot work with memory unsafe software. Most commerical C++ codebases leak.
This is basically the most important and common 'niche' of SW dev, which for some reason has been somewhat neglected, and I don't really consider Rust a great fit here either, but it doesn't lack anything that would disqualify it.
Swift would be another good choice, but it seems that language is very tied to the Apple ecosystem.
The only (non-Apple) language that understood EXACTLY what these people wanted imo was Object Pascal/Delphi in the 90s to early 2000s but seem to have died out unfortunately.
- Syzygies
For various purposes I work on a language comparison project that includes C and candidate successors such as Go, Zig. One question is the language to use for an archival port of a 1980's computer algebra system written in 32-bit K&R C. While Zig is a great debugging compiler, it's not yet stable enough to be the best target language for archival purposes.
https://github.com/Syzygies/Compare
So you're in a restaurant where you don't speak the language, you can't read the menu, but you see three price points for set meals featuring the house specialty. (Say, "Crossing the Bridge" noodles in Yunnan.) Which do you choose? My tour guide, the author Fuchsia Dunlop, later agreed with me this is obvious: The middle choice.
So you're choosing between Go and C23 as candidate successors to K&R C. They both have "royal blood". One got the name. Knowing nothing more, which do you choose?
The answer is equally obvious. The one that got the name also got the warts.
- csense
One of the section headings says "Mutation vs. immutable monad is the core difference" but this is not true.
The code in that section is clear in its purpose and broad outline: "Give me a function and data; if the data is bare apply the function to it; if the data is a container apply the function to each item inside it."
You can absolutely do that with immutable data structures in Zig. You just have to pass an allocator to the function (i.e. instead of calling data.flat_map(f), you call data.flat_map(a, f) where a is your allocator).
That the Zig version of the code does mutation is a matter of programmer choice, not something imposed by the language.
(Also, what do monads have to do with it?)
- weinzierl
Two additional points:
1. Tooling (as an extension to the mentioned IDE support point). Zig and Rust are both praised for their tooling and I think rightfully so. The C/C++ interop story and the cross-compiling story in Zig are great. From the standpoint of a working practitioner though I think Rust is way ahead. Not surprising given that Zig is much younger, but something to keep in mind.
2. Compile Time Stuff: Here Zig is praised and Rust not so much. I think this is undeserved. Rust has much higher aspirations for their compile time features, namely that outcome must be identical regardless when the code runs. This is a very useful property but makes the task much harder and fundamentally incomparable with Zig comptime.
- computerfriend
> Zig, by comparison, offered little beyond syntax highlighting and basic autocompletion.
Zig has a language server and "The majority of LSP features are supported" (https://github.com/zigtools/zls#features).
- Panzerschrek
> Rust: Drop runs automatically at scope end, so this specific bug simply doesn’t exist.
That's why having no auto-destructors is a dead-end. This is the greatest mistake of such languages like Zig or Odin.
- plqbfbv
Maybe I'm not that deep into programming, but I don't understand the hype about Zig?
I programmed in rust a bit and can't say I'm an expert, but in my view rust mostly-solved the memory management problem at compile time and without a GC, and it works very well. The biggest con and cost I've always seen repeated so far is that "it's slow to compile", and I get that, if you're past 250 crates the final --release link tends to become noticeable, but there were improvements to incremental compilation.
On the other hand - looking at the syntax from this post - Zig feels a blend of javascript, python and golang syntax that still requires memory management. So a nicer-written C that inherits all the issues from C? From the post: no functional programming, data mutation, memory leak, double-free, memory corruption.
Personally I'd rather trade a couple minutes of final link every time when this is the other option.
- sharktheone
> The first thing that caught me off guard — and honestly, who would’ve expected this to be the memorable part — was IDE support, or the near-total lack of it.
Yeah this was also surprising to me the first time I tried Zig.
ZLS exists, but back when I last used it it was unstable and crashed frequently.
I wrote a small toy JVM. In case anyone interested: https://github.com/Sharktheone/yeeeeem
- tialaramex
I think when we're looking back on the 2020s we'll be struck by the Allocator obsession
All of the Handmade "C successor" languages seem to have this obsession, including not only Zig but Odin, C3 and Jai.
For some toy problems you can do clever allocator tricks and get a huge perf win. For example Jai and Odin both seem to really want you to write code which can throw away a "per-frame" arena periodically so they're not paying to track allocations in the arena because they're all thrown away at the same time.
But a lot of real world software just isn't that simple. This doesn't make such features worthless, it just means they're one of a thousand tools the experienced developer could want in their toolkit, not really deserving headline status.
- janden
Articles like this make it clear that I have no idea what I'm doing. And I probably never will.