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.

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.

Having a Result[T, Err] monad that could represent either the data from a successful operation or an error. This can be generalised to the Either[A, B] monad too.

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 instead

in 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 the Left/error case, if any of the Eithers end up being a Left value then it’ll correctly “short-circuit” and the function will evaluate to that Left 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

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 returns B?
• call a function on A? that returns B

you’d end up with B? in either case

Say 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 Maybes (it works with any functor/monad), and maybe you wouldn’t want it to be. In that case you’d do this

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

It’s not a half-arsed copy, it’s borrowing a limited subset of HKT for a language with very different goals. Haskell can afford a lot of luxuries that Rust can’t.

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

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

Too many patterns. If you do not do this every author will have a different use of the language and you will have to read a book of documentation each time you change files.

I think that’s even worse because it increases the likelihood you’ll forget you faked that variable just for testing

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.

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.

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.

Beyond a quick “hello world” when it came out, I’ve never used rust, but that sounds pretty great

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.

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.

I will need it two minutes tops. If I don’t use it by then, I’ll delete it, especially if it gives a warning like Rust does. But this? It just gets in the way.

Have you looked at the post? Use case: you are testing something or playing around and you want to try something. That’s supper common

I have a use case in Powershell: my company has a number of scripts that are minimally but importantly customized per-location, and I have an otherwise unused “SiteId” variable where I keep the location name for that specific script for a quick sanity check when I’m looking them over for any reason. Not necessary, but useful to me. Probably wouldn’t do the same thing in a compiled program, but I can at least see where someone might want something similar.

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.

Wait… how do you say it? es queue el?

sure but unused variables are no biggie

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.