There are unused imports, solved easily with goimports, and then there are unused variables, which AFAIK are not solved by any tool. I dig what the author says regarding "explorability" hindered by all those errors popping up.

It's also funny to see errors solved automagically by tools instead of manually by the developer; there used to be a time where IDEs where voluntarily avoided because they did too many magic things to your code and to your project, and true hackers should be able to work with only a text editor and the compiler. I fear go may be headed back to IDE-land if it starts relying too much on tools (we have goimports today, the go generate command is to be used for code mangling before compiling ...)

> I fear go may be headed back to IDE-land if it starts relying too much on tools (we have goimports today, the go generate command is to be used for code mangling before compiling ...)

I think that it's kinda the opposite: rather than one monolithic IDE, it's lots of little pieces working together. Pretty much what one would expect from the guys who brought us Plan 9 and Go…