Not a go dev. Is it really preventing compilation or is it just some hardened linting rules? Most languages can prevent compile on those errors if tweaked, but that seems bad if it’s not a warning
Yes, and it fucking sucks. It’s a great thing to lint for but it makes debugging such a pain - commenting out an irrelevant block to focus your debugging will sometimes break your ability to compile… it’s extremely jarring.
This is why many languages have errors and warnings as separate things. Errors for things that for sure prevent the program from working, and warnings for things that are probably wrong but don’t prevent things from working. If you have a setting to then treat warnings as errors (like for CI checks), then you get all the guarantees and none of the frustration.
Have they given an explanation as to why that is? I mean why make it a fatal error that prevents compilation, when you could make it a warning and have the compiler simply skip it?
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.
There’s two types of programming languages, the ones people complain about and the ones nobody uses. Go is still my most productive language and is killer for building webservers. I basically use it as a scripting language since it’s so fast to write, compile, and execute.
What reason is there for this when the compiler could just optimize that variable out of existence? This feels like the most hand holdy annoying “feature” unless I’m missing something.
If you need to take variable you don’t use for some reason (like it’s a function arg that has to follow an interface, but it doesn’t need a specific parameter in this case), then you can prefix it with an underscore.
If the language weren’t pushed by Google, nobody would pay it any attention. It’s yet another attempt to “do C right” and it makes some odd choices in the attempt.
I for my part prefer it that way. Makes sure the code stays clean and nobody can just silence the warnings and be done with it. Because why would you accept useless variables that clutter the code in production builds? Imagine coming back after some time and try to understand the code again. At least you have the guarantee the variable is used somehow and not just “hmm, what does this do? … ah, it’s unused”
…you don’t accept them. Basically every programming language accepts some kind of -werror flag to turn warnings into errors. Warnings for development builds, errors for production builds. This has been a solved problem for a very long time. Not only is it assinine to force them to be errors always, it’s semantically incorrect. Errors should be things that prevent the code from functioning in some capacity.
Oh, that makes warnings errors and does not mean “ignore errors”. I’m not too familiar with compiler flags.
You could do some mental gymnastics to argue that the unused variable causes the compiler to exit and thus the code is not functioning and thus the unused variable is not a warning but an error :^)
It’s a pretty standard flag in basically all compiled languages, just goes by a different name. -werror in C, -Werror in Java, TreatWarningsAsErrors in C#, etc.
*when I’m doing debugging that requires commenting out code.
Most of the time, I don’t comment out code. I run the code in a debugger, step through it, and see how the behavior deviates from what I expect. I mostly only resort to commenting out code if I’m having trouble figuring out where the problem is coming from, which isn’t that often.
I don’t think its inherently bad but it feels jarring when the language allows you reference nill pointers. It’s so effective in its hand holding otherwise that blowing things up should not be so easy.
Not a go dev. Is it really preventing compilation or is it just some hardened linting rules? Most languages can prevent compile on those errors if tweaked, but that seems bad if it’s not a warning
Yes, and it fucking sucks. It’s a great thing to lint for but it makes debugging such a pain - commenting out an irrelevant block to focus your debugging will sometimes break your ability to compile… it’s extremely jarring.
Making a variable just to hold a debug value to look at with a breakpoint, but Go says no.
You can do
_ = variablePrint-style debugging/logging has entered the chat.
This is why many languages have errors and warnings as separate things. Errors for things that for sure prevent the program from working, and warnings for things that are probably wrong but don’t prevent things from working. If you have a setting to then treat warnings as errors (like for CI checks), then you get all the guarantees and none of the frustration.
Have they given an explanation as to why that is? I mean why make it a fatal error that prevents compilation, when you could make it a warning and have the compiler simply skip it?
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.I figured that much was implied, but I agree.
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.
Keep in mind that this is the same language that prefers function names ToBeLikeThis(), and the reason is that it looks different than Java.
Every time I think “perhaps I should give Golang another try”, it’s shit like this that keeps me noping out
There’s two types of programming languages, the ones people complain about and the ones nobody uses. Go is still my most productive language and is killer for building webservers. I basically use it as a scripting language since it’s so fast to write, compile, and execute.
just dogsled shit
Unused variable is an error which fails to compile.
What reason is there for this when the compiler could just optimize that variable out of existence? This feels like the most hand holdy annoying “feature” unless I’m missing something.
Cleaner code. That’s all.
If you need to take variable you don’t use for some reason (like it’s a function arg that has to follow an interface, but it doesn’t need a specific parameter in this case), then you can prefix it with an underscore.
That’s what warnings are for and
-werrorfor production builds in literally any other language. This has been a solved problem for a very long time.Sure. Tell that to the Go devs.
If the language weren’t pushed by Google, nobody would pay it any attention. It’s yet another attempt to “do C right” and it makes some odd choices in the attempt.
I for my part prefer it that way. Makes sure the code stays clean and nobody can just silence the warnings and be done with it. Because why would you accept useless variables that clutter the code in production builds? Imagine coming back after some time and try to understand the code again. At least you have the guarantee the variable is used somehow and not just “hmm, what does this do? … ah, it’s unused”
…you don’t accept them. Basically every programming language accepts some kind of
-werrorflag to turn warnings into errors. Warnings for development builds, errors for production builds. This has been a solved problem for a very long time. Not only is it assinine to force them to be errors always, it’s semantically incorrect. Errors should be things that prevent the code from functioning in some capacity.Oh, that makes warnings errors and does not mean “ignore errors”. I’m not too familiar with compiler flags. You could do some mental gymnastics to argue that the unused variable causes the compiler to exit and thus the code is not functioning and thus the unused variable is not a warning but an error :^)
It’s a pretty standard flag in basically all compiled languages, just goes by a different name.
-werrorin C,-Werrorin Java,TreatWarningsAsErrorsin C#, etc.Whoah, that seems like you’d flesh out code elsewhere, you know when you throw stuff together to make it work, and then fix it up to standards.
Feels like you should have to make git commits perfectly well before being able to compile…
Put that overwhelmingly intrusive thing in a hook checking out your commits instead (when you push your branch ofc).
You get used to it. The only time I really notice it these days is when I’m debugging and commenting out code.
So… A lot of the time?
“Nah, only when working…”
*when I’m doing debugging that requires commenting out code.
Most of the time, I don’t comment out code. I run the code in a debugger, step through it, and see how the behavior deviates from what I expect. I mostly only resort to commenting out code if I’m having trouble figuring out where the problem is coming from, which isn’t that often.
I don’t think its inherently bad but it feels jarring when the language allows you reference nill pointers. It’s so effective in its hand holding otherwise that blowing things up should not be so easy.
Yes but I’ve never found it to be that annoying.