3 ms·
Hmm... so many questions 1. Go binaries are bloated already. Do they plan to compress this (and other textual info, like full type names) in the binary? 2
by tandr 5y ago
Hmm... so many questions
1. Go binaries are bloated already. Do they plan to compress this (and other textual info, like full type names) in the binary?
2. I saw enough of build pipelines that do not clone repositories, but do a shallow copy for a tag, and have no .git folder. How much info will be added in this case?
3. Moreover, pretty much every serious build has source generation steps (protobuf, jooq, etc - you name it). If resulting executable will have a very particular info about these, the sheer amount of information added will probably make executables considerable larger.
- capableweb 5y ago1. It seems to be very small amount of information, if you compare to what already being included in a typical Golang binary. What's 1kb (or even 10kb) when your binary size is already huge thanks to Golang? If binary size is very important for you, then you would surely use something else than Golang in the first place.
- pqb 5y ago1) A lot of CI pipelines already do it by utilizing ldflags in go-build command. I don't think if few kilobytes more will matter much. 2): It will not be added (based on information provided in the article [0]). 3): Is it valid question? By my basic understanding of article the case of adding more bytes to binary will require having the main package [0]. Also, generation (e.g. gogo-proto, go:generate) will create only business logic code in new package, no additional metadata will be added. [0] Quote from article: > Version control information is embedded if the go command is invoked in a directory within a Git or Mercurial repository, and the main package and its containing main module are in the same repository.