That's not a stupid question. That's extremely insightful!
That is exactly my model of the world, in fact. When linking incrementally, you don't want a tightly packed object file where the functions are stacked right on top of one another. You want something more akin to a key–value database, where you can swap out key–value pairs without corrupting the entire file. Whether that's an object file that "symlinks" a bunch of other object files, or is one large file with easily swappable blocks (like a SQLite database) probably involves evaluating tradeoffs that I don't have a lot of context on.
(For example, one benefit of keeping it all in one file is that you can send the binary to someone else or move it to another path without corrupting the file.)
We have a lot of container formats. Movie files incorporates video, audio streams, subtitles. MP3 files contains ID3, ID3v2 metadata. JPEG - Exif, PNG - metadata chunks, HTML - <script>, <style>, <meta>. ISO 9660 is a folder. ZIP is a folder with compression. DOCX is ZIP. These can be represented as folders and I would argue some users would like it a lot.
We use modules as files in python and ruby, yet it is a problem and docker solves it.
Zig specific - I do not think you advise to create library file for each function. As such it'd solve nothing - they'd have to patch libraries. And maybe they already have do that.
Is there a point where instead of allowing your single binary to grow indefinitely (to your point about application growth eating up any linker performance benefits), you modularize it into shared libraries that can be independently linked?
I'm with you on the mental model, but from a hardware point of view what you also don't want is hundreds of random disk seeks. I know we're almost in an SSD-only world but HDDs are still a thing and large sequential reads are always important at any level of the memory hierarchy.
Sure, but the buffer cache is also part of the memory hierarchy. At every level, it's always good not to go wild with cache misses. Not that that's what you're proposing of course.
That is exactly my model of the world, in fact. When linking incrementally, you don't want a tightly packed object file where the functions are stacked right on top of one another. You want something more akin to a key–value database, where you can swap out key–value pairs without corrupting the entire file. Whether that's an object file that "symlinks" a bunch of other object files, or is one large file with easily swappable blocks (like a SQLite database) probably involves evaluating tradeoffs that I don't have a lot of context on.
(For example, one benefit of keeping it all in one file is that you can send the binary to someone else or move it to another path without corrupting the file.)