A Rust veteran's first Zig project: the friction was tooling and layout, not safety

A developer who says he has spent the last seven years working in Rust, mostly on open source ^[1], reimplemented one of his own libraries in Zig and wrote up what changed. In the published account, the things that actually cost him time are editor tooling, build invocation and file layout ^[9][11][14] - not allocators, not lifetimes, not memory safety ^[19]. If you are using write-ups like this to choose a systems language, that absence is the useful part.

The setup is more disciplined than most language comparisons. Rather than a benchmark or a toy, he re-ported something he had already shipped: JSONPath, the JSON query language specified in RFC 9535 ^[7]. The Rust implementation, jsonpath-rust, already existed; the new one is zig-jsonpath ^[8]. Same spec, same author, same problem shape, different language. He also states the obvious caveat himself: this project is where his Zig experience begins, and some of his decisions were shaped by Rust habits rather than Zig idiom ^[5]. He leans functional in Rust - clean functions, expressive types ^[2] - which is exactly the habit set you would expect Zig to punish.

It did not punish it in the way the usual safety-versus-speed framing predicts. The first thing that caught him off guard was the near-total lack of IDE support: coming from RustRover and other JetBrains tools, Zig offered him little beyond syntax highlighting and basic autocompletion ^[9]. That pushed him back to the command line, which he ended up rating as one of the more interesting parts of the experience ^[10], and eventually out of a full IDE entirely, to helix plus alacritty plus zellij ^[12]. The replacement for IDE run configurations was build.zig, which he describes as surprisingly easy, settling on a fixed set of commands: `zig build test`, `zig build test -Dfilter="..."` for a single test, `-Ddebug-query=true` for debug output, `zig build compliance` for the compliance suite, and `zig build check` for unit tests plus compliance ^[11].

The second finding is about structure, and it is the one that transfers. In Rust he reaches for folder hierarchy early, almost by default ^[17]. Zig permits nesting but does not encourage it, and nesting brings import friction ^[14], so it nudges you toward flat files, with a `model_<companion>` file beside a model when something needs a companion ^[15]. He deferred the hierarchy and never needed it on this project ^[17], while conceding the pattern will not scale to large projects - only that the threshold for needing structure was much higher than he expected ^[16]. His own conclusion is the honest one: it made him ask whether he organises files because a project needs it or out of habit ^[18].

Note what is not in the published text. It stops mid-sentence in the side-by-side `src/` listing, and contains no discussion of allocators, lifetimes or memory management ^[19]. So the tidy thesis - explicit allocators and manual lifetimes traded against type-system leverage - is not evidenced here. Three named frictions, zero of them about memory ^[20]. Treat the memory-model question as still open, and treat the tooling and layout observations as the reportable result.

What to watch: whether the follow-up covers allocator plumbing and where the type system stopped carrying him, since that is the part of the comparison an operator would actually budget for; whether zig-jsonpath's compliance suite ^[11] holds up against RFC 9535 ^[7] as the flat layout grows; and whether the editor gap ^[9] narrows enough that the command-line discipline he adopted stops being mandatory and becomes a choice.