> I’ve cut over 11,000 lines of completely dead code from Bun. I can’t think of another project whose codebase was so neglected as to reach 11K lines of dead code. I’ve also rewritten and modernized parts of the codebase, trying to rely more on Zig’s stdlib. In the process, countless bugs have also been fixed.

This is astonishing. Is anyone else surprised at this dead code figure? Is it a feature of large projects I've just never noticed?

▲

christophilus a minute ago | parent | next [-]

It's less than I'd expect, given how Bun was developed. I'm sure there's plenty more of that to be had in that codebase.

▲

singron 3 hours ago | parent | prev | next [-]

TFA says the whole codebase is 600k, so that would be 1.8% dead code. IME dead code is much more common in larger codebases as figuring out that code is dead becomes more non-local and changes over time create dead code at a distance. I'm also not sure if the 11k was trivially dead (`if (false) { dead_code(); }`) or if it was more subtle (e.g. dynamically-dispatchable code that can't logically be called).

The 1.8% feels high if it's trivially dead. When I've run simple static analysis on decent codebases before, it's been much lower. For non-trivial dead code, it might be low. E.g. a lot of projects have piles of "dead" code behind ancient feature flags that would never be switched.

A small amount of dead code is fine. E.g. it might not be worth deleting utility methods that you happen to remove the last use of if they are simple and you might re-add a use later. Generated code is often dead since it's not worth specifying to the generator exactly what will be used. Other times, deleting dead code can lead to a valuable cascade of other deletions and simplifications.

	▲	jasonjmcghee 2 hours ago \| parent [-]
		LLMs from 1+ years ago approached solving every problem by adding additional code and not cleaning up or adding strange unnecessary backwards compatibility (and often still do this kind of thing - "all tests green")

▲

hansvm 3 hours ago | parent | prev | next [-]

At my last company I cut 8k lines from a 10k component and fixed every major bug in the process. It wasn't "dead" per se, but if you start by cleaning up one little bad abstraction then that opens opportunities for the next one and the one after that till eventually all you're left with is software which actually does what it's supposed to.

That hasn't been a unique experience either -- quite the opposite. Codebases bloat over time. The only thing astonishing to me is that in something as large as Bun they only found 11k lines.

▲

asibahi 4 hours ago | parent | prev | next [-]

The Zig compiler compiles lazily and does not detect dead code. (Read: functions that are not called from any compiled functions)

▲

robertlagrant 3 hours ago | parent [-]

That makes total sense (though it would be nice if it could do that detected, I suppose), but what makes less sense to me is the accumulation of unnecessary code (and presumably unit tests for that code) that isn't removed as soon as it's no longer needed.

▲

dnautics 3 hours ago | parent [-]

hard to detect. what if a whole code branch is used by macos and you're on x86?

▲

robertlagrant 3 hours ago | parent [-]

I don't understand - wouldn't this be observable by the person making the change? They used to call this function / use this class and now they don't any more? Even if it's inside a conditional compilation block.

	▲	zdragnar 2 hours ago \| parent \| next [-]
		That requires a person to be making that change. If the change is vibe coded and the person is only checking that the tests pass, it's not hard for cruft to accumulate.
	▲	dnautics an hour ago \| parent \| prev \| next [-]
		i did not say "Impossible to detect"! in practice the exponential explosion of options may become intractable. lets say you have 10 compilation flags with 10 options each. not syre you want the compiler scanning through all that on each pass
	▲	wmedrano 2 hours ago \| parent \| prev [-]
		The hard to detect is the compilers technical reason for not doing the analysis. Maybe it will one day. In practice, it's annoying to track if those small util functions become dead code.

▲

ryan_lane 3 hours ago | parent | prev [-]

I'm astonished that anyone is astonished by this amount of dead code in any large code-base. That's like 10 somewhat normal sized PRs worth of code.

	▲	hombre_fatal 2 hours ago \| parent [-]
		Same reaction here. 11,000 lines is nothing for a project this large. It's bog standard, very mild technical debt.