@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
@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 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.
@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 @fasterthanlime Which is great fun when refactoring code, I do like spending 20% of my time commenting in and out imports just to be able to run the WIP
@piegames @fasterthanlime Then maybe unused imports shouldn't be an error, at least that's the side I would come down on if I was creating a language
I would rather have a separate utility for my language for cleaning up code formatting and imports and such
@quirk you want every unused variables to throw an error during debugging? 😰