As your future colleague wondering what the hell that variable is for, thanks Go.
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?
If it is a pure value, I’d assume yes, but if it is tied to a side effect (E.g. write its value to a file), then it would be not used but still could break your app if removed.
I’m not familiar with rust language specifically, but generally that’s what could happen
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.
Yeah that should be looked for in a CI line check, not a compilation requirement
You mean a system like the compiler
Or a linter. Or code reviews. Or anything else. The nice thing is that if the compiler doesn’t demand something, it can be given to the engineer as an option. The compiler should have the option to do it. The option could even be defaulted on. Afaik there is no way in Golang to disable that error (this is the line that does it: https://github.com/golang/go/blob/04fb929a5b7991ed0945d05ab8015c1721958d82/src/go/types/stmt.go#L67-L69). like --no-pedantics or such. Golang’s compiler openly refuses to give engineers more choices in what they think is the best system to handle it.
Who needs an option to leave unused variables around the code base? Lazybones?
You’ve literally never commented out a line or two but left the variable declaration while debugging?
deleted by creator
People are scared of monads and think this is better.
My brain is too smooth to imagine a solution to this using monads. Mind sharing what you got with the class?
Someone else and not an expert. But Maybe types are implemented with Monads, Maybe is a common monad.
Its how rust does error handling for example, you have to test a return value for “something or nothing” but you can pass the monadic value and handle the error later, in go you have to handle the error explicitly (almost) all the time.
Here’s an example (first in Haskell then in Go), lets say you have some types/functions:
- type Possible a = Either String a
- data User = User { name :: String, age :: Int }
- validateName :: String -> Possible String
- validateAge :: Int -> Possible Int
then you can make
mkValidUser :: String -> Int -> Possible User mkValidUser name age = do validatedName ← validateName name validatedAge ← validateAge age pure $ User validatedName validatedAge
for some reason <- in lemmy shows up as
<-
inside code blocks, so I used the left arrow unicode in the above insteadin Go you’d have these
- (no
Possible
type alias, Go can’t do generic type aliases yet, there’s an open issue for it) - type User struct { Name string; Age int }
- func validateName(name string) (string, error)
- func validateAge(age int) (int, error)
and with them you’d make:
func mkValidUser(name string, age int) (*User, error) { validatedName, err = validateName(name) if err != nil { return nil, err } validatedAge, err = validateAge(age) if err != nil { return nil, err } return User(Name: validatedName, Age: validatedAge), nil }
In the Haskell, the fact that
Either
is a monad is saving you from a lot of boilerplate. You don’t have to explicitly handle theLeft
/error case, if any of theEither
s end up being aLeft
value then it’ll correctly “short-circuit” and the function will evaluate to thatLeft
value.Without using the fact that it’s a functor/monad (e.g you have no access to fmap/>>=/do syntax), you’d end up with code that has a similar amount of boilerplate to the Go code (notice we have to handle each
Left
case now):mkValidUser :: String -> Int -> Possible User mkValidUser name age = case (validatedName name, validateAge age) of (Left nameErr, _) => Left nameErr (_, Left ageErr) => Left ageErr (Right validatedName, Right validatedAge) => Right $ User validatedName validatedAge
Swift and Rust have a far more elegant solution. Swift has a pseudo throw / try-catch, while Rust has a Result<> and if you want to throw it up the chain you can use a ? notation instead of cluttering the code with error checking.
The exception handling question mark, spelled
?
and abbreviated and pronouncedeh?
, is a half-arsed copy of monadic error handling. Rust devs really wanted the syntax without introducing HKTs, and admittedly you can’t dofoo()?.bar()?.baz()?
in Haskell so it’s only theoretical purity which is half-arsed, not ergonomics.Note: Lemmy code blocks don’t play nice with some symbols, specifically < and & in the following code examples
This isn’t a language level issue really though, Haskell can be equally ergonomic.
The weird thing about
?.
is that it’s actually overloaded, it can mean:- call a function on
A?
that returnsB?
- call a function on
A?
that returnsB
you’d end up with
B?
in either caseSay you have these functions
toInt :: String -> Maybe Int double :: Int -> Int isValid :: Int -> Maybe Int
and you want to construct the following using these 3 functions
fn :: Maybe String -> Maybe Int
in a Rust-type syntax, you’d call
str?.toInt()?.double()?.isValid()
in Haskell you’d have two different operators here
str >>= toInt <&> double >>= isValid
however you can define this type class
class Chainable f a b fb where (?.) :: f a -> (a -> fb) -> f b instance Functor f => Chainable f a b b where (?.) = (<&>) instance Monad m => Chainable m a b (m b) where (?.) = (>>=)
and then get roughly the same syntax as rust without introducing a new language feature
str ?. toInt ?. double ?. isValid
though this is more general than just
Maybe
s (it works with any functor/monad), and maybe you wouldn’t want it to be. In that case you’d do thisclass Chainable a b fb where (?.) :: Maybe a -> (a -> fb) -> Maybe b instance Chainable a b b where (?.) = (<&>) instance Chainable a b (Maybe b) where (?.) = (>>=)
restricting it to only maybes could also theoretically help type inference.
I was thinking along the lines of “you can’t easily get at the wrapped type”. To get at
b
instead ofMaybe b
you need to either use do-notation or lambdas (which do-notation is supposed to eliminate because they’re awkward in a monadic context) whereas Rust will gladly hand you thatb
in the middle of an expression, and doesn’t force you to name the point.Or to give a concrete example,
if foo()? {...}
is rather awkward in Haskell, you end up writing things likefoo x y = bar >>= baz x y where baz x y True = x baz x y False = y
, though of course baz is completely generic and can be factored out. I think I called it “cap” in my Haskell days, for “consequent-alternative-predicate”.
Flattening Functors and Monads syntax-wise is neat but it’s not getting you all the way. But it’s the Haskell way: Instead of macros, use tons upon tons of trivial functions :)
- call a function on
You can say it’s half-arsed if you like, but it’s still vastly more convenient to write than if err != nil all over the place
Can anybody explain the rationale behind this?
Exceptions don’t exists and ask errors must be handled at every level. It’s infuriating.
I actually kind of like the error handling. Code should explain why something was a problem, not just where it was a problem. You get a huge string of “couldn’t foobar the baz: target baz was not greebleable: no greeble provider named fizzbuzz”, and while the strings are long as hell they are much better explanations for a problem than a stack trace is.
Hahaha, fuck no, I’ve dealt with exception-less code enough in my life, kthxbye
I think you missed a memo. Exceptions are bad and errors as values are in… I’ll have Harold forward it to you
deleted by creator
btw lua handles error in exactly the same way
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.
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.
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?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.I think that’s even worse because it increases the likelihood you’ll forget you faked that variable just for testing
Worse than not having a unused variable check at all? Dunno, the underscore assignment are very visible for me and stand out on every code read and review.
Yes, worse, because now if you want to use the underscore assignment to indicate that you really want to discard that variable - it gets confused with underscore assignments that were put there “temporarily” for experimentation purpose.
Exactly.
Say I’m having some issue with a function. I comment out half the function to see if that’s where the weirdness is. Golang says “unused variable, I refuse to compile this dogshit!” I completely fool Golang by just using
_ = foo
. Yes, I was correct, that’s where the problem was. I rewrite that section of the code, and test it out, things work perfectly. Only now, it turns out I’m not usingfoo
anymore, and Golang has no idea because I so cleverly fooled it with_ = foo
.Now, something that could be caught by a linter and expressed as a warning is missed by the language police entirely, and may make it into production code.
Police the code that people put into a repository / share with others. Don’t police the code that people just want to test on their own.
Ew, that’s awful. Go is not one of my programming languages but I had always held it in high esteem because Ken Thompson and Rob Pike were involved in it.
That’s the main reason it has had any success. It’s not that it’s a good language, it’s just that it has good references.
Honestly, it does not happen often that I have a ln unused variable that I want to keep. In my mind it is the same thing when wanting to call a function that does not exists. Also my editor is highlighting error Long before I try to compile, so this is fine too for me.
The underscore is used in production code too. It’s a legitimate way to tell the compiler to discard the object because you don’t intend to use the pointer/value.
Never really coded in Go outside of trying it out, but as far as I know it’s a hard error.
I think this is a good thing. The styles are just opinions anyway and forcing everyone to just follow a single style takes a lot of bikeshedding away, which I really like.
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 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.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.
Because you want to know if the first half of the code works at all before you write the whole second half.
Finding all the bits that will be used by the second half and changing the declarations to just expressions is a bunch of extra work. As is adding placeholder code to use the declared variables.
I’m having a hard time envisioning a situation where testing my code requires a bunch of unused variables. Just don’t declare the variables until you’ve started writing the code that uses them…
Most of the time you don’t write the code, you change it.
I had tons of situations where I wanted to test deleting a code block which just happened to use an imported library, which the compiler is now complaining about because it’s no longer being used.
If that’s the problem, then I would just use something like goimports to auto fix the imports every time I hit save. I never even see those errors so they don’t bother me.
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 🔓
🫡
I was working for a team that did quality control on the code of an entire financial group and it’s still amazing to me the shit we let through.
I feel annoyed even having compiler warnings in my code and here we were downgrading errors into warnings so the code would go through, or adding rules exceptions for a program so the team responsible could push a hotfix to prod… It’s all shit. All the way down.I dream of working with such a strict language.
I’ll start calling SQL “squeal” now in the spirit of this comment
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.
Java doesn’t have to declare every error at every level… Go is significantly more tedious and verbose than any other common language (for errors). I found it leads to less specific errors and errors handled at weird levels in the stack.
You know it’s social media when the one that’s right is downvoted
I’m with you, exceptions sound good but are a bug factory.
There’s nothing sane and readable about how Go insists you format dates and time. It is one of the dumbest language features I’ve ever seen.
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.
sure but unused variables are no biggie
You go Go!
lints that underline unused vars as errors, and not notes or warns are the worst lints…
This makes me not want to use Golang at all.
I assure you, the feeling is mutual.
You have to manually provide a seed every time you want a random number. Gophers will defend this with their dying breath.
This is not needed anymore since version 1.20
That’s good to hear, but I wouldn’t choose to use a language that took 5 years to get that right, when most languages have it from day 1.
So what language would you chose then? Java, PHP, JavaScript? None of the big languages where perfect from day one and it does not really matter, since day one is over already.
Yes, but I’d prefer incompetence rather than being deliberately anti-developer.
Okayyyy
you can assign it to itself and it’ll be just fine. can’t put a breakpoint right on it, but it works
I hate this in C++ when it does this with parameters of an overidden function. I don’t need that specific parameter, but if I omit the variable name, I reduce readability.
[[maybe_unused]]
Which is have been able to use since we switched to C++17 … a couple of months ago.
The best part of these threads is no matter what someone comments, at least 2 people will reply either correcting or “clarifying” the original commenter.
Lol
Me when my wife wants to buy new clothes (her clothes are the variables)
Isn’t it the same with ESLint 6 (JavaScript/ES6)?
Depends on your eslint config, but yeah that’s an option.
I don’t believe so.
Are you sure?
(this is my work pc so wayyy to much work to make a screenshot and upload it)
That’s from ESLint, not javascript itself. JS doesn’t care about unused variables
JS simply does not care.
That’s why I said ESLint
ESLint won’t prevent you from running your code, which is what the OP is on about. Hence the confusion in this thread.
Oh it will. At least in combination with Vue. At least that’s the default. Of cause you can disable it.
You’re describing many things that are not JavaScript the language. If you create and use tools that will stop you then yes they will stop you.