_vvhw

Joran from TigerBeetle here!

Awesome to hear that you're excited about Zig.

Thanks for sharing the link to our repo also—would love to take you on a 1-on-1 tour of the codebase sometime if you'd be up for that!

Anecdotally again, but I've been coding in Zig since 2020 and have hit I think 2-3 compiler bugs in all that time?

The first was fixed within 24 hours, in fact just before I reported it. The others had clear TODO error messages in the panic, and there were easy enough workarounds.

Yes, we're planning also to add a kill switch to the allocator that we switch on if anything allocates after init().

Ah, missed that, thanks! I've updated the comment.

We're aware of this, in fact, and do have a plan to address virtual memory. To be fair, it's really the kernel being dynamic here, not TigerBeetle.

Static allocation has also made TigerBeetle's code cleaner, by eliminating branching at call sites where before a message might not always have been available. With static allocation, there's no branch because a message is always guaranteed to be available.

It's also made TigerBeetle's code more reliable, because tests can assert that limits are never exceeded. This has detected rare leaks that might otherwise have only been detected in production.

Joran from the TigerBeetle team here.

The limit of 70 lines is actually a slight increase beyond the 60 line limit imposed by NASA's Power of Ten Rules for Safety Critical Software.

In my experience, in every instance where we've refactored an overlong function, the result has almost always been safer.

Thanks!

Joran from the TigerBeetle team here.

Appreciate your balanced comment.

To be fair, we're certainly concerned about logic errors and buffer bleeds. The philosophy in TigerBeetle is always to downgrade a worse bug to a lesser. For example, if it's a choice between correctness and liveness, we'll downgrade the potential correctness bug to a crash.

In the specific case of message buffer reuse here, our last line of defense then is also TigerBeetle's assertions, hash chains and checksums. These exhaustively check all function pre/post-conditions, arguments, processing steps and return values. The assertion-function ratio is then also tracked for coverage, especially in critical sections like our consensus or storage engine.

So—apologies for the wince! I feel it too, this would certainly be a nasty bug if it were to happen.

Joran from the TigerBeetle team here!

We have a secret plan for this too. ;)

Good to be back—Joran from the TigerBeetle team here!

Static allocation does make for some extremely hard guarantees on p100 latency. For example, for a batch of 8191 queries, the performance plot is like Y=10ms, i.e. a flat line.

And memory doesn't increase as throughput increases—it's just another flat line.

I personally find it also to be a fun way of coding, everything is explicit and limits are well-defined.