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).

Some people simply ignore warnings, that’s the main issue. Trust me, I saw this way too often.

If you cannot compile it than you have to fix it, otherwise just mark unused variables as ‘not an error’ via _ = someunusedvar.

Yeah that should be looked for in a CI line check, not a compilation requirement

Yeah any compiler should support environments or config files. Our CI would never work with without --env “stage”

You mean a system like the compiler

Yeah, insisting on things like a variable being used will result in people using work arounds. It won’t result in people not doing it.

Then, because people trust the language to police this rule, the work-arounds and debug code will get committed.

func main() {  
    test := true  
}  

Oops, golang doesn’t like that.

func main() {  
    test := true  
    _ = test  
}

Perfectly cromulent code.

If they really wanted to avoid people having unused variables, they should have used a naming convention. Any variable not prefixed by “_” or “_debug_” or whatever has to be used, for example. Then block any code being checked in that still contains those markers.

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

I agree that golang is being dumb when you don’t even have the option to tell it that this is a testing env or something. But the thing about syntax highlighting is not the same. One is about handholding the developer so much that it makes it even more difficult to develop, and the other is a completely optional feature that is so uselful and non intrusive that even wizardly editors like emacs use it.

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.

I concur, it is a problem with that workplace. (In this case, OP is just sharing a funny meme. I wouldn’t suggest this meme means they’re a problem. I could have made this meme and I love the feature.)

Developing on a team at a company is like the “Wild West.” What’s considered to be acceptable will not only vary from workplace to workplace, but it can also fluctuate as developers and managers come and Go. Each of them have their own unique personality with their own outlook on what “quality” code looks like. (And many of them do not care about code quality whatsoever. They just need to survive 1-2 years there, make management happy with speedy deliveries, and then they can move on to the next company with a 30% pay bump.)

Having experienced working with developers who frequently filled with code base with unused code while having no control over who will leave or join as a contributor to the code base, I think features like this make for a more sane development experience when you’re developing with a team of seemingly random people that you never personally invited to contribute to the code base.

will not merge your PR unless the stricter rules are met.

This doesn’t fly when you work in big corporate and the boss doesn’t care about the code meeting stricter rules. “A working prototype? No it’s not- that’s an MVP! Deploy it to production now and move onto the next project!”

Why in the world would you want to develop something that doesn’t follow the coding rules required by your org, just so you can go back and fix everything before submitting a PR? That’s just extra work.

🫡

No amount of propaganda will ever get me to pronounce it “sequel”. I’ll die in that hill.

As far as C++ goes, that’s probably the only sane way to use the language.

Just about any place I know that uses C++ also does that with C++ so that’s nothing unusual for C++ specifically. It’s too big of a language to reason about very well if you don’t, so you’ve gotta find a subset that works.

Never really coded in Go outside of trying it out, but as far as I know it’s a hard error.

Yes it is a hard error and Go does not compile then. You can do _ = foobar to fake variable usage. I think this is okay for testing purposes.

The exception handling question mark, spelled ? and abbreviated and pronounced eh?, is a half-arsed copy of monadic error handling. Rust devs really wanted the syntax without introducing HKTs, and admittedly you can’t do foo()?.bar()?.baz()? in Haskell so it’s only theoretical purity which is half-arsed, not ergonomics.

The language was designed to be as simple as possible, as to not confuse the developers at Google. I know this sounds like something I made up in bad faith, but it’s really not.

The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike

"It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical. – Rob Pike

The infamous if err != nil blocks are a consequence of building the language around tuples (as opposed to, say, sum types like in Rust) and treating errors as values like in C. Rob Pike attempts to explain why it’s not a big deal here.

a desperate fear of modular code that provides sound and safe abstractions over common patterns. that the language failed to learn from Java and was eventually forced to add generics anyway - a lesson from 2004 - says everything worth saying about the language.

Exceptions don’t exists and ask errors must be handled at every level. It’s infuriating.

This is not needed anymore since version 1.20

“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.

Wow. I’m honestly surprised I’m getting downvotes for a joke. Also, no. It isn’t. It really isn’t.