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.
