As your future colleague wondering what the hell that variable is for, thanks Go.
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).
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
Let’s not pretend people acknowledge warnings, though. It’s a popular meme that projects will have hundreds of warnings and that devs will ignore them all.
There’s a perfectly valid use case for opinionated languages that don’t let you get away with that. It’s also similar to how go has gofmt to enforce a consistent formatting.
Honestly, I’ve been using Go for years and this unused variable error rarely comes up. When it does, it’s trivial to resolve. But the error has saved me from bugs more often than it has wasted my time. Most commonly when you declare a new variable in a narrower scope when you intended to assign to the variable of the same name (since Go has separate declare vs assign operators).
You can, if you want, opt into warnings causing your build to fail. This is commonly done in larger projects. If your merge request builds with warnings, it does not get merged.
In other words, it’s not a bad idea to want to flag unused variables and prevent them from ending up in source control. It’s a bad idea for the compiler to also pretend it’s a linter, and for this behaviour to be forced on, which ironically breaks the Unix philosophy principle of doing one thing and doing it well.
Mind you, this is an extremely minor pain point, but frankly this is like most Go design choices wherein the idea isn’t bad, but there exists a much better way to solve the problem.
Isnt the syntax highlighting it as mever used?
So why would they wonder?
Changing it will bring down the entire system.
We’ve spent ten million dollars and do not know why.
Sometimes I think Go was specifically made for Google to dictate its own preferences on the rest of us like some kind of power play. It enforces one single style of programming too much.
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.
As far as C++ goes, that’s probably the only sane way to use the language.
Go is not a programming language. It’s an angry rant of a bored Google engineer.
IDK, Brainfuck is still classified as a programming language and Go is not that far behind it.
If this language feature is annoying to you, you are the problem. You 👏are 👏 the 👏 reason 👏 it 👏 exists.
I worked in places where the developers loaded their code full of unused variables and dead code. 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).
This is a very attractive feature for a programming language in my opinion.
PS: I’m still denying your pull request if you try to comment the code instead.
❗️EDIT: A lot of y’all have never been to programming hell and it shows. 🪖 I’m telling you, I’ve fixed bayonets in the trenches of dynamically typed Python, I’ve braved the rice paddies of CICD YAML mines, I’ve queried alongside SQL Team Six; I’ve seen things in production, things you’ll probably never see… things you should never see. It’s easy to be against an opinionated compiler having such a feature, but when you watch a prod deployment blow up on a Friday afternoon without an easy option to rollback AND hours later you find the bug after you were stalled by dead code, it changes you. Then… then you start to appreciate opinionated features like this one. 🫡
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.
reading my code after being up for 18 hours and having my eyes glaze over trying to parse the structure of my monochromatic code but then I remember Rob Pike said syntax highlighting is juvenile so I throw my head against that wall for another 3 hours
Prescription glasses are juvenile. When I was a child, I was prescribed visual aid to help my nearsightedness. I grew up and today I raw-dog the road.
What’s a situation where you need an unused variable? I’m onboard with go and goland being a bit aggressive with this type of thing, but I can’t think of the case where I need to be able to commit an unused variable.
You probably wouldn’t be committing this, unless you’re backing up a heavily WIP branch. The issue is that if you’re developing locally and need to make a temporary change, you might comment something out, which then requires commenting another now-unused variable, which then requires commenting out yet another variable, and so on. Go isn’t helping you here, it’s wasting your time for no good reason. Just emit a warning and allow CI to be configured to reject warnings.
And I fucking love it. Thank you Go!
lol what’s wrong with you
“Other people” are what’s wrong with me. People don’t use linters/formatters/type annotations when it’s optional and produce dogshite code as a result. Having the compiler itself enforce some level of human decency is a godsend.
Also Go: exceptions aren’t real, you declare and handle every error at every level or declare that you might return that error because go fuck yourself.
Because that’s sane and readable?
Wow. I’m honestly surprised I’m getting downvotes for a joke. Also, no. It isn’t. It really isn’t.
It is better than in most languages with exceptions, except from languages like Java, that require you to declare that certain method throws certain error.
It’s more tedious in Go, but at the end of the day it’s the same thing.
When I use someone else’s code I want to be sure if that thing can throw an error so I can decide what to do with it.
