> Differing use cases lend cause to different tooling.
What?
If you're messing around with your own test code, it's fine if your compiles get slower, etc. On the other hand, if you're writing code that thousands of other engineers are immediately going to depend on, it's better if you're not allowed at all to make things slower via unused imports. True, if you could globally mandate the use of a lint/presubmit rule disallowing unused imports, that would also work. But, that's a harder swing.
I am not writing code that thousands of other engineers are going to depend on. A company that requires this can enforce methodological rules. Go is supposed to be used in different contexts, not just Google, right?
> What?
Different needs, different languages.
I write 100-line scripts in Perl that rip apart text files and extract the bits I want. I don't write 100,000 line embedded systems in Perl.
So, if you're complaining that a language doesn't satisfy a need well, then go find one that satisfies it better. Use that instead.
In that world, this sort of thing enforced strongly makes me much happier.
For random one-off hacking, yea, it'd be a pain.
Differing use cases lend cause to different tooling.