I'm not impressed by the careless tossing around of the word "easily" in this thread.

It's quite ridiculous that you're claiming errors can be easily left unhandled while referring to what, a single unfortunate pattern of code that will only realistically happen due to copy-pasting and gets you code that looks obviously wrong? Sigh.

Okay let's dissect that.

"Easily" doesn't mean "it happens all the time" in this context (e.g. PHP, at least in the olden days).

"Easily" here means that WHEN it happens, it is not usually obvious. That is my experience as a daily go user. It's not the result of copy-pasting, it's just the result of editing code. Real-life code is not a beautiful succession of `op1, op2, op3...`. You have conditions in between, you have for loops that you don't want to exit in some cases (but aggregate errors), you have times where handling an error means not returning it but doing something else, you have retries...

I don't use rust at work, but enough in hobby/OSS work to say that when an error is not handled, it sticks out much more. To get back on topic of succinctness: you can obviously swallow errors in rust, but then you need to be juggling error vars, so this immediately catches the eye. In go, you are juggling error vars all the time, so you need to sift through the whole thing every goddamn time.

> Debugging means grepping that string in the codebase, and praying that it's unique.

This really isn't an issue in practice. The only case where an error wouldn't uniquely identify its call stack is if you were to use the exact same context string within the same function (and also your callees did the same). I've never encountered such a case.

> You are also not forced to add context

Yes, but in my experience Go devs do. Probably because they're having to go to the effort of typing `if err != nil` anyway, and frankly Go code with bare:

    if err != nil {
        return err
    }

sticks out like a sore thumb to any experienced Go dev.

> which even linters won't pick up, due to asinine variable syntax rules.

I have never encountered a case where errcheck failed to detect an unhandled error, but I'd be curious to hear an example.

The go stdlib notoriously returns errors without wrapping. I think it has been shifting towards more wrapping more often, but still.

    err1 := foo()
    err2 := bar()
    if err1 != nil || err2 != nil {
        return err1  // if only err2 failed, returns nil!
    }

``` func process() error { err := foo() if err != nil { return err }

    if something {
        result, err := bar()  // new err shadows outer err
        if err != nil {
            return err
        }
        use(result)
    }
    
    if somethingElse {
        err := baz()  // another shadow
        log.Println(err)
    }
    
    return err  // returns foo's err (nil), baz's error lost

} ```

Now all you have to do is get a Go programmer to write code like this:

    if somethingElse {
        err := baz()  
        log.Println(err)
    }

Good luck!

As for your first example,

    // if only err2 failed, returns nil!

Yes, that's an accurate description of what the code you wrote does. Like, what? Whatever point you're trying to make still hinges on somebody writing code like that, and nobody who writes Go would.

Now, can this result in bugs in real life? Sure, and it has. Is it a big deal to get a bug once in a blue moon due to this? No, not really.