I’m a long time C/C++ developer, although my use has waned over the last few years.
I’ve been looking at Zig for some months now. We have two REST APIs written using Python and FastAPI (time to market). We’re very interested in Zig/Zap but our concern is that neither seems like they’ve reached production status yet.
A side issue is that there isn’t a production ready Redis client for Zig, so we assume that we’d have to use one written in C.
Sorry if this has been beaten to death, but a quick topic search didn’t turn anything up and I couldn’t find a roadmap.
I don’t think Zig is near enough 1.0 to be able to predict when 1.0 happens.
That being said, if you are ready to deal with upgrades (in particular, if you control all your dependencies), and are willing to fill in the gaps yourself, it’s totally fine to use it in production.
Ready for production != 1.0 != stable API != finished.
To make a decision here, it would help to understand what specifically do you need from the language in terms of maturity.
What 1.0??? My web browser is 137.0 and has essential parts written in the Crab language (which is 1.86 and claims to be safe and stable), and it runs like a piece of crap… lol
This redis library (by @kristoff ) has been recently brought up to zig 0.14 from 0.11:
It is actually pretty approachable and could definitely use some help! I only recently got it to work on 0.14 through mostly some syntax changes but I think there are a lot of easy wins regarding test coverage / cleaning up some stuff / using more of the standard library (since the standard library has improved a lot since).
Tbh, dealing with Zig language updates since around 0.12-ish isn’t any different than dealing with new warnings in minor C/C++ compiler toolchain updates, you’ll have to touch your C/C++ code base to fix those warnings the same way you’ll have to fix Zig code after a new Zig version is released.
In that sense, C/C++ compilers never reached a “1.0 status” but C/C++ is definitely used “in production”, and tbh, I’m also sceptical of the promise of Zig 1.0 about language stability. I’d rather have a ‘living language’ that requires fixing my code base from time to time than having to live with a language where the design warts cannot be fixed because of a backward compatibility promise.
Nobody expects library APIs to remain set in stone either, and we’re used to fixing our code after upgrading to a new library version, and it’s not a big deal.
The difference I see is that the core team hasn’t ruled out major changes to the language.
The last two updates have been mainly cosmetic, but that doesn’t mean every subsequent update on the road to 1.0 will be similarly minor. There’s a subjective sense that most things won’t change, or won’t change much, but that’s far from a compatibility guarantee.
For those of us around here, that situation is fine, but for others that level of uncertainty might not be acceptable.
Thanks for explaining that the API isn’t guaranteed to be stable in 1.0. I really want a stable API because I and many small businesses don’t have the time interest in fixing the codebase after each update.
You never update your dependencies either I guess?
IME updating the dependencies in an average JS/TS project is much more hassle compared to the Zig language and stdlib changes.
E.g. to elaborate a bit: I’d take breaking changes over a too strict backward compatibility philosophy any day, because the only other options are either a stagnating language and stdlib or sediment layers of accumulated cruft.
Let C++, OpenGL and Vulkan be a warning, and a model of how not to do it
I guess this was why java has LTS, while many companies with their enterprise being stuck at java 8. Business usually talks about availability and stability, so I guess the better way is to backup the dependencies that you are using (if the dependencies you are using don’t have releases), and only update zig if it has critical issues.
The real question is: Do zig have LTS or do we have a agreement for specific version of zig for business purpose?
Edit:
I wish they wrote migration guides for how to update between versions.
I think they did in the release notes, but it might not covers all the case. For example, this was for the alternative for the deprecated BoundArray.
I’m going to make you defend your inclusion of Vulkan on that list.
The fact that Vulkan is backward and forward compatible is quite remarkable. Sure, I don’t enjoy the Vulkan API, but I’m not sure I agree that it’s a negative example. Doubly so because the Vulkan API has a reflection into the hardware that it must mirror–not all the API decisions are malleable like C++.
As for API “cruft”, that hasn’t been established for very long timewise. The 1.3 spec was only 2022 and the open source drivers only nominally reached compliance in 2024 and still don’t support a whole lot of stuff that they really need to. Zig has been a godsend because when I hit a dark Vulkan corner and it contains a Grue, I can simply transfer my code to a Windows machine and compile it there to check if the problem is my code or an open source driver bug.
Yes, the “bindless” and “dynamic rendering” stuff is much easier for desktop users. However, the tiling architectures (aka everything mobile) can’t really make use of that stuff and still need to use the old subpass methodology (although I think 1.4 finally makes the newer stuff available even for tiling architectures).
If you’ve got an example of an API carrying out a task like Vulkan that you consider “good”, I’d love to look at it.
It really isn’t a lot, and it’s split into sections so you can skip what you don’t immediately care about.
You probably thought it was much larger, as the only indicator you’re out of the reader/writer section is a slight increase in the size of the section headers.
As well as the following sections being reader/writer adjacent.
But it is definitely missing a ‘basic usage section’ that would have made everyone’s lives easier.
It could work briefly for older zig version, but it has to be something that remains unchanged for a long time. Let me tell you about the time I tried it to use it with some pull requests.
I sometimes use LLM to research some concepts and brief idea, and there was a time I have first encountered the anyopaque type. Even I have read some documentations, I still got confused since I didn’t have any idea why I should use it instead of using struct, so I told copilot to generate some examples to let me know what is the purpose of it. Its code didn’t run correctly and I need to apply additional casts to make it work; nonetheless, the objective still executed correctly since the example code and the explanation can still let me understand the needs and the mechanisms of the type.
However, that was LLM at best from my experience because I was working on a pr when 0.15.1 just rolled in, and the cutoff date of copilot was 2024 which its knowledge base only contains 0.14.0 experimental at most. This caused a huge issue where it had no idea what is the latest Writer and Reader API, resulting in either writing a lot of code that only works for the old version or it just “invented” some non-existent types.
Thus, LLM is good for getting brief idea, or perhaps the more complicated concepts only if the example are abundance in the web, but it is exceptionally bad to aware of they don’t know the topic or the topic has been updated.
no way I am reading through all of that to update my reader/writer.
Ctrl + F and the search functions in the forum are always your friend and this could massively save your time, use it wisely in long passages. I didn’t read all the details when I was researching the alternative for BoundedArray, and I just searched the keyword and jumped into the section that matches with the keyword. Other than that, considering the rapid update of zig, unfortunately, you have to gets your hands dirty to explore and experiment the new changes with patience unless you have no problem using zig with one or two versions late. (could be a good or a bad thing depending the dependencies you used and the purpose of your project.)
TL;DR: I think if Vulkan would at least not expose extensions that had been incorporated into core, and also not expose deprecated types and function prototypes in the header when I’m requesting a specific device version (like 1.3 or 1.4) the API would be much less confusing to newcomers.
The runtime flag for the version is already there in the AppInfo struct, the header declarations could be scoped with a define. But that’s the bare minimum IMHO. It would be better if instead of 1.4, Vulkan would be 4.0 now, where each major version should be a fundamental and breaking API cleanup instead of accumulating one sediment layers on top of another
In the end, Vulkan suffers from the same main problem as GL: The API is not ‘designed’, but instead cobbled together from random vendor extensions that are promoted to the core API. Too many cooks and no consistent vision.
