@fasterthanlime one thing I like about Go, if I remember correctly, is that they have a policy against compiler warnings, either it's something you must fix our it's not, and people tend not to fix warnings
@quirk you want every unused variables to throw an error during debugging? 😰
@Gottox yes?? Why not?
I think that warnings are useless, cause people end up ignoring warnings if there are a lot of them
So, as a compiler writer you have to pick, is it a problem or not? Go chooses errors, other languages chooses to just ignore, Both choices are ok in my opinion
In go you can also just do the following to get rid of the error:
_ = x
@quirk So the attitude is the problem. And objectively it makes difference if the code throws warnings left and right or the code is scattered by _ = x and other shinanigans to avoid them. Warnings are easier to spot though.
@quirk
I largely prefer languages that can be configured to either allow warnings or make them compile errors.
This way I can develop with warnings allowed, but set up the CI to deny all warnings.
This is tremendously useful in Rust where warnings are frequent and useful during development ("doesn't need to be mutable" and "unused parameter" are telltale signs that the implementation is not finished yet).
@Gottox
@quirk people write bad code. That's especially a pattern with Go code. Warnings as errors doesn't solve this problem. Go has great characteristics, this is not one of them for me. But you do you, that's fine.