As someone who has used Zig in anger for the last year (to build an in-memory db coincidentally). I find the idea of using it in production, especially for financial data, absolutely unsettling.
The language is awesome, and developing rapidly, but you don't have to wander far to hit a compiler bug, there is no advanced testing infrastructure a la quick-check and friends, and documentation and documentation tooling except for the core reference is non existent.
I see a bright future ahead for the language, and I'm glad that I got a Zig version on release day, but if you want to write production code, you might wanna stick to Rust or C for now, or put a small team on just improving the ecosystem.
We do in fact have some extremely advanced testing infrastructure, even going as far as using a deterministic Linux hypervisor to do coverage guided fuzzing of our compiled binaries from the outside in. At the same time, we fuzz from the inside out, also Deterministic Simulation Testing, with a ton of assertions (literally a 1000+ and counting) as a force multiplier for fuzzing. Our experience in all this, is that while Zig is early in terms of timeline, the quality is nevertheless extremely high.
Andrew and team know what they're doing. They've got some of the best people in the world in their respective fields. For example, Frank Denis of libsodium heading up Zig's crypto.
Beyond this, we do the basic things like consciously restrict our use of language features to stable features only (which may be why our experience has not been the same as yours with respect to compiler bugs?), and invest in our own I/O stack around io_uring instead of depending on the std lib, which we know will churn.
Two of our team are Zig core team members and we sponsor the Zig Software Foundation to invest in the ecosystem. Don't forget also that Zig's ecosystem is really C's ecosystem so there's an escape hatch there.
Also, TB is not yet production ready. We'll ship our production release when we're confident that our TB binary is safe, or able to shut down if it detects any safety violation.
At the end of the day, databases are a big investment. It's important to think about the next 20 to 30 years. C would absolutely have been the wrong choice for that future.
As you say, the future is bright for Zig, and we're convinced that Zig is the right choice for a database that follows embedded coding standards with respect to memory. For example, TigerBeetle has to handle memory allocation failure, and only does static memory allocation so we never malloc or free after startup.
I got a minor glimpse into the mindset of the TB team a while ago -- on the consensus bits and TB's choice of protocol -- and was impressed with the rigorous and ++informed approach that guided the design of that aspect of the system. Joran even managed to create a Garbo Speaks moment by finding Brian Oki and interviewing him. They are quite thorough! /g
Thanks, it's a pleasure! Yes, with packed structs it's important to keep things carefully aligned.
Have you seen this post [1] about struct packing? This is what we did for TB's structures, so that we can switch them to `extern struct` for C ABI compatibility. It also helped side step the packed struct bugs.
I see a bright future ahead for the language, and I'm glad that I got a Zig version on release day, but if you want to write production code, you might wanna stick to Rust or C for now, or put a small team on just improving the ecosystem.