Someone on the thread in HN pointed out https://github.com/bradfitz/goimports that solves the unused import issue. I’ll definitely be making use of it.
There’s that tired and insensitive autism analogy again.
In other words, Go represents a kind of Machiavellian power play, orchestrated by slow-and-careful programmers who are tired of suffering for the sins of fast-and-loose programmers. The Go documentation refers quite often to intolerable 45-minute build times suffered by the original designers, and I can’t help but imagine them sitting around and seething about all those unused imports from those “other” programmers, that is, the “bad” programmers. Their solution was not to engage and educate those programmers to change their habits, but rather design a new language that the bad programmers would be compelled to use — and tie down the language sufficiently so that “bad” practices, such as a program containing unused variables, were impossible.
I don’t think there’s anything Machiavellian about designing your tools to fit your notions about correctness. It happens that Go has a lot of traction because it’s from Google, but it wears the history and prejudices of its creators happily on its sleeve. It happens that I think Pike et al are wrong about a lot of things, but it’s an honest wrongness.
Fortunately you don’t have to agree on everything while still being able to use a language someone built.
Just agree to disagree, move along people, keep calm and build awesome stuff.
Well, sure. But technologies have their creators' ideas baked into them, and to use them to their fullest you can’t be fighting all the time. If your view of the world agrees with that of Pike or Odersky or Wall, then you are off to the races and good on you; but if you want something different, or disagree with the ideology of a tool, then it’s useless to fight; switch.