Hacker News Reader

Comment by kstenerud | Hacker News Reader

Go's tooling is very nice compared to most other dev technologies, and the source is quite hackable as well. I made a 1-commit modification to the compiler that adds a flag -warnunused to make it stop failing on unused imports or variables [1], and it was remarkably simple to do in the go src tree.

Plus, it's super easy for other people to use. Just check out the modified source, make.bash, and you're done in less than a minute of compilation!

I may not agree with some of their philosophies, but the tooling is nice!

[1] https://github.com/kstenerud/go

View on HN

Oh man, that commit is serious business! Documented and everything!

Looks like you're prepping for a PR? Good luck, in earnest; the import-in-import-out dance is like adding 8 seconds to every dev cycle.

Just hook your editor up to run goimports on save.

Doesn't help when you remove chunks for testing purposes, but want to keep the imports around as you'll be adding them back immediately after and don't want to search for the right import again.

My experience with GoLand is that it manages to add back the right imports (notably with things like errors vs github.com/pkg/errors vs github.com/cockroachdb/errors, where they all share a package name and ~interface) but that might just be me getting lucky or not noticing changes.

You got lucky. And it still doesn't solve the problem of unused variables.

At the end of the day, it's a hair shirt. And no matter how many coping mechanisms people come up with, it's still a hair shirt.

Even the go authors had to put a limit on their madness. You'll notice that unused unexported functions don't cause compilation errors despite the fact that they, too, fall afoul of the original justification for this policy: https://golang.org/doc/faq#unused_variables_and_imports

"The presence of an unused variable may indicate a bug, while unused imports just slow down compilation, an effect that can become substantial as a program accumulates code and programmers over time. For these reasons, Go refuses to compile programs with unused variables or imports, trading short-term convenience for long-term build speed and program clarity."

But disallowing unused functions would have been a bridge too far, so we're left with this half-measure and half-reasoning that doesn't even make sense.

> But disallowing unused functions would have been a bridge too far, so we're left with this half-measure and half-reasoning that doesn't even make sense.

how would you find an unused function?

The same way you detect unused variables: Look for accesses, and if nothing accesses the function, it's unused.

Note that I'm talking about non-exported functions (i.e. someFunction rather than SomeFunction).

while a pain, for unused variables, if it comes up, right under the declared variable, just add the line: _ = myVar. Bingo, now it is used. Gross, but works.

I think you missed the point of the comment - no matter if you're removing or adding imports, the tool (goimports) should do it for you automatically. It's easy to setup with any modern text editor (VSCode, emacs, etc)

What of when there are duplicate symbols with the same name? And this doesn’t help with unused locals. Also, another commenter pointed out that unused local functions don’t get flagged. Go authors probably realized that making people delete and restore entire function bodies during debugging was too much, but they could still convince people to be okay with deleting and restoring import statements and local variable definitions.

It's much rarer that an unused function indicates an error.

Exactly. Imports should never be an issue with the tooling available, i.e. goimports, and almost any text editor that can run the tool on save.

https://github.com/golang/go/compare/master...kstenerud:mast...

> this commit will not go into mainline go

Truly unfortunate. I don't write Go, but so often I comment out large swaths of code for debugging purposes and get warnings for unused variables and imports. If I couldn't simply ignore the warnings, I would not be a happy camper. It's funny to me that people call it a "hackers language", when it seems so restricting from afar.

Can you expand on the use case for your change? Why would you want unused imports or variables?

When actively developing code, it can be useful for warnings to go away. Get things to work, then make it tidy.

When I'm debugging something, I don't want compiling to fail just because I've commented out the only line that uses the net/url package. If I temporarily modify a function call to use a literal instead of a variable so I can test an assumption, I don't want it to refuse to compile just because that variable is now "unused". The cascade effect of this can get quite extensive and annoying.

Same goes for exploratory programming, where I'm testing out ideas rather than writing production code. I expect my tools to get out of my way rather than play nanny.

Alternatively just add usages at top of package that have no real effects. This is experimental code after all! Never had problems with this, but yes, it's a bit different.

But then if you forget to take those bits out, you now have unused things in your checked in code, which is exactly what the compiler was trying to prevent!

The build flags approach is more comprehensive and safer, because it simply won't compile when you build without the -warnunused flag (for example in your ci trigger off your git repo).

So many silly workarounds being suggested here. You should be able to pass a flag to accomplish this, anything else is simply annoying and drives away new users.

That's a feature!

You could have a flag, but we all know this is going to be abused. Seems devs have opted away from such, though it is understandably opinionated and require some thought.

In what way would it be abused? "To use this library, you must enable warnings in your build"? Yeah, that's gonna fly. If your code won't compile with default options, nobody will want to use it.

This is just a solution in search of a problem.

Isn't such types of shenanigans SOP in many communities?

Not against options per se, but can see the arguments against implicitly hiding alternative behaviour. Many compilers fail to be simple, performant and provide the right incentives.

Again, never had problems adding experimental code (// TODO: Remove), bootstrap-code, extra debug-info, etc. Ie. Why you should want to prefer refactoring.

It's not a feature, it's an annoyance. Don't use the flag in CI and don't allow merges until CI passes. It's not hard.

I learned to always wrap the code with `if false {}` instead of commenting them out because of this very reason.

That doesn't give you nearly the same flexibility as commenting out, as if statements are not expressions, but epsilon can very well be. JS:

const value = getMainValue() + calculateAdjustment();

const value = getMainValue() // + calculateAdjustment();

goimports on save will change your life :)

Goimports breaks when two packages have the same local name, can't handle import name overrides, and doesn't solve the variable problem. My solution fixes everything.

> Why would you want unused imports or variables?

The main reason would be that they don’t actually matter and having to strip them out is a worthless pain in the ass when trying things out.

Reply on news.ycombinator.com