I was already using go-plus, but I think the addition of goimports is something recent — it wasn't there when I last looked. Thanks for the pointer.
I know that "go vet" can warn about this, my point was that it's amazing that Go refuses unused imports but allows shadowing. It reveals a very skewed idea of what is important when compiling.
iirc, the decision to disallow unused imports was largely motivated by improving build times. And not just for your package either. If each package in the tree can accidentally have an extra import or two it could end up ballooning to crazy proportions where everything and their third cousin is imported with only some of them being used.
But that concern is about releasing, which is completely orthogonal to building.
Go conflating the two is, I think, its biggest design mistake on the build system side. In Go, dependencies are inferred from imports, which, since it can't express versioning information, leads precisely to this sort of problem.
It makes sense only if you're putting all of your dependencies in a single versioned work tree, but almost no developers work like that outside of Google. And it's not a good pattern for most devs/companies. Yet Go is completely infected by it.
Other languages typically use a dependency manifest, which IMHO is the only sane, logic approach.
The funny thing, a dependency manifest is a superset of Go's current import behavior. But they chose implicit over explicit, which in CS is a mistake 9 times out of 10.
What are you talking about? How is unused imports related to library versioning? And how is focusing on improving build times orthogonal to "building"? The concern with build times is to make building while developing faster [0], how is that related to "releasing"?
Your points are tangential at best, and nonsensical otherwise.
First, Go doesn't have any concept of "releasing". "go get" just (1) just grabs the latest HEAD from whatever repo you're using, and (2) follows import paths. It doesn't even use release tags.
So the "build times are affected by unused imports in dependencies" problem only exists as a hypothetical issue because "go get" implicitly trusts dependencies' import statements.
Other package systems don't do this. They (RubyGems and NPM are good examples) require that you build a release that you then publish. Included in such a release is a dependency manifest (Gemfile.lock, npm-shrinkwrap.json) that the package manager can read.
The more natural solution is to generate a dependency manifest at release time that only includes valid imports, and refuse to release something that contains unused imports.
The build time issue only exists locally if you run a monorepo like Google's, and in that case it's my opinion that, just like code linting, this is your own concern, not something to pollute an entire developer ecosystem with.
I know that "go vet" can warn about this, my point was that it's amazing that Go refuses unused imports but allows shadowing. It reveals a very skewed idea of what is important when compiling.