I don’t intend for this to be an inflammatory or otherwise negative post. I’m honestly curious what others think about this:
What prevents you from using Zig in production?
Lacking enough skill / experience with Zig
Zig (the language) is too unstable
The ZSF isn’t supported enough
Miss-compilation risk
Std lib not stable enough / good enough
Not enough libraries available
Target not supported
Need better async / concurrency support
Colleagues are not familiar with Zig / don’t trust it
I don’t lead the project
Authorship tooling (language server, linting) not good enough
Static analysis, provability
Certifications, regulations, government stuff
Debugger tooling
Documentation generation
Language interoperability
Compiler too slow
Talent pool too small
Use-case better handed by another language
LLM’s are not good at Zig
0voters
I use zig in production!
0voters
Personally, it would have been difficult for me to deploy it a year ago due to my own inexperience. The projects I work on (industrial controls), often have shifting requirements that require me to quickly develop solutions to low-level problems. Things like “oops! this sensor uses the Modbus protocol! figure it out!”. So being able to just import a library that has already been developed for the majority of my tasks really accelerates development, even if it may not be the most long-term sustainable solution. Diving deep and re-implementing everything is sometimes just too slow. This is why the majority of my applications are Python. One counter argument for this is c-interoperability. Though honestly C is just hard.
Now with more experience under my belt, I am confident that Zig would be a good solution for a well-understood, limited-scope problem.
I use zig plenty in personal and oss projects (around 45kloc written so far). But for professional projects it has to have some sort of language stability guarantees. So basically that means waiting for a 1.0 release.
I’ve tried for many years to find a “fun” language to use at work, but it’s so hard to beat the velocity of PHP for “just throw together some forms and we’ll probably never touch them again”.
Though I have picked one project to attempt to port to Zig.
For me the issue is the segment of the industry. I work as a consultant for cloud computing. So until Zig gets into the industry far enough that companies ask us to work with Zig, I won’t see it.
But as of right now, I have no concern using it for side projects.
Could one of the static analysis people elaborate? Zig is already statically typed, what are you missing? Are you waiting for additional static memory safety guarantees? Like stack overflow / unbounded recursion being prevented?
In my experience, zig being a compiled language already provides better guarantees than python + mypy for example.
Also, are your use cases not already requiring extensive test coverage?
I wouldn’t say strange. I’m a big fan of new stuff like Zig and go, but when it comes to dangerous things like this, you want them using the dusty old crap that is reliable to the core.
