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

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. [VIDEO]

> 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: [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", but perhaps you meant something different by that term.

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-depth. We have plans for how our docs will be used in future, that you may not be aware of, and security is important.) Finally, we're happy with the result, the project was small and didn't take long. We're used to "painting" things like this fairly quickly. It's just easier for us than trying to "sculpt" off the shelf dependencies. That's not to suggest that everyone needs to paint like we do at TigerBeetle, but it's equally true that not everyone needs to sculpt either. [1] [1] To understand our engineering methodology, and why we prefer to paint than sculpt, see TigerStyle: [VIDEO]

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] [VIDEO]

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 to prove valuable when applied. [1] Some of the background motivation behind TigerStyle: [VIDEO]

> 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 for the next 30 and with a more powerful toolchain. Of course, we'd also have been without Deterministic Simulation Testing, because most software dependencies are typically not designed for DST. But finally (and to your point about sustainability), without TigerStyle, we wouldn't have had the company, or the investment, team, and customers we have today, or be as far along financially. Not saying that you need to share our engineering philosophy. But it works for us. [0] [VIDEO]

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 this talk: [VIDEO]

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: [VIDEO] See also a shorter explanation: [LINK]