For a little while I used to compile with -Werror but I found it very annoying. I very often want to make a quick test commenting out a function call or doing an early return that would trigger a warning for dead code and prevent me from continuing.

It might be a good idea to add it to your build bot though, this way you can enforce it for commited code. That's a good compromise IMO.

You use linters to catch those issues (and more). Any quality project will have linters, CI/CD etc. set up. And it's not like golang obviates the need for linters, if anything, it needs them more than other languages to deal with several issues, including (ironically) accidentally ignoring handling errors.

Is ignoring errors really a problem in practice? I’ve been using this language since before 1.0 and I don’t think I’ve ever been burned by this. I’m sure it happens once in a while (albeit at very low frequency), but people in this thread act like you can’t build software in Go because the compiler doesn’t catch every ignored error.

It gets in your way when you're debugging or writing quick scripts.

Yes, it does: -Werror=unused-variable

Presumably by "unconditional" they mean not conditioned on you using a flag.

There's another switch that treats all warnings as errors and therefore bails out.

You could enforce -Werror for all debug builds, but that might be too draconian.

isn't that what go does?

after all there's no way to ignore unused variables with a compiler option

And that's part of the reason why some people will bever use go or other languages that add purely stylistical restrictions on you