6 ms·

My main wish: Please don't refuse to compile just because there are unused imports. Please do warn, and loudly say it's NON-CONFORMANT or whatever will embara

My main wish: Please don't refuse to compile just because there are unused imports. Please do warn, and loudly say it's NON-CONFORMANT or whatever will embarass me enough from sharing my piece of Go code with someone else.. but.. can I please just run my code, in private, when experimenting?

fixermark 9y ago
I'd be even more excited if the compiler were willing to execute complete heresy on my behalf and (with user consent) edit my source code automatically to remove unused imports. ;)
- johansch 9y ago
  You mean have the compiler modify the source code files destructively? Then I'll have to disagree, that just doesn't make sense.
  - dmit 9y ago
    There was a precedent in Haskell land: https://twitter.com/bos31337/status/116372971509121025 https://twitter.com/bos31337/status/116372971509121025 A more modern implementation: https://github.com/munificent/vigil https://github.com/munificent/vigil
    - fixermark 9y ago
      `gofmt -w` also already exists, it just (a) has to be run as a separate step and (b) doesn't have full cross-file understanding of the program. Since we have version control now, I don't see any threat from an optional capacity for the compiler to destructively mutate the source as an optional feature. Let the same toolchain that converts input to output suggest improvements to the input.
ahacker15 9y ago
I like that Go don't allows unused import and variables. If you're working with inexperienced programmers (and some experienced but bad programmers), you should be certain that they WILL let that code garbage there if the compiler allow it.
- johansch 9y ago
  Funnily enough: I've never found that to be a big problem with other languages in practice. Actually, on a scale of problems in other people's code I'd probably put this very far down the list.
  - nuggien 9y ago
    Have you worked with code where unused variables actually have a side effect?
- Orangeair 9y ago
  That's the kind of thing that should be detected by a linter and stop code submission though, not necessarily stop it from even compiling. What if you just want to comment something out quickly? I don't program in Go, but it seems like it would be annoying to have to repeatedly add and remove the main dependencies while I was iterating on something.
  - johansch 9y ago
    It is absurdly annoying. It's the one thing that put me off golang development, despite all of its nice aspects relating to concurrency. Having custom functionality in editors to work around this apparently dogmatic design decision in the core language.. is also just absurd.
  - infogulch 9y ago
    This problem is fixed by using the "goimports" tool that will automatically add and remove imports as they're used on save. Pretty much every editor supports it. With goimports and gofmt that formats code, I no longer have to think about formatting and imports at all until I git diff, the whole problem vanishes.
rexf 9y ago
there is the godep tool that addresses the issue https://github.com/tools/godep https://github.com/tools/godep > godep helps build packages reproducibly by fixing their dependencies
- johansch 9y ago
  This is hostile behavior towards a new developer trying out golang. Any third-party tools aren't really going to fix that.
nuggien 9y ago
Just use an editor that has goimports hooked up to run on save.
- johansch 9y ago
  Or pick a language where you don't have to jump through arbitrary hoops.
  - nuggien 9y ago
    depends on which editor you use, but i'd say there's a high chance it has a go package that has all this configured for you. In any case, every language has a hoop to jump through. Good luck finding one without.
mook 9y ago
Unfortunately, just importing the package can have side effects (due to `init()`), so making the programmer explicitly ignore the import is actually useful.

fixermark 9y ago

I'd be even more excited if the compiler were willing to execute complete heresy on my behalf and (with user consent) edit my source code automatically to remove unused imports. ;)

johansch 9y ago
You mean have the compiler modify the source code files destructively? Then I'll have to disagree, that just doesn't make sense.
- dmit 9y ago
  There was a precedent in Haskell land: https://twitter.com/bos31337/status/116372971509121025 https://twitter.com/bos31337/status/116372971509121025 A more modern implementation: https://github.com/munificent/vigil https://github.com/munificent/vigil
  - fixermark 9y ago
    `gofmt -w` also already exists, it just (a) has to be run as a separate step and (b) doesn't have full cross-file understanding of the program. Since we have version control now, I don't see any threat from an optional capacity for the compiler to destructively mutate the source as an optional feature. Let the same toolchain that converts input to output suggest improvements to the input.

ahacker15 9y ago

I like that Go don't allows unused import and variables. If you're working with inexperienced programmers (and some experienced but bad programmers), you should be certain that they WILL let that code garbage there if the compiler allow it.

johansch 9y ago
Funnily enough: I've never found that to be a big problem with other languages in practice. Actually, on a scale of problems in other people's code I'd probably put this very far down the list.
- nuggien 9y ago
  Have you worked with code where unused variables actually have a side effect?
Orangeair 9y ago
That's the kind of thing that should be detected by a linter and stop code submission though, not necessarily stop it from even compiling. What if you just want to comment something out quickly? I don't program in Go, but it seems like it would be annoying to have to repeatedly add and remove the main dependencies while I was iterating on something.
- johansch 9y ago
  It is absurdly annoying. It's the one thing that put me off golang development, despite all of its nice aspects relating to concurrency. Having custom functionality in editors to work around this apparently dogmatic design decision in the core language.. is also just absurd.
- infogulch 9y ago
  This problem is fixed by using the "goimports" tool that will automatically add and remove imports as they're used on save. Pretty much every editor supports it. With goimports and gofmt that formats code, I no longer have to think about formatting and imports at all until I git diff, the whole problem vanishes.

rexf 9y ago

there is the godep tool that addresses the issue https://github.com/tools/godep https://github.com/tools/godep > godep helps build packages reproducibly by fixing their dependencies

johansch 9y ago
This is hostile behavior towards a new developer trying out golang. Any third-party tools aren't really going to fix that.

nuggien 9y ago

Just use an editor that has goimports hooked up to run on save.

johansch 9y ago
Or pick a language where you don't have to jump through arbitrary hoops.
- nuggien 9y ago
  depends on which editor you use, but i'd say there's a high chance it has a go package that has all this configured for you. In any case, every language has a hoop to jump through. Good luck finding one without.

mook 9y ago

Unfortunately, just importing the package can have side effects (due to `init()`), so making the programmer explicitly ignore the import is actually useful.