I prefer for it to be just a warning so I can debug without trouble, the build system will just prevent me from completing the pull request with it (and any other warning).

Changing it will bring down the entire system.

We've spent ten million dollars and do not know why.

Isnt the syntax highlighting it as mever used?

So why would they wonder?

A quick "find all references" will point out it's not used and can be deleted if it accidentally gets checked in but ideally, you have systems in place to not let it get checked into the main branch in the first place.

If only there was some way the compiler could detect unused variable declarations, and may be emit some sort of "warning", which would be sort of like an "error", but wouldn't cause the build to fail, and could be treated as an error in CI pipelines

From what I've heard from Google employees Google is really stringent with their coding standards and they usually limit what you can do with the language. Like for C++ they don't even use half the fancy features C++ offers you because it's hard to reason about them.

I guess that policy makes sense but I feel like it takes out all the fun out of the job.

Is this a hard error? Like it doesn't compile at all?

Isn't there something like #[allow(unused)] in Rust you can put over the declaration?

IDK, Brainfuck is still classified as a programming language and Go is not that far behind it.

That's 👏 what 👏 CI 👏 is 👏 for

Warn in dev, enforce stuff like this in CI and block PRs that don't pass. Go is just being silly here, which is not surprising given that Rob Pike said

Syntax highlighting is juvenile. When I was a child, I was taught arithmetic using colored rods. I grew up and today I use monochromatic numerals.

The Go developers need to get over themselves.

That's a problem with your workplace, not the language nor OP.
You could have a build setting for personal development where unused variables are not checked, and then a build setting for your CI system that will look for them. It gives you freedom to develop the way you want without being annoyed when you remove something just to test something, but will not merge your PR unless the stricter rules are met.

That's what warnings are for. The jokes about programmers ignoring warnings are outdated - we live in an age where CIs run linters and style checkers on pull requests, there is no reason for a CI to not automatically reject code that builds with warnings.

I mean, yeah that kind of stuff absolutely should not be in production. However, it's easy to see how it could be annoying while testing something while working on it. It being annoying doesn't make it a bad feature, just as finding it annoying doesn't make you a problem imo.

Lol new copypasta unlocked 🔓

It costs a lot of time reasoning about it during pull request and it costs a lot of time arguing with coworkers who swear that they’re going to need that code in there next week (they never need that code).

You should go to your team leader and ask them to enforce a coding standard. I agree with other commenters that said this should be a warning instead of an error.

Because that's sane and readable?