My Go executable files are still getting larger
This article is full of misinformation. Just a few representative things:<p>- The expansion of pclntab in Go 1.2 dramatically improved startup time and reduced memory footprint, by letting the OS demand-page this critical table that is used any time a stack must be walked (in particular, during garbage collection). See <a href="https:&#x2F;&#x2F;golang.org&#x2F;s&#x2F;go12symtab" rel="nofollow">https:&#x2F;&#x2F;golang.org&#x2F;s&#x2F;go12symtab</a> for details.<p>- We (the Go team) did not “recompress” pclntab in Go 1.15. We did not remove pclntab in Go 1.16. Nor do we have plans to do either. Consequently, we never claimed “pclntab has been reduced to zero”, which is presented in the article as if a direct quote.<p>- If the 73% of the binary diagnosed as “not useful” were really not useful, a reasonable demonstration would be to delete it from the binary and see the binary still run. It clearly would not.<p>- The big table seems to claim that a 40 MB Go 1.8 binary has grown to a 289 MB Go 1.16 binary. That’s certainly not the case. More is changing from line to line in that table than the Go version.<p>Overall, the claim of “dark bytes” or “non-useful bytes” strikes me as similar to the claims of “junk DNA”. They’re not dark or non-useful. It turns out that having the necessary metadata for garbage collection and reflection in a statically-compiled language takes up a significant amount of space, which we’ve worked over time at reducing. But the dynamic possibilities in reflection and interface assertions mean that fewer bytes can be dropped than you’d hope. We track binary size work in <a href="https:&#x2F;&#x2F;golang.org&#x2F;issue&#x2F;6853" rel="nofollow">https:&#x2F;&#x2F;golang.org&#x2F;issue&#x2F;6853</a>.<p>An unfortunate article.