In the general sense, no, not yet, of course, but in one sense, Zig is probably more production ready than Rust, for example on embedded systems with obscure architectures where OOM-safety is essential.
Here is a talk on using Zig in exactly this kind of environment in production:
> In the general sense, no, not yet, of course, but in one sense, Zig is probably more production ready than Rust, for example on embedded systems with obscure architectures where OOM-safety is essential.
I mean, FWIW, Rust is fairly ready for embedded systems, even when OOM-safety is essential. There are crates dedicated to providing fallible memory allocation primitives for exactly those use-cases.
With that said: I do believe Zig would work a lot better than Rust in severely resource-constrained environments. Rust has a few pitfalls that can easily cause a code size explosion (anything using core::fmt, for instance). And zig's constexpr appear more powerful than Rust's current stable const fn, which can be critical to writing maintainable, small code.
I've worked on a Rust reimplementation of a bootloader that had to fit in 8KiB of RAM, and I often went over accidentally by having a panic handler pull core::fmt. I haven't tried Zig for the same use-case (yet), but from a cursory glance, it appears to be less prone to this kind of code-size explosions.
