From the user's perspective, this doesn't matter at all. Zig is implementation detail, what we actually ship is a fully statically linked native executable for the database, and "links only libc" (because thread locals!) .a/.so native "C" library for clients. Nothing will change, for the user, if we decide to rewrite the thing in Rust, or C, or Hare, nothing Zig-specific leaks out.

Form the developer perspective, the big thing is that we don't have any dependencies, so updating compiler for us is just a small amount of work once in a while, and not your typical ecosystem-wide coordination problem. Otherwise, Zig's pretty much "finished" for our use-case, it more or less just works.

Zig's pre-1.0 status also refers more to API stability. The language and tooling already has more quality, at least in my own experience, than if we had picked C, which was the only other choice available to us when we made the decision to invest in Zig's trajectory back in 2020, given we needed to do static allocation and that any sort of global allocator was out of the question.

But, no. On the commercial side, I don't think we've had one conversation with a prospect or CTO or engineering team where they were concerned that we picked a systems language for the next thirty years. And while Zig is a beautiful, perfect replacement for C, I think the real reason the question has never come up, is that our customers come to us instead of us to them. We're not trying to convince anyone. They're already appreciating the extensive end-to-end testing we do on everything we ship.

However, I should emphasize again, that given all the assertions, fuzzing and DST we do, Zig's quality can't be overstated. It holds up.