Post #4039768

2026-07-23 11:59 UTC

My system-oriented code thread yesterday is a good example of the gap between looking eloquent to other people vs feeling like I'm rigorously expressing and exploring ideas. Honestly, good post in its own right. But there's a subsequent idea I wanted to build on top of it, and then literally could not remember what it was after getting the initial post done. https://raphus.social/@MaddieM4/116965519725934081 Now I finally remember, but the idea is something I haven't explored enough yet to post authoritatively! It's about nesting. Yes, data composes into data and execution composes into execution. But these system utilities are often able to be as pristine and well-crafted as they are because they aren't depending on a lot of libraries. Specificity is what enables simplicity. But in an application, where most of the logic is libraries built on libraries, most of that code has to be written with a kind of generic/agnostic blindness that increases total systemic complexity.

Replies (1)

@MaddieM4@raphus.social 2026-07-23 12:05

The simplest version of this problem is the kind you can solve with tree shaking. If a library has a bunch of functionality that you don't use (because another library consumer *does* or *might* use it), the final build may be able to omit a lot of that code, by a mechanism that isn't too far off from a mark-n-sweep garbage collector, treating your application's main function as the GC root. Some amount of this low-hanging fruit usually exists, but not necessarily enough to fill your stomach with a free lunch. Are you actually writing a library that depends on a library? Now you have multiple entrypoints (public functions) that someone might use, which means more GC roots of things someone *might*, use pinning dependency content in place. You also usually end up needing to track more state that someone might use. Okay, now all your structs take longer to malloc and copy and you need to gather more information to populate them, etc. Because "might" and "maybe" are expansive words in a cautious context.

Open ##4039767