3 ms·

People are ok with compilers telling them what is wrong, they complain that Go wants to control when you fix the problem: "fix that import NOW, bad developer" i

• dmoy 10y ago
  By differing use cases: 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.
  • junke 10y ago
    My reaction to "differing use cases lend to different tools" was that tools and especially languages often accommodate multiple, sometimes contradictory use cases. 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?
• AnimalMuppet 10y ago
  > > Differing use cases lend cause to different tooling. > 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.
  • junke 10y ago
    What about different needs among the users of a same language?
    • AnimalMuppet 10y ago
      Any language satisfies some needs well (hopefully), and some needs less well, and some other needs badly. Different languages have different sets of needs that they satisfy well. 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.