On Windows, the Microsoft compilers and linkers have inserted such toolchain/library version metadata into PE executables for decades now (the "RICH" header — https://bytepointer.com/articles/the_microsoft_rich_header.h...).

At the time that Microsoft started doing it, paranoiacs thought it was some kind of anti-piracy software fingerprinting mechanism, embedding the compiling computer's MAC address or something. But really, it serves exactly the same purpose that Golang's effort does here: to let you map compiled-artifact back to inputs.

There's also ongoing work to build a dependency vulnerability database. This is proposed to be surfaced via a built in `go audit` command.

https://go.googlesource.com/proposal/+/master/design/draft-v...

So if you make a commit to the README.md fixing a typo, now your build of the source code has a different checksum? I wonder why they don't instead hash all the source files and then embed that hash.

> So if you make a commit to the README.md fixing a typo, now your build of the source code has a different checksum?

Yes...? What's the problem?

> why they don't instead hash all the source files and then embed that hash.

This is almost exactly what the git sha is. If you're arguing that README.md files shouldn't be included in the checksum, that's subjective. Many people would argue otherwise. And it doesn't hurt to be more accurate than less.

The git commit hash is less accurate, since it includes extra files like README.md that aren't converted to any part of the executable.

That doesn’t provide a link back to the source, unless you store that hash elsewhere. Giving you the problem of maintaining a database also.

You store the source packages alongside the binary packages, and then index hashes of all the source/binary package contents. Then you know which source files were used from which source/binary packages to produce a particular executable.

My list of languages to practice were Scala and Rust. Maybe I'll do Scala and Go considering this single point.