5 ms·

How is this better than downgrading the error into a warning? You'd be able to build but would still know something was wrong-ish. Certainly a warning would be

How is this better than downgrading the error into a warning? You'd be able to build but would still know something was wrong-ish. Certainly a warning would be sufficient to chase down any bugs, and is very freeing compared to an error.

nouveaux 4y ago
This. Better yet, make this a --strict requirement you can turn on in CI and leave it out for normal development.
xboxnolifes 4y ago
Turned around, what's the benefit of allowing someone to build something that may potentially break, when the alternative is an easy to fix error instead?
- bobbylarrybobby 4y ago
  The benefit is not needing to make any additional source changes when you go from using an import to not using it to using it again.
- another_story 4y ago
  Sometimes you want to comment out something and rerun, and having to do the same with dependencies is annoying. Maybe have a dev vs prod compilation split, with the first allowing unused imports.
tptacek 4y ago
I'm not offering any opinion about the use requirement other than to say that it has caught 3-4 bugs for me.
bborud 4y ago
Knowingly shipping code that generates warnings during build is anti-social. It usually isn't that much work to fix a warning as you are writing the code and you encounter the warning the first time. It becomes much more expensive to fix warnings later because you do not have the mental context you had when you wrote the code. But some people behave like that. They think it is someone else's job to chase down bugs in their code after they have knowingly submitted code with defects rather than deal with it immediately. Classifying something as an error rather than a warning makes zero difference to programmers who take care not to knowingly ship defects. It only makes a difference to people who were going to ignore it and let someone else take up their slack. And to be frank: why on earth would you want to accomodate them?
scott_s 4y ago
I think it's important to know what problem the no-unused-imports error is solving. See Rob Pike's talk from 2012, and in particular, the section of dependencies in C++: https://talks.golang.org/2012/splash.article#TOC_5 https://talks.golang.org/2012/splash.article#TOC_5. Basically, the point of no-unused-imports is to reduce compilation time at scale. In the C++ ecosystem, there are lots of redundant and unused #includes. This means that a lot of the bytes sent to the C++ compiler are just thrown away. If you can guarantee that the compiler will never need to look at a source file it does not need to, you can cut down on the compilation time. For small projects, this doesn't matter much. For large projects, it does. Go was designed for large projects.

nouveaux 4y ago

This. Better yet, make this a --strict requirement you can turn on in CI and leave it out for normal development.

xboxnolifes 4y ago

Turned around, what's the benefit of allowing someone to build something that may potentially break, when the alternative is an easy to fix error instead?

bobbylarrybobby 4y ago
The benefit is not needing to make any additional source changes when you go from using an import to not using it to using it again.
another_story 4y ago
Sometimes you want to comment out something and rerun, and having to do the same with dependencies is annoying. Maybe have a dev vs prod compilation split, with the first allowing unused imports.

tptacek 4y ago

I'm not offering any opinion about the use requirement other than to say that it has caught 3-4 bugs for me.

bborud 4y ago

Knowingly shipping code that generates warnings during build is anti-social. It usually isn't that much work to fix a warning as you are writing the code and you encounter the warning the first time. It becomes much more expensive to fix warnings later because you do not have the mental context you had when you wrote the code. But some people behave like that. They think it is someone else's job to chase down bugs in their code after they have knowingly submitted code with defects rather than deal with it immediately. Classifying something as an error rather than a warning makes zero difference to programmers who take care not to knowingly ship defects. It only makes a difference to people who were going to ignore it and let someone else take up their slack. And to be frank: why on earth would you want to accomodate them?

scott_s 4y ago

I think it's important to know what problem the no-unused-imports error is solving. See Rob Pike's talk from 2012, and in particular, the section of dependencies in C++: https://talks.golang.org/2012/splash.article#TOC_5 https://talks.golang.org/2012/splash.article#TOC_5. Basically, the point of no-unused-imports is to reduce compilation time at scale. In the C++ ecosystem, there are lots of redundant and unused #includes. This means that a lot of the bytes sent to the C++ compiler are just thrown away. If you can guarantee that the compiler will never need to look at a source file it does not need to, you can cut down on the compilation time. For small projects, this doesn't matter much. For large projects, it does. Go was designed for large projects.