There’s been a few news stories that have highlighted how maintenance of some major open-source projects is down to a single person, and I’ve seen some people say there’s a preference to do rewrites “with modern tools” rather than invest in old code-bases. Sounds like madness to me.
Seeing as “Maintain it in Zig” has been one of Zig mantras I was wondering if anybody was aware of a project that was being successful doing just that. It’d be nice to be able to point people to example that’s different to just a complete rewrite. Ideally I’d be looking for something that:
Is historically a C project with a good level of investment in the code base.
Has the build system replaced with build.zig
Has started an incremental resolution of issues using Zig.
Neovim is at stage 2, if you look at their repo they have a build.zig. I believe they are interested in moving away from C and also they don’t seem to like Rust much, so Zig would be a viable candidate. But if that will happen, it will take some time, as they have not yet fully replaced their other build scripts with the build.zig (which currently in beta essentially, afaik).
In my experience, build scripts tend to break with every Zig version update, requiring minor rewrites. Not a big deal for a Zig project, but annoying when maintaining a non-Zig project when your build system has breaking changes every 6 months. I expect Zig will become a more appealing build system for C projects after 1.0.
There is nothing wrong with sticking to a specific zig version, especially when only using the build system.
And only updating every few versions/when a beneficial change or feature is added.
I agree, and when I used Zig as the build system for a C++ project on a job last year, I bundled 0.14 right into the repo rather than using the system Zig version. Still, most people want to be able to update their dependencies (build system, libraries, etc) to get the latest bug fixes without rewrites, and tend to view regular, breaking changes as a problem.
I think the most compelling reason to use build.zig for non-zig projects is that it makes them easy to use as dependencies for other build.zig projects, but this won’t work if the projects require different zig versions.
I wasn’t really thinking that the build system was the heart of what I was asking. More just a step along the way. I’m thinking of the situation where you have a C code base and you start incrementalally replacing the C with with Zig.
Is it really that because the language isn’t stable, this isn’t a practical method yet?
Probably the effort without any immediate gains dissuades a lot of people.
I personally started using zig, because I wanted to write some C code for a STM32 project of a colleague. For that case zig was the best option:
I did not have the micro controller at hand and I did not have any native C tool chain installed
the built in testing capabilities were great in that case for “test driven development”
last but not least, I could install it now instead of asking the IT department for permission and then wait for an admin password
But I doubt I would have been able to port the whole project to a zig tool chain (or microzig). I never even thought about it. That simply would have been too much work, if even possible. Also, my colleagues would not have been too thrilled Maybe, I should try something similar now that I know a bit more!
Maybe, I should try something similar now that I know a bit more!