Hacker News Reader

(I work on TigerBeetle)

+100, context is the key thing, both TigerBeetle and rust-analyzer have strong culture of how the things are done, but the _specific_ culture is quite different, because they solve very different problems.

That being said, I _think_ you might be pattern-matching a bit against the usual dependencies good/dependencies bad argument, and the TFA is on a different level. Note the examples of dependencies used: POSIX, ECMA-48, the web platform. These are not libraries, these are systems interfaces!

Dependency on a library is not a big deal --- if it starts to bite, you can just rewrite the code! But dependency on that underlying thing that the library does is usually something that can't be changed, or extremely costly to change. Answering "No" to "is doing X in scope for my software?" is powerful

To refer to the sibling comment, if there's a team whose core business is writing matrix multiplication code, they _can_ use random library #24 for something else, but often, if you apply some software design, you might realize that the product surrounding matrix multiplication _shouldn't_ handle concern #24. It doesn't mean that concern #24 isn't handled by anything at all, rather that we try to find _better_ factoring of the overall system to compartmentalize essential dependencies.

The problem I have with this line of thinking is that it only works when you're talking about bottom of the barrel developers.

The tech world has this tendency to dumb down every advice so it caters to the lowest common denominator, but I honestly have never worked in such an environment where developers couldn't learn to duplicate the functionality of shitty dependencies while at the same time fixing the problem.

And as much as people love to mock CRUD, bad abstractions can be a horrible drain on teams doing CRUD work. And even the popular stuff can often suck and be a timesink unless you're doing absolutely basic stuff that's just repeating the tutorial.

Most professionals are average, by definition, because skill follows a Gauss curve.

HN is a bubble, the world runs on "meh".

Average doesn't mean rock bottom.

I've seen "Meh" do the things HN claims nobody can. Plenty of times.

> but I honestly have never worked in such an environment where developers couldn't learn to duplicate the functionality of shitty dependencies while at the same time fixing the problem.

I have absolutely seen this. It’s not a matter of them being bad developers, but no one is an expert in all things and gaining expertise takes time which costs money. All dependencies have a lot of trade-offs baked in that must be re-evaluated if you decide to go the NIH route, and that’s usually where expertise is needed. If you lack the expertise you will still be making trade-offs, but you will lack the knowledge to foresee the long term consequences of these decisions.

In my own opinion core business differentiators are where engineering resources should be used. That’s not to say a dependency that is more generic than the problem your business is trying to solve should never be pulled in house, but the decision to do that shouldn’t be taken lightly as it will increase the burden of learning, maintaining, documenting, testing, etc for a team that is being judged on the success of business objectives. To put it another way, the business will be hesitant to give you time to work on something that is only tangentially related to their objectives and quality can and usually will suffer which will put you in a worse position.

I think software development has some unique characteristics that makes NIH a problem. If you’re an electrical engineer you will never be given the resources to make a custom microcontroller or a new way of manufacturing a PCB unless that is what your company is selling; the upfront costs would be staggering and that would not be allowed. The limitations of the technology available is simply that, a constraint on what the business can do given current tech. Perhaps there is an opportunity for something better, but that would be best served as a new company focused on providing that solution if it can be done in an economically viable way. Software doesn’t have these massive upfront manufacturing costs that are obvious like the example above, but they still exist.

AI may change this calculus.

I am not saying it doesn’t exist, just that I have been around the block for quite a while but even then didn’t personally work in a place like this.

Places with average developers are more than equipped to do tasks that HN claims to be impossible to anyone but Carmack or Torvalds.

And average doesn’t mean rock bottom!

I don’t understand why those conversations only focus on the extremes. We should stop being so prescriptive of other people’s work.

I've seen a few people from the bottom of the barrel outside on the real world...

The funny thing is that no advice is dumbed-down enough for them. They will take anything you can say and implement wrongly.

That idea that if you dumb-down everything, it will be helpful is just plain bullshit. People that can't duplicate a dependency just can't choose the right dependency either, and if you force them to use some good one, they will use it wrong.

Yeah, that's a great argument.

Not only it's harming people of average capability, it's also not even benefiting the people on the bottom.

The Overton-window of supply-chain has shifted so much to one side that it no longer benefit anyone but supply-chain providers.

It doesn't even have to be related to quality of developers. Whatever tool chain or product you use, you're using someone else's dependencies. In some places more than others, but most people aren't implementing their own matrix multiplication code, and the ones that are, aren't implementing random library #24 which isn't in their core business. So this whole discussion happens on black and white terms when in fact people only care if they have regulatory obligations, or they have a particular personal interest in implementing something, or they got attached to that idea for a specific library. But nobody is applying this fully or they'd still be at the beach collecting sand.

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] https://tigerbeetle.com/blog/2025-02-27-why-we-designed-tige...

[2] https://www.youtube.com/watch?v=w3WYdYyjek4

Where's your custom matrix multiplication implemented in your stack?

