4 ms·

This may work for you code. But are you sure that all the libraries you use also follow that rule? Are you going to audit all of those projects and their depend

by zaphar 10y ago

This may work for you code. But are you sure that all the libraries you use also follow that rule? Are you going to audit all of those projects and their dependencies to validate they follow the same best practices as you? The end result of Go's opinion on warnings is that you know a certain class of bugs in not present anywhere in both your code and all of your dependencies. While it's true that people and teams that follow the best practices around warnings also tend to follow the best practices for other things but there is no guarantee for the ecosystem in a language that allows warnings, and no project lives in a vacuum.

hehheh 10y ago
This is an easy problem to solve. The Go compiler could simply include a bit in the resulting binary/library that indicates whether or not it was built with the "disable-unused-variable-error" flag. If you're using a library that was built with that flag the compiler can simply refuse to compile your code without that flag, forcing you to acknowledge the problem head-on.
- zaphar 10y ago
  This doesn't solve the problem. It just makes you aware it might be there. It doesn't keep the ecosystem clean. The result will be that everyone compiles with that flag on so they can use the libraries they want/need. It's in fact actively worse than just allowing warnings. At least if you allow warnings that way you aren't forced to lower your own codes protection just because one of your dependencies does.
  - hehheh 10y ago
    If a library is so popular that "everyone" uses the flag so they can use it, surely someone can be convinced to remove the unused import statement. If the ecosystem makes that difficult then we're talking about a totally different problem.
  - wruza 10y ago
    Complaining about unused import doesn't solve anything IRL, if we talking about solving something. Problems in code are complex diseases, and cleaning unused entities is like washing your hands, not like taking a cure. And hand cleanliness checks is too idiotic measure to cure brain cancer. Of course all our problems are still here in both cases, but at least with Go we will die clean for sure.

by zaphar 10y ago

hehheh 10y ago

This is an easy problem to solve. The Go compiler could simply include a bit in the resulting binary/library that indicates whether or not it was built with the "disable-unused-variable-error" flag. If you're using a library that was built with that flag the compiler can simply refuse to compile your code without that flag, forcing you to acknowledge the problem head-on.

zaphar 10y ago
This doesn't solve the problem. It just makes you aware it might be there. It doesn't keep the ecosystem clean. The result will be that everyone compiles with that flag on so they can use the libraries they want/need. It's in fact actively worse than just allowing warnings. At least if you allow warnings that way you aren't forced to lower your own codes protection just because one of your dependencies does.
- hehheh 10y ago
  If a library is so popular that "everyone" uses the flag so they can use it, surely someone can be convinced to remove the unused import statement. If the ecosystem makes that difficult then we're talking about a totally different problem.
- wruza 10y ago
  Complaining about unused import doesn't solve anything IRL, if we talking about solving something. Problems in code are complex diseases, and cleaning unused entities is like washing your hands, not like taking a cure. And hand cleanliness checks is too idiotic measure to cure brain cancer. Of course all our problems are still here in both cases, but at least with Go we will die clean for sure.