6 ms·

> Go programs with unused imports do not compile. This is a deliberate feature of the language as importing packages slow down the compiler. I'm reading this a

> Go programs with unused imports do not compile. This is a deliberate feature of the language as importing packages slow down the compiler. I'm reading this and I can't shake the feeling that this is really bad compiler and/or language design. Why would the compiler import (that is, parse and compile) a package that's unused in the code? > A better solution is to use goimports tool. Goimports removes unreferenced imports for you. What’s even better it tries to automatically find and add missing ones. Why can't the compiler do that? Why do you need a few dozen separate tools to complement the compiler?

konart 6y ago
>Why would the compiler import (that is, parse and compile) a package that's unused in the code? Parse - yes, compile - no. Compiler still needs to parse your code to determine if your import is used or not. Go team decided that compilation should take as little time as possible, so it is easier to make sure that the compiler does not have to worry about unused imports at all. Not to mention that this keeps your code clean. Dozen separate tools can be used effectively in your workflow (say CI\CD pipeline). Or just executed on every save. (or both) https://golang.org/doc/faq#unused_variables_and_imports https://golang.org/doc/faq#unused_variables_and_imports
- dmitriid 6y ago
  > Compiler still needs to parse your code to determine if your import is used or not. Parsing is easy. And it's fast. On top of that the compiler already knows it's unused: --- start quote --- Go programs with unused imports do not compile. This is a deliberate feature of the language as importing packages slow down the compiler. --- end quote --- So, the compiler has already parsed the file, and determined that the import is unused. And refuses to compile further, because... it needs to import that package anyway? Why? > Dozen separate tools can be used effectively in your workflow Haha, no. If you need a dozen different tools, there's no question about effectiveness at all.
  - deleted 6y ago
    [deleted]
  - knorker 6y ago
    > And refuses to compile further, because... it needs to import that package anyway? Why? Because it may have side-effects, and the compiler doesn't know if it's the programmer's intention to import in order to get those side-effects, or if it's a mistake.
    - dmitriid 6y ago
      https://news.ycombinator.com/item?id=26565422 https://news.ycombinator.com/item?id=26565422
      - knorker 6y ago
        I'm sorry you just don't understand why Go forces you to do the right thing.
        dmitriid 6y ago
        It's post-hoc justification of bad design: https://news.ycombinator.com/edit?id=26573519 https://news.ycombinator.com/edit?id=26573519
drvd 6y ago
Sorry to hurt your feelings, but it is not. The _compiler_ cannot know whether the code in a package might be used (e.g. because the package is just used to register some stuff; a common example being image file formats). Only the _linker_ can strip unused stuff. This has nothing to do with bad language design, most languages work that way.
- dmitriid 6y ago
  > Sorry to hurt your feelings, but it is not. The _compiler_ cannot know whether the code in a package might be used I'm sorry to hurt your feelings, but compiler definitely can know whether some external module is used in the file it's compiling now. See my other comment: https://news.ycombinator.com/item?id=26553401 https://news.ycombinator.com/item?id=26553401
  - knorker 6y ago
    I'm not sure I follow. How can the compiler know that the import is side-effect free, transitively? Without opening more files and parsing them, how does it know that none of the transitive dependency tree has a `func init(){}` ? Go forces you to add an underscore if you mean "I'm importing this for its side-effects, and am not using it directly".
    - kaba0 6y ago
      If it doesn’t know whether it is used or not, how can it fail a compile?
      - knorker 6y ago
        It doesn't know what the author's intention is: "import for the side-effects", or "oops, that was a mistake". It's not that it fails, it's that it rejects.
        kaba0 6y ago
        I’m not familiar with go, but why on Earth can an import have side-effects? That’s ridiculous.. I was never a fan of Go, but this just takes the cake..

konart 6y ago

>Why would the compiler import (that is, parse and compile) a package that's unused in the code? Parse - yes, compile - no. Compiler still needs to parse your code to determine if your import is used or not. Go team decided that compilation should take as little time as possible, so it is easier to make sure that the compiler does not have to worry about unused imports at all. Not to mention that this keeps your code clean. Dozen separate tools can be used effectively in your workflow (say CI\CD pipeline). Or just executed on every save. (or both) https://golang.org/doc/faq#unused_variables_and_imports https://golang.org/doc/faq#unused_variables_and_imports

dmitriid 6y ago
> Compiler still needs to parse your code to determine if your import is used or not. Parsing is easy. And it's fast. On top of that the compiler already knows it's unused: --- start quote --- Go programs with unused imports do not compile. This is a deliberate feature of the language as importing packages slow down the compiler. --- end quote --- So, the compiler has already parsed the file, and determined that the import is unused. And refuses to compile further, because... it needs to import that package anyway? Why? > Dozen separate tools can be used effectively in your workflow Haha, no. If you need a dozen different tools, there's no question about effectiveness at all.
- deleted 6y ago
  [deleted]
- knorker 6y ago
  > And refuses to compile further, because... it needs to import that package anyway? Why? Because it may have side-effects, and the compiler doesn't know if it's the programmer's intention to import in order to get those side-effects, or if it's a mistake.
  - dmitriid 6y ago
    https://news.ycombinator.com/item?id=26565422 https://news.ycombinator.com/item?id=26565422
    - knorker 6y ago
      I'm sorry you just don't understand why Go forces you to do the right thing.
      - dmitriid 6y ago
        It's post-hoc justification of bad design: https://news.ycombinator.com/edit?id=26573519 https://news.ycombinator.com/edit?id=26573519

drvd 6y ago

Sorry to hurt your feelings, but it is not. The _compiler_ cannot know whether the code in a package might be used (e.g. because the package is just used to register some stuff; a common example being image file formats). Only the _linker_ can strip unused stuff. This has nothing to do with bad language design, most languages work that way.

dmitriid 6y ago
> Sorry to hurt your feelings, but it is not. The _compiler_ cannot know whether the code in a package might be used I'm sorry to hurt your feelings, but compiler definitely can know whether some external module is used in the file it's compiling now. See my other comment: https://news.ycombinator.com/item?id=26553401 https://news.ycombinator.com/item?id=26553401
- knorker 6y ago
  I'm not sure I follow. How can the compiler know that the import is side-effect free, transitively? Without opening more files and parsing them, how does it know that none of the transitive dependency tree has a `func init(){}` ? Go forces you to add an underscore if you mean "I'm importing this for its side-effects, and am not using it directly".
  - kaba0 6y ago
    If it doesn’t know whether it is used or not, how can it fail a compile?
    - knorker 6y ago
      It doesn't know what the author's intention is: "import for the side-effects", or "oops, that was a mistake". It's not that it fails, it's that it rejects.
      - kaba0 6y ago
        I’m not familiar with go, but why on Earth can an import have side-effects? That’s ridiculous.. I was never a fan of Go, but this just takes the cake..