4 ms·
We think carefully about this. We do in fact have some extremely advanced testing infrastructure, even going as far as using a deterministic Linux hypervisor t
by _vvhw 4y ago
We think carefully about this.
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.
- eternalban 4y agoI 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 https://www.youtube.com/watch?v=ps106zjmjhw https://www.youtube.com/watch?v=ps106zjmjhw (Joran, I am happy to see your team and product are getting the exposure that imho they certainly deserve.)
- _vvhw 4y agoThanks @eternalban! Awesome to read your comment here—appreciate the well wishes!
- j-pb 4y agoThanks for the insight on how you mitigate these issues! We're doing a lot of data-structure work involving bit stuffing, i.e. packed struct, which is very unfinished indeed.
- _vvhw 4y agoThanks, 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. [1] http://www.catb.org/esr/structure-packing/ http://www.catb.org/esr/structure-packing/