|
The article has been updated to avoid calling the bytes "not useful" and to address the narrow, specific points I raised, but it is still generally suspect. Over on Lobsters, zeebo took the time (thanks!) to build the same version of CockroachDB with various historical Go toolchains, varying only the toolchain, and found that if anything the Go executables are getting smaller over time, in some cases significantly so. v1.0 v20.2.0
1.8 58,099,688 n/a
1.9 57,897,616 314,191,032
1.10 57,722,520 313,669,616
1.11 48,961,712 233,170,304
1.12 52,440,168 236,192,600
1.13 50,844,048 214,373,144
1.14 50,527,320 212,699,656
1.15 47,910,360 201,391,416
https://lobste.rs/s/gvtstv/my_go_executable_files_are_still_...The title of the article ("My Go executable files are still getting larger") appears to be literally untrue, at least read as a critique of Go itself. If they are getting larger, it's because new code is being added, not because the Go runtime or compiler is degrading in some way over time. |
Yes this is a fair assessment, although I find it surprising (and enlightening) that you refer to “a critique of Go”. At no moment was the intent to critique Go specifically; the entire analysis is made of observation of the results of combining Go with specific (and varying) amounts of source code.
In any case, based on this discussion I have decided to amend the title and emphasize in the conclusion that the absolute size of the code+data for a fixed amount of source code has decreased between go 1.15 and 1.16.
edit: This is relevant to this discussion: https://sneak.berlin/20191201/american-communication/