5 ms·

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 reg

by 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..
        knorker 6y ago
        Many languages do. A Python import will execute anything it imports (most of what's "executed" is "def" and "class"), but if there's code at the top level, it'll run. C++ will run constructors for global variables before main(). Even C has side-effects from linking in! void __attribute__ ((constructor)) init() {} So I don't mean side-effects at compile time (e.g. it's not like C macros), but importing / linking something even if you don't use it is very common that it has side effects. Why would you do this? Commonly to "register a handler", to not have to both "import foo" and call "foo.init()"
        kaba0 6y ago
        To be honest, I think of header files really lowly. I do see now why would one use that, thank you! Though I still think that adding an explicit keyword to run init functions would be preferable, like `import init package`.
        knorker 6y ago
        That's what the underscore is. :-) Other init code is stuff like "var foo = regexp.MustCompile(...)". Then there may be transitive imports that do C code, and it really needs to run its init code.
      - deleted 6y ago
        [deleted]
      - dmitriid 6y ago
        This just adds to my impression that Go is a very poorly designed language. So. The compiler knows that the package is not used. How can you tell the compiler that the package is imported for side-effects? Oh, you have to explicitly tell it to the compiler by, you know, actually using the import, right. By doing something stupid like import ( _ "github.com/lib/pq" _ "image/png" ... ) Oh. Look. Problem solved. You mark a package as "I imported this specifically for its side effects". So the compiler can go ahead and include it. Why does it need to include any other unused module?

by drvd 6y ago

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..
      - knorker 6y ago
        Many languages do. A Python import will execute anything it imports (most of what's "executed" is "def" and "class"), but if there's code at the top level, it'll run. C++ will run constructors for global variables before main(). Even C has side-effects from linking in! void __attribute__ ((constructor)) init() {} So I don't mean side-effects at compile time (e.g. it's not like C macros), but importing / linking something even if you don't use it is very common that it has side effects. Why would you do this? Commonly to "register a handler", to not have to both "import foo" and call "foo.init()"
        kaba0 6y ago
        To be honest, I think of header files really lowly. I do see now why would one use that, thank you! Though I still think that adding an explicit keyword to run init functions would be preferable, like `import init package`.
        knorker 6y ago
        That's what the underscore is. :-) Other init code is stuff like "var foo = regexp.MustCompile(...)". Then there may be transitive imports that do C code, and it really needs to run its init code.
    - deleted 6y ago
      [deleted]
    - dmitriid 6y ago
      This just adds to my impression that Go is a very poorly designed language. So. The compiler knows that the package is not used. How can you tell the compiler that the package is imported for side-effects? Oh, you have to explicitly tell it to the compiler by, you know, actually using the import, right. By doing something stupid like import ( _ "github.com/lib/pq" _ "image/png" ... ) Oh. Look. Problem solved. You mark a package as "I imported this specifically for its side effects". So the compiler can go ahead and include it. Why does it need to include any other unused module?