Vasco! In a past life I've implemented (and tuned) things like Cauchy by hand, but we don't use any of that in TigerBeetle. Nevertheless, the experiences and learnings around that were valuable for me personally, and I don't think I'd have been able to do TigerBeetle without putting in those hours. Wish you all the best, man!

> But nobody is applying this fully or they'd still be at the beach collecting sand.

To this point I posit almost all of the "this good, that bad" type of posts are just "at my point on the abstraction continuum, this thing is better than that thing" without taking into account any context.

For most assembly is too low level for their context/use case, but for some, the C programming language is too HIGH level, as it was originally designed to be (but not for me).

> But the average developer, writing most line-of-business CRUD systems, well, quite honestly they're not that strong to begin with.

This is a wild take. Developers don't usually get to pick the system they work on, resource constraints exist during development time. We make tradeoff decisions every day and pulling in a "cheap" dependency will often make the difference between a shipped, working piece of software and plain "nothing". You seem to be fairly little involved in actual software development, considering how generic and wrong this take is.

When looking at CVs and interviewing actively, it's honestly very easy to believe the quoted claim. Of course I work with some very skilled folks on line-of-business CRUD too so who knows.

Isn't the industry still growing pretty quickly? If five years is enough to count as "senior", most won't be that good just because they haven't had time to get good yet. And any segment that's big enough or low enough margin won't be able to escape that average.

The problem, IMO, is that the trade-offs seem to always land on the side of “what ships faster.” That may well be the fault of PMs rather than SWEs, but either way, it doesn’t usually make for a sustainable product.

I also don't quite like TigerBeetle as an example, because it is very new startup. They are pre-1.0 and just a bit more than a year since production release. It's way too early to tell whether their approach actually paid off.

Joran from TigerBeetle here!

While the company is 3 years old, TigerBeetle as an open source DBMS project actually started in 2020.

What we mean by "production" is also typically a bit different to what is typically meant.

For example, TigerBeetle is one of the first DBMS's to withstand an explicit storage fault model (i.e. disk corruption across all replicas). So the tolerances are a bit tighter for TigerBeetle, also with things like static memory allocation (cf. NASA's Power of Ten Rules for Safety-Critical Code).

Beyond this, when TigerBeetle was designed, it was (along with FoundationDB) one of few DBMS's to invest in a Deterministic Simulator in-house. Most DBMS's before 2020 were typically not designed from the ground up for Deterministic Simulation Testing (DST) and so now can only use Antithesis if they want to get into DST.

However, TB invests heavily in both, not only an external DST audit function, but more importantly, also our own internal DST audit function, which we designed and built entirely inhouse, and which can do considerably more damage to TigerBeetle because it's protocol-aware and understands how to push TB's consensus and storage to the breaking limit. In other words, not one DST simulator, but two, with “the VOPR” (the name for TB's own simulator) tailored to our fault models, and able to reach into any part of the code, across any machine in the simulation, and verify expectations. For example, do things like verify cache coherency between user space page cache and simulated storage engine.

Finally, if you're interested in the results of whether this rigid TigerStyle approach pays off, Kyle Kingsbury's Jepsen audit of TigerBeetle was one of the longest Jepsen engagements to date, and these were the findings: https://jepsen.io/analyses/tigerbeetle-0.16.11

I work at a medium company that is in a comparable sector implementing comparatively performant and externally constrained things pretty much wholly in C and pretty much wholly with our own dependencies with external dependencies being mostly located in ops, testing/qa and other stuff not in the critical path of what the people who pay us want the products to do. For us it's not about "built here" it's about control and uniformity. The company is a decade old and very profitable for its headcount though not subject to wild delusions about future hockey sticks because of what we build and for who.

So the approach clearly can work. It won't kill you. But it's also unclear the degree to which this approach contributed to vs detracted from our success since it's not like there's a control company that did it the other way you can compare to. It takes constant effort to do things this way, but so does managing dependencies. While unilateral control, and the responsibility for that, that comes with writing your own dependencies is a key aspect of how we do what we do with the headcount we do it's not like it's part of our marketing. It's just a decision that was made that we're sticking to because it seems to work for us. It's not some silver bullet, it takes effort to do well, like anything else done well.

I have worked at huge companies where they were biased toward using existing stuff where it existed and tweaking it just the bare minimum needed and that worked very well for them too and definitely had its pros too.

Author here!

I pointed to tigerbeetle because they're one of the few companies I know of who 1) have a philosophy about dependencies and 2) talk about it openly in an easy to quote document.

I'm not sure if I succeeded, but I wanted to get across that I mean "dependency" in a very broad sense. Not just libraries, or services you interact with, but also what you need to build and deploy.

It wasn't a call to just not use dependencies. It was a call to think about them and be clear what you're depending on. Tigerbeetle have done that and given reasoning.

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: https://www.youtube.com/watch?v=w3WYdYyjek4