I have come up against something a bit strange and interesting that I didn't really expect from the Go compiler.
I have a main which uses a structure created in a package, which contains a whole load of references to other packages.
What I discovered is that even though only one of these included packages is used, the whole set still gets included in the binary.
Am I right in saying that packages create a linker object file, as a whole, and every package imported is also linked?
In the case of my application it means I now have to manually break up a whole load of nice pretty neat declarations into pieces that return generator functions, and each part has to come from a different package, meaning a folder and one tiny little source file.
I couldn't find any reasonable terms that explained Go's linking mechanisms but it dawned on me as I thought about how each folder in the tree creates a binary object that is stitched together in the final binary, that there's really no way around this, and I suppose it makes nice neat little bite sized source files but for my case it was a surprise I hadn't expected.
After building a giant conglomeration I realised for some cases (namely, a backend for a mobile app) that one has to design the folder tree to split the parts. It's something to keep in mind for multi-function binaries if you want to also offer single function binaries for specific parts that are only needed alone.
I am probably, as usual, doing something unconventional and running up against things that nobody else ever thought of and discover something about a system that isn't obvious until you think about it, when one intends to do some particular thing.
In terms of memory utilisation, there is really not a great deal of difference in terms of performance, I presume, except providing the ability to cut up the whole thing into small pieces, a tiny amount extra on disk but I presume the final memory use, since all is a monolithic (more or less) static binary, that once it unwraps all the entry points and relative references that there isn't (much) extra in memory. I suppose also if one is targeting a constrained environment, it would make sense to use -s -w to strip out the debug symbols.