What Zig felt like, coming from Rust

Over the past seven years, I've dedicated myself to Rust development, primarily on open-source projects, where I've come to appreciate its functional aspects like clean functions and expressive types. Zig has been on my radar as a potential C successor, combining lower-level, lightweight characteristics and earning recognition among serious languages.

Having worked with C earlier in my career, comparing Rust and Zig felt natural. However, my Zig experience began with this project, so some observations might seem naive or obvious to experienced Zig developers. I decided to reimplement JSONPath, a query language for JSON, in Zig, which I had already built in Rust. The initial surprise was the lack of advanced IDE support in Zig, with only basic syntax highlighting and autocompletion.

This forced me back to command-line tooling, which, despite being a drawback, ended up being an interesting part of the experience. One notable aspect was the `build.zig` file, which handled the build process surprisingly smoothly. I eventually settled on a setup that proved refreshing compared to traditional IDEs. Zig doesn't encourage deep folder structures like Rust, nudging developers toward a flat layout.

While this could potentially lead to scalability issues in large projects, it helped me reconsider file organization habits in other languages too. Testing in Rust tends to be more functional, with separate test files for each module. In Zig, while tests can be written inline, the verbosity can clutter projects. Configuring tests in Zig proved manageable, but the overall ease of writing and managing tests in Rust was more pleasant.

Ultimately, Zig's manual memory management, unlike Rust's automatic handling, contributed to a different testing experience.