8 ms·

i was shocked by that at first too. Then I came to love it. It's sooooo go. Don't import stuff you aren't using. Don't declare a var and just leave it there un-

i was shocked by that at first too. Then I came to love it. It's sooooo go. Don't import stuff you aren't using. Don't declare a var and just leave it there un-used. When I go back to ruby and commit that crime, I see why golang did what it did. There's something magical about a golang program that will compile without error. It's worthy of checking in to git. And months later, there will be no unsed imports FOR SURE.

greyskull 10y ago
What about just really obnoxious compiler warnings that can't be disabled?
- majewsky 10y ago
  More than once I've built some free software from source, only to witness literally thousands of warnings being spit out during the compile phase.
  - Sean1708 10y ago
    I would argue that that's becuase checks had to be enabled not because they could be disabled.
wruza 10y ago
Stockholm syndrome in action. There are two phases: active development and release engineering. -Wall for former, -Wextra -Werror for latter. If someone is not disciplined enough to throw out unused variables/imports/whatever from release, Go will not save him from hell.
- sagichmal 10y ago
  > There are two phases: active development and release > engineering. For you, perhaps. Go encourages you to think about your problem and develop it in the "release engineering" style from the very beginning. This is a virtue of the language, in my view.
  - junke 10y ago
    Ada is probably the most real-software-engineers-dont-hack language ever designed, and yet compilers have flags to control checks and warnings.
  - tigershark 10y ago
    No, there is no encouragement here. Go forces you to treat things that have always been just warnings in other languages as errors. And I wouldn't call a virtue something that doesn't give you a choice. I will be really pissed off if the language thinks that I'm so idiot that I need errors instead of simple warnings for the cases discussed here.
    - Klathmon 10y ago
      You are human, humans forget, humans get distracted, humans think that their situation is the exception that makes the rule. A program doesn't suffer from that. Forcing these things to be showstoppers makes sure they NEVER become a problem, and the "cost" (in terms of the developer) is pretty small in the grand scheme of things.
      - tigershark 10y ago
        How in the world forcing someone to put an underscore before the import name or adding a dummy variable to use the import (both should be removed after the debugging) helps to avoid bugs instead of making easier to introduce them?
        Klathmon 10y ago
        Adding a dummy var won't work, because then the dummy var will trip the "no unused variables" check. Adding a _ to the front of an import is not the correct way to get around this "problem" during development, commenting out the whole import is the correct way. That way if you forget, it's not in your code anywhere (as it shouldn't be since it isn't used). The underscore system is meant only to be used when you need to import for side effects (something that i've never actually needed to use).
- laumars 10y ago
  > Stockholm syndrome in action. That's a very negative way of saying "that's not my personal behavioral preference" > There are two phases: active development and release engineering. -Wall for former, -Wextra -Werror for latter. Many of Go's idiosyncrasies are for code readability and maintainability, which is very much a part of active development. The point being to mitigate the likelihood you end up with spaghetti code (yes, I know you ultimately end up with code quality only as good as the developer, but some languages do still make the process easier than others) > If someone is not disciplined enough to throw out unused variables/imports/whatever from release, Go will not save him from hell. Except it does though, since that's the very behaviour you're complaining about.
  - ckastner 10y ago
    >> Stockholm syndrome in action. >That's a very negative way of saying "that's not my personal behavioral preference" In my experience, Stockholm syndrome is not used to describe personal behavioral preferences, but rather (unexpected) transitions between such preferences from the negative to the positive. In the grandparent's own words: >>> i was shocked by that at first too. Then I came to love it.
    - fauigerzigerk 10y ago
      Yes, but it requires that the victim has no way out. Stockholm syndrome is not just any unexpected change of preferences.
      - mtanski 10y ago
        The victim has no way out short of switching languages which may or may not be under their control.
        fauigerzigerk 10y ago
        Stockholm syndrome, as far as I know, was observed in situations of physical threat to life or health with the only way out being death.
- 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.
- AnimalMuppet 10y ago
  > Stockholm syndrome in action. So here's a language feature that you don't like. Other people don't like it and then, after they get more experience, decide they like it after all. And you call it Stockholm syndrome? By saying that, you're asserting that there is no possibility that the feature could possibly be anything other than harmful. That's... pretty arrogant, actually. Both the language designers and the users who like it are objectively wrong, and you're right? Look, you don't like it. That's fine. It doesn't work with the way you like to develop. That's fine, too. But your assertion is that it is worse than useless for all users, and that's a bit more than you have the knowledge to assert.
patates 10y ago
Why on earth would the language hinder you from iterating fast with a flag, and then convert all the warnings to errors when you run the full tests? For example, most JS linters do that check and as a general rule, the build servers would reject the commit when the linter complains. I actually have a (very hacky) plugin to ESLint that automatically removes unused variables before `hg push`. It's totally not optimal, as in, you can still run/compile/transpile/whateverify the code with default options, but a language with no backwards compatibility worries can just add a flag to override strict checks to make a developers life easier, can't it? I understand not implementing something that perhaps may not fit the language well or is so complicated that it really needs a lot of thought (read: generics). But this decision seems to be dogmatic at best. I have the exact love/hate relationship with Go as the author of the article.
- millstone 10y ago
  Devil's advocate: if you can disable -Werror, then users will disable -Werror, and we'll end up in a C-like situation where everything warns all the time, and real problems get buried. Better to inflict some pain during development if it keeps the Go source corpus hygienic. One under-appreciated consequence is that this policy limits Go to one implementation. Say I write an alternative implementation of Go, that has a different "unreachable code" detector. If I issue errors on new cases, then I'm incompatible with lots of existing Go code. If I fail to issue errors, then code developed against me may be incompatible with the standard Go. The effect is to suppress alternative implementations. Better to just put my smarts into a linter, which is then just reinventing compiler warnings under a different guise.
  - patates 10y ago
    > Devil's advocate: if you can disable -Werror, then users will disable -Werror, and we'll end up in a C-like situation where everything warns all the time, and real problems get buried. I already mentioned that case. To be more clear: Let it not build with default options. Make it not `go get`able. Let me develop first, and not force me to optimize prematurely.
junke 10y ago
Define unused imports/variables as warnings but produce an executable that first prints "This program is for debugging purposes only, it built with 133 warnings." and beeps loudly.
- nomel 10y ago
  Nothing like a little public shaming to keep your code in check.
barrkel 10y ago
Unused Ruby variables stand out like a sore thumb, if you have a linter configured with your editor. I use emacs with rubocop through flycheck.

greyskull 10y ago

What about just really obnoxious compiler warnings that can't be disabled?

majewsky 10y ago
More than once I've built some free software from source, only to witness literally thousands of warnings being spit out during the compile phase.
- Sean1708 10y ago
  I would argue that that's becuase checks had to be enabled not because they could be disabled.

wruza 10y ago

Stockholm syndrome in action. There are two phases: active development and release engineering. -Wall for former, -Wextra -Werror for latter. If someone is not disciplined enough to throw out unused variables/imports/whatever from release, Go will not save him from hell.

sagichmal 10y ago
> There are two phases: active development and release > engineering. For you, perhaps. Go encourages you to think about your problem and develop it in the "release engineering" style from the very beginning. This is a virtue of the language, in my view.
- junke 10y ago
  Ada is probably the most real-software-engineers-dont-hack language ever designed, and yet compilers have flags to control checks and warnings.
- tigershark 10y ago
  No, there is no encouragement here. Go forces you to treat things that have always been just warnings in other languages as errors. And I wouldn't call a virtue something that doesn't give you a choice. I will be really pissed off if the language thinks that I'm so idiot that I need errors instead of simple warnings for the cases discussed here.
  - Klathmon 10y ago
    You are human, humans forget, humans get distracted, humans think that their situation is the exception that makes the rule. A program doesn't suffer from that. Forcing these things to be showstoppers makes sure they NEVER become a problem, and the "cost" (in terms of the developer) is pretty small in the grand scheme of things.
    - tigershark 10y ago
      How in the world forcing someone to put an underscore before the import name or adding a dummy variable to use the import (both should be removed after the debugging) helps to avoid bugs instead of making easier to introduce them?
      - Klathmon 10y ago
        Adding a dummy var won't work, because then the dummy var will trip the "no unused variables" check. Adding a _ to the front of an import is not the correct way to get around this "problem" during development, commenting out the whole import is the correct way. That way if you forget, it's not in your code anywhere (as it shouldn't be since it isn't used). The underscore system is meant only to be used when you need to import for side effects (something that i've never actually needed to use).
laumars 10y ago
> Stockholm syndrome in action. That's a very negative way of saying "that's not my personal behavioral preference" > There are two phases: active development and release engineering. -Wall for former, -Wextra -Werror for latter. Many of Go's idiosyncrasies are for code readability and maintainability, which is very much a part of active development. The point being to mitigate the likelihood you end up with spaghetti code (yes, I know you ultimately end up with code quality only as good as the developer, but some languages do still make the process easier than others) > If someone is not disciplined enough to throw out unused variables/imports/whatever from release, Go will not save him from hell. Except it does though, since that's the very behaviour you're complaining about.
- ckastner 10y ago
  >> Stockholm syndrome in action. >That's a very negative way of saying "that's not my personal behavioral preference" In my experience, Stockholm syndrome is not used to describe personal behavioral preferences, but rather (unexpected) transitions between such preferences from the negative to the positive. In the grandparent's own words: >>> i was shocked by that at first too. Then I came to love it.
  - fauigerzigerk 10y ago
    Yes, but it requires that the victim has no way out. Stockholm syndrome is not just any unexpected change of preferences.
    - mtanski 10y ago
      The victim has no way out short of switching languages which may or may not be under their control.
      - fauigerzigerk 10y ago
        Stockholm syndrome, as far as I know, was observed in situations of physical threat to life or health with the only way out being death.
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.
AnimalMuppet 10y ago
> Stockholm syndrome in action. So here's a language feature that you don't like. Other people don't like it and then, after they get more experience, decide they like it after all. And you call it Stockholm syndrome? By saying that, you're asserting that there is no possibility that the feature could possibly be anything other than harmful. That's... pretty arrogant, actually. Both the language designers and the users who like it are objectively wrong, and you're right? Look, you don't like it. That's fine. It doesn't work with the way you like to develop. That's fine, too. But your assertion is that it is worse than useless for all users, and that's a bit more than you have the knowledge to assert.

patates 10y ago

Why on earth would the language hinder you from iterating fast with a flag, and then convert all the warnings to errors when you run the full tests? For example, most JS linters do that check and as a general rule, the build servers would reject the commit when the linter complains. I actually have a (very hacky) plugin to ESLint that automatically removes unused variables before `hg push`. It's totally not optimal, as in, you can still run/compile/transpile/whateverify the code with default options, but a language with no backwards compatibility worries can just add a flag to override strict checks to make a developers life easier, can't it? I understand not implementing something that perhaps may not fit the language well or is so complicated that it really needs a lot of thought (read: generics). But this decision seems to be dogmatic at best. I have the exact love/hate relationship with Go as the author of the article.

millstone 10y ago
Devil's advocate: if you can disable -Werror, then users will disable -Werror, and we'll end up in a C-like situation where everything warns all the time, and real problems get buried. Better to inflict some pain during development if it keeps the Go source corpus hygienic. One under-appreciated consequence is that this policy limits Go to one implementation. Say I write an alternative implementation of Go, that has a different "unreachable code" detector. If I issue errors on new cases, then I'm incompatible with lots of existing Go code. If I fail to issue errors, then code developed against me may be incompatible with the standard Go. The effect is to suppress alternative implementations. Better to just put my smarts into a linter, which is then just reinventing compiler warnings under a different guise.
- patates 10y ago
  > Devil's advocate: if you can disable -Werror, then users will disable -Werror, and we'll end up in a C-like situation where everything warns all the time, and real problems get buried. I already mentioned that case. To be more clear: Let it not build with default options. Make it not `go get`able. Let me develop first, and not force me to optimize prematurely.

junke 10y ago

Define unused imports/variables as warnings but produce an executable that first prints "This program is for debugging purposes only, it built with 133 warnings." and beeps loudly.

nomel 10y ago
Nothing like a little public shaming to keep your code in check.

barrkel 10y ago

Unused Ruby variables stand out like a sore thumb, if you have a linter configured with your editor. I use emacs with rubocop through flycheck.