If you have built a module-enabled Go binary yesterday with a specific version of an external dependency, you will get that exact version of the dependency tomorrow when you rebuild (IFF you have version-controlled your go.mod and go.sum, which you should). And if someone tries to be sneaky and move the release tag, the checksum will no longer match, and your build will fail.
If you want to upgrade the version of a dependency, that is doable (with plenty of toll assistance), but it requires a positive action.
Theer is, however, no good solution for the "first use". But, that is pretyt much standard.
That is probably to some extent correct. Although this would bite you on a new build, not for anything that is already running in production. My understanding is that that is/was not necessarily the case for leftpad.
Yeah, the suggestion is that you should run a caching mirror or manually vendor your dependencies.
Other unconventional ideas about go packaging is that new major versions should have a new package name or be available in a subdirectory with the old version existing in perpetuity, and the minimal version selection approach to dependency conflicts.
I'm sure these things work well inside Google, but at least for me the package management situation is a big turn off for the language.
