TigerStyle! (Or How To Design Safer Systems in Less Time) by Joran Dirk Greef

What Hacker News said

Strong rec samatman · 2024-07 · on “A write-ahead log is not a universal part of durability”

I second this recommendation. I'm impressed by what TigerBeetle has accomplished, and would love to see more of the industry approach software engineering with their philosophy and rigour. The TigerStyle video is well worth watching for anyone who wants to build defect-free software systems, or recognizes that this is the correct thing to aim for. [this video]

Recommends samatman · 2024-09 · on “Why Haskell?”

> Zig will be easy to understand and use but too unsafe to use for important applications This is an outside perspective on Zig, and I have to say, not an informed one. If you'd like to understand Zig (and what I mean) better, this video is a good start: [this video] Zig is, right now, being used for high-assurance systems where correctness is a terminal value, and it provides many tools and affordances to assist in doing so. It isn't a good choice for projects which give lip-service to correctness, but for ones which actually mean it, and are willing and able to put in the effort and expense to achieve it, it's an excellent choice. I'm willing to gloss that domain as "important applications", bu

Recommends jorangreef · 2025-04 · on “We Designed TigerBeetle's Docs from Scratch”

Joran from TigerBeetle here! We didn't design our docs because it was "a fun thing" (as suggested) but rather because we simply care deeply about the experience of developers reading our docs. For example, concerning performance and offline use, which were further reasons we gave in the post. We have a high bar for taking on dependencies. We don't take on dependencies automatically without justification. It's just not a philosophy that we share, to assume or to insist that everything needs to be a dependency. (The discussion on CSP in our post was also not given as motivation, but as an example of the thought process that went into this. Again, as per the post, it's a matter of defense-in-de

Recommends jorangreef · 2025-07 · on “NIH is cheaper than the wrong dependency”

We apply this pretty much fully at TigerBeetle [1]. Reason being that TigerStyle is not only about shipping safer software, but shipping it in less time [2], factoring in the Total Cost of Ownership to end users. In other words, not only optimizing our development time, but also all the time spent in production with subsequent fixes. [1] [LINK] [2] [this video]

Recommends jorangreef · 2025-07 · on “NIH is cheaper than the wrong dependency”

Appreciated your post, Lewis! From the beginning, TigerStyle was intended not only for TigerBeetle as infrastructure, but for software (up and down the stack) in general. Nobody wants buggier, slower software. And so TigerStyle as a methodology was codified primarily to address this problem: How to write “higher quality software in less time”? [1] Before designing TigerBeetle, I was finding the principles more and more valuable, regardless of whether I was doing frontend or backend work, and so brought them into TigerBeetle. Of course, software higher up is likely to use some dependencies, but there's always a cost, and this principle (“do more with less”), at least in my experience, tends t

Recommends jorangreef · 2025-07 · on “NIH is cheaper than the wrong dependency”

> How does TigerBeetle's existence support the argument that rolling your own dependencies is better than using off-the-shelf tools? At least from my own experience, without TigerStyle [0], there's no way we could have shipped TigerBeetle from 0 to production in 3.5 years, with the same quality, and to the same tolerances: [LINK] Whereas, for example, if we'd used off-the-shelf dependencies such as Raft or RocksDB, it would have been a nightmare, and taken longer, just to fix them up to solve our storage fault model and implement Protocol-Aware Recovery correctly. Even then, we'd have been stuck with a systems language of the last 30 years (C/C++), when we could have invested in a language f

Recommends jorangreef · 2025-10 · on “TigerBeetle and Synadia pledge $512k to the Zig Software Foundation”

You're right! In the past, distributed databases written without Deterministic Simulation Testing (DST) would typically take around ~10 years (~5 years for the consensus protocol and ~5 years for the storage engine). And then not without bugs. However, and we write about this also in the post, but TigerStyle and DST enabled us to ship TigerBeetle to production in 3.5 years, in less time, to a higher standard, and to be the first distributed database with an explicit storage fault model (Kyle Kingsbury added new storage fault injectors to Jepsen) solving Protocol-Aware Recovery. Our Jepsen audit is here (also linked in the post): [LINK] For more on TigerStyle as a methodology, hope you enjoy

Recommends jorangreef · 2025-11 · on “Tigerbeetle Simulator”

Joran from TigerBeetle here! This is a “walking sim” real visualization of our Deterministic Simulation Testing harness, the VOPR. Typically we do DST headless in the terminal but this is a visualization, more or less the same thing but with a gaming engine on top. It’s running real TigerBeetle code, but with simulated network/storage and fault injection, and multiple replicas in a cluster, all compiled to WASM and running in the browser, and you can interact with the simulation to poke it and watch the consensus recover. Here’s the full background context and explanation from our talk, TigerStyle, for which we developed this sim: [this video] See also a shorter explanation: [LINK]