Go Analysis Framework: modular static analysis by go team

No, making error handling verbose mandatory is meant to make developers do mental cardio and be mindful of what they are doing.

You can either keep developers mindful or punish them after they make a mistake by shouting at them and make them waste their time during re-compiling.

P.S.: Yes, I love Go's error handling mechanics, which makes handling errors mandatory, not optional, and if you ignore the error, this is a deliberate choice and the burden is on the developer. Go does the former, Rust does the latter.

Also, if error wrapping hurts you so much (I don't use it), just implement a project-specific error that works how you want. This could be something that is JSON serializable, that captures a line number at each return site, etc. It will take like 10 minutes to get your project's errors working exactly how you want.

My projects usually do -

    log.SetFlags(log.LstdFlags | log.Lshortfile)
    // ...
    if err != nil {
        log.Println(err)
        return errors.New("Error doing the thing.")
    }

2.That error handling is one of the best features. It makes me explicitly acknowledge the errors instead of letting them just happen. No error goes unnoticed!

Each if err != nil is an explicit reminder to check, do I need to clean up? Do I need to log this error to a file?

"And no more oh an error happened I wonder where"

With LLMs verbosity is not an excuse anymore. Just generate it and focus on other things then

    found := false
    for _, v := range s {
        if v == needle {
            found = true
            break
        }
    }

If you'd used `slices.Contains(s, needle)`, on the other hand, it could have such a performance bug in it and you'd never know.

While the first occupies more lines I suspect I’d spend less time spotting it in the code. The physical shape of the expression is something my brain is used to seeing after 40 years of programming. Even when code grows more complex.

The second is OK when it stands alone, but I am not so certain it would be as easy to spot in more complex surroundings. Even on a single line, there is something a bit ugly about the code. Even before we get to the desperate triple-pipe. That kind of reminds me of the desperate attempts at repairing JS after they realized its equality semantics were shot. Just heap more characters on it.

The thing is: it is actually very hard to judge how ergonomic a language is by just looking at it. You have to use it and you have to use it enough to realize where the paint points really are. I’ve read through a lot of the responses in this discussion and I’ll be honest: I think a lot of people who criticize other languages (be they Rust, C, Go or whatever) aren’t very fluent in them. It takes a couple of years to develop fluency.

foo := thinger()

_ = foo # no longer unused

Which is a great way to make sure they're not overused, which in my experience is better than underuse.