Hacker News Reader

Comment by johansch | Hacker News Reader

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?

View on HN

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.

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.

Have you worked with code where unused variables actually have a side effect?

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.

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.

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.

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

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

Or pick a language where you don't have to jump through arbitrary hoops.

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.

there is the godep tool that addresses the issue https://github.com/tools/godep

> godep helps build packages reproducibly by fixing their dependencies

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

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. ;)

You mean have the compiler modify the source code files destructively? Then I'll have to disagree, that just doesn't make sense.

There was a precedent in Haskell land: https://twitter.com/bos31337/status/116372971509121025

A more modern implementation: https://github.com/munificent/vigil

`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.

Reply on news.ycombinator.com