So, hopefully, the tech people involved in choosing a database for their project understand that, and do their own correctness and performance testing before making a decision. As for the business people, the tigerbeetle.com landing page doesn't mention Zig at all, although it probably will come up when they "ask AI" for a comparison. So, yeah, probably some risk. Perhaps the LLM will also point out the Jepsen report on Tigerbeetle to offset it.
Everybody has a plan until their compiler compiles an if-else wrong, and that's the level of instability that Zig had when I left it and Tigerbeetle committed to it.
No amount of testing is going to save you from that and it's a completely avoidable unnecessary self-inflicted problem, as a technical person that makes me seriously doubt every other decision you make on top of that. So I feel like they've already been fighting an uphill battle, where they have to proof that they have a stable system, despite an unconventional early stage foundation, and I feel like that it just got even harder.
But this link has got me concerned. When I get more ibverbs work done ill see how good/bad it is in rust.
In this kind of extremely low latency high throughput work there is hardly any (mostly none) MT data structures. Memory is pre-allocated for one pinned thread. Atomics are not much used either. So rust isn't going to help on design much. But I think rust/c interoperability is worse than zig.
In fairness to zig many of these issues were closed when zig 0.16.0 was released, which is what im using.
We'll see