Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
TinyGo
Go compiler for small places. Microcontrollers, WebAssembly (WASM/WASI), and command-line tools. Based on LLVM.
To promote my own tool, https://github.com/bradfitz/shotizam lets you drill down into why Go binaries are large without having to make up terms like "dark bytes".
one mentioning their findings, but don't quote me on that.
[1]: https://github.com/golang/go/issues/6853
> The sum of the sizes reported by go tool nm does not add up to the final size of the Go executable.
> At this time, I do not have a satisfying explanation for this “dark” file usage.
The author's journey of starting with "nm --size", discovering "dark" bytes, and wanting to attribute them properly, is exactly what led me to create and invest so much effort into Bloaty McBloatface: https://github.com/google/bloaty
Bloaty's core principle is that every byte of the file should be attributed to something, so that the sum of the parts always adds up to the total file size. If we can't get detailed symbol, etc. information for a given region of the file, we can at least fall back to describing what section the bytes were in.
Attributing all of the bytes requires parsing much more than just the symbol table. Bloaty parses many different sections of the binary, including unwind information, relocation information, debug info, and the data section itself in an attempt to attribute every part of the binary to the function/data that emitted it. It will even disassemble the binary looking for references to anonymous data (some data won't make it into the symbol table, especially things like string literals).
I wrote up some details of how Bloaty works here: https://github.com/google/bloaty/blob/master/doc/how-bloaty-...
The author's contention that these "dark" bytes are "non-useful" is not quite fair. There are plenty of things a binary contains that are useful even though they are not literally executable code. For example, making a binary position-independent requires emitting relocations into the binary so that globals with pointer values can be relocated at program load time, once the base address of the binary is chosen.
On the other hand, I do agree that the ability to produce slim binaries is an important and often undervalued property of modern compiler toolchains. All else being equal, I much prefer a toolchain that can make the smallest binaries.
There are go variants for this. See tinygo [1], which targeted embedded originally (iirc) but now also targets wasm.
So you’re definitely correct that core Go is not an option, but options exist within the “greater metropolitan area” that’s built up around downtown.
These are among the benefits of having a relatively simple language and a 1.0 compatibility commitment, I think.
[1]: https://tinygo.org/ their FAQ is quite good.