>Instructive here is Tigerbeetle, a financial database written entirely with Vanilla Zig:
How does TigerBeetle's existence support the argument that rolling your own dependencies is better than using off-the-shelf tools?
TigerBeetle has existed as a company for less than three years, they haven't reached a 1.0 release, and they have a single-digit number of engineers. As far as I can tell, they haven't even reached the point of self-sufficiency, as they raised another round of VC funding a year ago.
The pain of rolling your own tools happens as you grow and your needs change. Rolling your own static site generator[0] is fine when you only have a handful of engineers, but I suspect over time, they'll burn more time on their homegrown HTML templating solution[1] than if they had just used a battle-tested, off-the-shelf solution like Hugo.
The only dependency TigerBeetle accepted is Zig, which also hasn't reached a stable 1.0 release and frequently forces developers to rewrite their code to deal with breaking changes, including a major one coming in Zig 0.15.0.[2]
I like TigerBeetle, but they're not proof of anything yet. For every TigerBeetle, there are a hundred profitable companies whose entire business depends on WordPress with 50 plugins they picked at random.
Aside from TigerBeetle, I find most of the arguments in this article weak. They sound like rationalization for a developer who enjoys rolling their own tools and seem not to consider actual business value.
The article also leaves out what I think is the most important consideration in evaluating dependencies: lock-in. How difficult is it to swap out this dependency later? Because if the answer is, "very easy" most of the other considerations don't matter.
There's no use doing an exhaustive survey of image processing libraries when you can swap out your choice with a few hours of dev work. But choosing something like a storage backend is very difficult to change later, so you want to put more thought into it.
> 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: https://jepsen.io/analyses/tigerbeetle-0.16.11
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.
How does TigerBeetle's existence support the argument that rolling your own dependencies is better than using off-the-shelf tools?
TigerBeetle has existed as a company for less than three years, they haven't reached a 1.0 release, and they have a single-digit number of engineers. As far as I can tell, they haven't even reached the point of self-sufficiency, as they raised another round of VC funding a year ago.
The pain of rolling your own tools happens as you grow and your needs change. Rolling your own static site generator[0] is fine when you only have a handful of engineers, but I suspect over time, they'll burn more time on their homegrown HTML templating solution[1] than if they had just used a battle-tested, off-the-shelf solution like Hugo.
The only dependency TigerBeetle accepted is Zig, which also hasn't reached a stable 1.0 release and frequently forces developers to rewrite their code to deal with breaking changes, including a major one coming in Zig 0.15.0.[2]
I like TigerBeetle, but they're not proof of anything yet. For every TigerBeetle, there are a hundred profitable companies whose entire business depends on WordPress with 50 plugins they picked at random.
Aside from TigerBeetle, I find most of the arguments in this article weak. They sound like rationalization for a developer who enjoys rolling their own tools and seem not to consider actual business value.
The article also leaves out what I think is the most important consideration in evaluating dependencies: lock-in. How difficult is it to swap out this dependency later? Because if the answer is, "very easy" most of the other considerations don't matter.
There's no use doing an exhaustive survey of image processing libraries when you can swap out your choice with a few hours of dev work. But choosing something like a storage backend is very difficult to change later, so you want to put more thought into it.
[0] https://tigerbeetle.com/blog/2025-02-27-why-we-designed-tige...
[1] https://github.com/tigerbeetle/tigerbeetle/blob/86b85ab60395...
[2] https://github.com/ziglang/zig/pull/24329