I can see the sentiment here… Going through 100 clippy warning on Rust is just not fun… I know there’s the good old clippy --fix but I’m paranoid it breaks my code accidentally.
Could probably have a compromise like 5 unused variables and your code don’t compile
I totally agree that it’s really annoying when debugging, but go run literally builds then executes. I think what they should do is add a build flag. So debug builds can pass that flag to get the builder to shut up, and leave it those errors enabled for production builds.
Or, you know, treat it as a warning like literally every other language. There’s absolutely no good reason for it to prevent a build outright, but then again, there’s not really good reasons for many of the decisions behind go.
Its an effort to keep large code bases clean. I think they should allow them when running
go runbut not when building.I can see the sentiment here… Going through 100 clippy warning on Rust is just not fun… I know there’s the good old clippy --fix but I’m paranoid it breaks my code accidentally.
Could probably have a compromise like 5 unused variables and your code don’t compile
Automated tests and version control should prevent that from being a problem, I imagine.
I totally agree that it’s really annoying when debugging, but
go runliterally builds then executes. I think what they should do is add a build flag. So debug builds can pass that flag to get the builder to shut up, and leaveitthose errors enabled for production builds.deleted by creator
Has Google never heard of CI to perform such checks?
Or, you know, treat it as a warning like literally every other language. There’s absolutely no good reason for it to prevent a build outright, but then again, there’s not really good reasons for many of the decisions behind go.