Show notes
Assertions vs Types: Design by Contract, Deterministic Simulation Testing, and Safety vs Availability (TigerBeetle Vol. 3)In this episode (volume 3), Kai talks with Alex about assertions, type systems, and design by contract, arguing it’s not “types vs assertions” but using both: types for cheap, structural guarantees and assertions where types become too costly or obscure logic. Alex defines assertions (in Zig) as a function that crashes the program on false, explains why disabling assertions in production is dangerous, and ties reliable assertion use to deterministic simulation/generative testing to exercise error paths. We discuss aiming for very high assertion density, repeating weak and strong assertions across call sites and callees to form an interlocking “net,” and note you don’t need special language features for DBC. We also cover safety vs availability tradeoffs, recovery/isolation boundaries (“let it crash” with recovery), TigerBeetle’s approach to correctness, a real cache/hash-table bug caught by an assertion, handling poison-pill failures via fix-forward and frequent releases, control plane vs data plane performance tactics for assertions, and why Alex doesn’t use AI to write TigerBeetle code.Chapters: