What Zig felt like, coming from Rust

My 7-year journey as a Rust developer has given me a solid understanding of the language and its ecosystem. I'm particularly drawn to its functional side, characterized by clean functions, expressive types, and the like. Zig, however, has been on my radar for some time as a potential C successor, offering lower-level, lighter-weight features and gaining recognition in the programming world. Given my background in C, comparing Rust and Zig seemed like a natural fit.

Important to note upfront: my exposure to Zig is limited to my current project. Consequently, some observations may appear naive or overly simplistic for those who work with Zig daily, and many decisions made during the process may not have been optimal, rather influenced by pre-existing Rust habits. That said, I've embraced whatever cross-language intuition I've accumulated over the years, for better or worse.

To ensure a fair comparison, I chose to reimplement a project I had already completed in Rust, rather than a toy project or an overly complex one. I opted for JSONPath, a query language for JSON as defined in RFC 9535. The Rust version already existed (jsonpath-rust), and my goal was to recreate it in Zig (zig-jsonpath).

One aspect that caught me off guard was the IDE support, or the near lack thereof. I was accustomed to using RustRover for Rust and various JetBrains tools for other languages, so Zig's minimal support - primarily syntax highlighting and basic autocompletion - was a stark contrast. Initially, this seemed like a disadvantage, but it ultimately forced me back to basics, learning to navigate the language largely through the command line.

While initially a drawback, this experience proved to be one of the more interesting aspects of the project.

One significant lesson was the use of build.zig, which proved surprisingly easy to work with. I eventually settled on a setup that emphasized simplicity and ease of use. This experience encouraged me to move away from a full IDE towards a helix + alacritty + zellij setup, which I found to be more efficient.

Gone are the days of spending significant time trying to find the right balance between file size and folder depth, as Zig does not encourage such practices as it does in C. While nesting files and folders is possible, it introduces some import friction, and the question then becomes: what is the real benefit in terms of readability?

In practice, it's often more beneficial to keep everything in one place. Zig encourages a flat structure, with related entities often placed in a single file. This approach may not scale well to larger projects, but at some point, a real hierarchy becomes necessary.

In Rust, I typically rely on folders from the outset, almost by default. However, in Zig, I've found that I can defer this organization until later, often not needing it at all by the end of the project. This difference in approach has made me reconsider my file organization practices in other languages as well. A project's complexity can often be gauged by the extent to which folder structure is required from day one.