The draft design document that all of the feedback is based on mentions C++, Rust, and Swift. In the extensive feedback document you link above I could not find mention of do-notation/for-comprehensions/monadic-let as used Haskell/Scala/OCaml. I didn't find anything like that in the first few pages of the most commented GitHub issues.

You make it out like the Go Team are programming language design wizards and people here are breezily proposing solutions that they must have considered but lets not forget that the Go team made the same blunder made by Java (static typing with no parametric polymorphism) which lies at the root of this error handling problem, to which they are throwing up their hands and not fixing.

It fascinates me that really smart and experienced people have written that page and debated approaches for many years, and yet nowhere on that page is the Haskell-solution mentioned, which is the Maybe and Either monads, including their do-notation using the bind operator. Sounds fancy, intimidating even, but is a very elegant and functionally pure way of just propagating an error to where it can be handled, at the same time ensuring it's not forgotten.

This is so entrenched into everybody writing Haskell code, that I really can't comprehend why that was not considered. Surely there must be somebody in the Go community knowing about it and perhaps appreciating it as well? Even if we leave out everybody too intimidated by the supposed academic-ness of Haskell and even avoiding any religios arguments.

I really appreciate the link to this page, and overall its existence, but this really leaves me confused how people caring so much about their language can skip over such well-established solutions.

It's probably already answered somewhere, but I am curious why it's such a problem in Go specifically, when nearly every language has something better - various different approaches ... is the problem just not being able to decide / please everyone, or there's something specific about Go the language that means everyone else's solutions don't work somehow?

This is a common theme with criticisms of Go.

Relative amateurs assuming that the people who work on Go know less about programming languages than themselves, when in almost all cases they know infinitely more.

The amateur naively assumes that whichever language packs in the most features is the best, especially if it includes their personal favorites.

The way an amateur getting into knife making might look at a Japanese chef's knife and find it lacking. And think they could make an even better one with a 3D printed handle that includes finger grooves, a hidden compartment, a lighter, and a Bluetooth speaker.

The problem is that error handling is far more complex than you think at first.

The idea that "the happy path is the most common" is a total lie.

    a + b

So, errors are everywhere. And you must commit to a way to handle it and no is not possible, like no, not possible to satisfy all the competing ideas about it.

So there is not viable to ask the community about it, because:

    a + b

So, you pick a side and that is.

that is weird that they call it a Wiki when it is not a wiki any more - you have to submit changes for approval

"despite multiple complete perfect proposals on how to do it"

There is no such a thing.

and this is how rust gains its reputation as an ugly to read language with inconsistent syntax: design by committee

Programming languages are designed systems, they need to make sense holistically. They're not simply collections of tick-boxed features that are expected to be added once their tick-box requirements are satisfied.

> Go cannot solve the single problem everyone immediately has with the language...

What? Survey says 13% mentioned error handling.

And some people actually do prefer it as is.

https://go.dev/blog/survey2024-h1-results

!RemindMe in 25 years.

Did Rust become a clusterfuck like C++?

Is Go as timeless as it was during release?

> complete perfect

This is entirely subjective and paints the Go community as being paradoxical, simultaneously obstinate and wanting change.

The disappointing reality is that Go's error handling is the least terrible option in satisfying the language design ethos and developers writing Go. I have a penchant for implementing V's style of error handling, though I understand why actually implementing it wouldn't be all sunshine and rainbows.

If Haskell was mainstream and everyone piled in and complained that objects were immutable and it adds so much noise having to deal with that using lenses or state monads or whatever, do we go with democracy or do we say wait.... maybe Haskell was meant to be like this, there are reasons something is a seperate language.

Any time I write "if err == nil" I write // inverted just to make it stick out. It would be nice if it was handled by the language but just wanted to share a way to at least make it a bit more visible.

    if err == nil { // inverted
        return err
    }

Of course, `if fruit != "Apple" { ... }` would leave you in the exact same situation. Is there a general solution to improving upon this? Seeing it as an error problem exclusively seems rather misguided. After all, there is nothing special or unique about errors. They're just state like any other.

This is actually an argument against the syntactic changes. Because now if you have the common `if err == nil { return ... }` pattern, then you have _that_ "littering" your code, instead of the syntax.

The current solution is fine, and it seems to be only junior/new to golang people who hate it.

Everyone I know loves the explicit, clear, easy to read "verbose" error handling.

Just as a devil's-advocate argument, an IDE + font could syntax-highlight + ligature `if err != nil` (only under Golang syntax mode) into a single compact heiroglyph and fade it into the background — which would in turn make anything that differs from that exact string (like `if err == nil`) now pop out, due to not being rendered that way.

Good point. Perhaps it could also be solved in an editor with a collapsed notation like ‘if err … {‘

I like nil == err for this case

Nothingburger here, you had a bug, and you fixed it.

All is well, no need to question your language or the meaning of life.

When you make a mistake irl or trip over when walking, do you reconsider you DNA and submit a patch to God?

Sometimes you just gotta have faith in the language and assume it like an axiom, to avoid wasting energy fighting windmills.

I'm not a deep Go programmer, but I really enjoy how it's highly resistant to change and consistent across it's 15 years so far.

My experience with errors is that error handling policy should be delegated to the caller. Low level parts of the stack shouldn't be handling errors; they generally don't know what to do.

A policy of handling errors usually ends up turning into a policy of wrapping errors and returning them up the stack instead. A lot of busywork.

> If a function fails, then you need to handle its failure

And this is exactly where Go fails, because it allows you to completely ignore the error, which will lead to a crash.

I'm a bit baffled that you correctly identified that this is a requirement to produce robust software and yet, you like Go's error handling approach...

I just want borgo[1] syntax to be the Go 2 language. A man can dream...

[1]: https://borgo-lang.github.io/ | https://github.com/borgo-lang/borgo

I have to ask, in comparison to what do you like it? Because every functional language, many modern languages like Rust, and even Java with checked exceptions offers this.

Hell, you can mostly replicate Gos "error handling" in any language with generics and probably end up with nicer code.

If your answer is "JavaScript" or "Python", well, that's the common pattern.

At this rate, I suspect Go2 is an ideas lab for what's never shipping.

This is just sad. Neither of your supports have anything to do with how dismal Go's error handling is, and neither would be worsened in any way by making it better. If anything they would be improved.

Even PHP has better error handling with the levels, and the @ (at operator) to suppress errors at a callsite.

Even bash has -e :)

Me too. I'll take the higher Loc for the greater certainty of what is going on.

I thought it was clever in C# years ago when I first used to to grok all the try/catch/finally flows including using and nested versions and what happens if an error happens in the catch and what if it happens in the finally and so on. But now I'd rather just not think about that stuff.

rust-style "sum type" errors are values too

90% of working professionally in Go is contriving test cases to achieve statement coverage over each error return branch, something no one would ever do in a language with exceptions.

> I really don't like how this article claims that the primary issue with Go's error handling is that the syntax is too verbose.

I don't believe this claim is made anywhere.

We've decided that we are not going to make any further attempts to change the syntax of error handling in the foreseeable future. That frees up attention to consider other issues (with errors or otherwise).

Just remember it took FOREVER for Go to support some form of generics. Go evolution happens at a glacial pace. That's a feature, not a bug....to many.

I agree with item #1, but it can be mitigated somewhat with dev tools like errcheck: https://github.com/kisielk/errcheck?tab=readme-ov-file

Agreed, 100%.

We're both Googlers here and this is so disappointing to be let down again by the Go team.

It's funny to me when people see screenfuls of stack traces and remark how clear and useful it is. Perhaps, but do you really need all that? At what cost to your logs? I'd much rather have a one-liner wrapped error that cuts through all the framework and runtime noise. Yes, I can trace just as effectively (usually better)--the wrapping is very greppable when done well. No, in over a decade of writing Go full time, I have never cared about a runtime function or the other usual verbose garbage in my call stack.

From all available evidence, there is no chance in hell Go could adopt a `with` statement.

Go is fascinating in how long it holds out on some of the most basic, obviously valuable constructs (generics, error handling, package management) because The Community cannot agree.

- Generics took 13 years from the open source release.

- 16 years in there isn’t error handling.

- Package management took about 9 years.

There’s value to deliberation and there’s value to shipping. My guess is that the people writing 900 GH comments would still write Go and be better off by the language having something vs. kicking the can down the road.

Go's multiple return is in itself insane from my perspective. You cannot 'do' anything with a function that has multiple return types except assign them to a variable.

Haskellers and Rust fans think they own sum types, and people read their comments and blog posts and believe them, and decide they don't want sum types because they don't want to go down the horrifying Hindley-Milner rabbit hole.

But meanwhile it's just perfectly idiomatic Erlang and Elixir, none of that baggage required. (In fact, the sum types are vastly more powerful than in the ML lineage - they're open.)

Go can’t have Result because they don’t have sum types, and they can’t add them because of their bizarre insistence that every type has to have a designated zero value.

> But I fail to see how having convenience equates to ignoring the error.

The convenience of writing `?` means nobody will bother wrapping errors anymore. Is what I understand of this extremely dubious argument.

Since you could just design your `?` to encourage wrapping instead.

> I dont see why the Rust style isnt just adopted.

Mostly because it is not entirely clear what the Rust-style equivalent in Go might be. What would Rust's "From" look like, for example?

- It has poor visibility, it hides control flow branches in a single statement / expression. That's one of the reasons Go got rid of the ternary operator in favor of an if statement where each branch has to be on its own line.

- It isn't easily breakpointable.

- It favors "bubbling up" as-is over enriching or handling.

Wait...

  x, err := strconv.Atoi("123")
  if err != nil {
    panic(err)
  }
  y, err := strconv.Atoi("1234")
  fmt.Println("result:", x, y)

Okay, I don't use golang... but I thought ":=" was "single statement declare-and-assign".

Is it not redeclaring "err" in your example on line 5, and therefore the new "err" variable (that would shadow the old err variable) should be considered unused and fail with 'declared and not used: err'

Or does := just do vanilla assignment if the variable already exists?

> Its the thing I immediately add now that I have generics in Go.

If you’re willing to share, I’m very curious to see a code example of what you mean by this.

I’m surprised I don’t see this mentioned more. This is spooky action at a distance at its worst. And it’s not even limited to error handling. Any multi value assignment works like this.

It's fairly obvious when writing Go that `err` is being shadowed and needs to be checked after each expression. You should be wrapping them anyways!

I would be astonished if there isn't an automated tool to check for that at the push of a button. I would be mildly surprised if there isn't a compiler flag to check for it.

I don't think in real code you generally want to return "err" directly, but add some kind of context to made debugging easier. Its the same problem Rusts `?` has.

How do you do that with this suggestion?

I absolutely agree with this, and would be better than all of the other proposals.

Did anyone propose this in one of the many error handling proposals?

> they could have something like this:

Could in some purely theoretical way, but this is pretty much exactly the same, minor syntax differences aside, as virtually every other failed proposal that has been made around this. It would be useless in practice.

In the real world it would have to look more like this...

    func printSum(a, b string) result[error, unit] {
        return for {
            x <- strconv.Atoi(a) else (err error) {
                details := collectDetails(a, b)
                stop firstConvError{err, details}
            }
            y <- strconv.Atoi(b) else (err error) {
                stop secondConvError{err}
            }
        } yield fmt.Println("result:", x + y)
    }

   func printSum(a, b string) result[error, unit] {
        return for {
            x <- strconv.Atoi(a)
            y <- strconv.Atoi(b)
        } yield fmt.Println("result:", x + y)
    }

    handle(printSum, "x", func(vars map[string]any, err error) {
        details := collectDetails(vars["a"].(string), vars["b"].(string))
        return firstConvError{err, details}
    }

    handle(printSum, "y", func(vars map[string]any, err error) {
        return secondConvError{err}
    }

Once you start dealing with the realities of the real world, it is not clear how your approach is any better. It is pretty much exactly the same as what we have now. In fact, it is arguably worse as the different syntax doesn't add anything except unnecessary complexity and confusion. Which is largely the same reason why all those aforementioned proposals failed. Like the linked article states, syntax is not the problem. The problem is that nobody to date knows how to solve it conceptually without completely changing the fundamentals of the language or just doing what you did, which is pointless.

And there is another obvious problem with your code: result[error, unit], while perfectly fitting in other languages designed with that idea in mind, is logically incorrect in the context of Go. They are not dependent variables. It doesn't make sense to make them dependent. For it to make sense, you would, as before, have to completely change the fundamentals of the language. And at that point you have a band new language, making any discussion about Go moot. That said, I think the rest of your idea could be reasonably grafted onto the (T, error) idiom just as easily. However, it still fails on other problems, so...

[1] Which, I will add, is not just speculation. The Go team actually collected data about this as part of their due diligence. One of the earlier proposals was on the cusp of acceptance, but in the end it wasn't clear who – outside of contrived HN comments – would ever use it due to the limitations spoken of above, thus it ultimately was rejected on that basis.

I have 2 problems.

It's too easy to accidentally write `if err == nil` instead of `if err != nil`. I have even seen LLMs erroneously generate the first instead of the latter. And since it's such a tiny difference and the code is riddled with `if err != nil`, it's hard to catch at review time.

Second, you're not forced by the language to do anything with the error at all. There are cases where `err` is used in a function that not handling the `err` return value from a specific function silently compiles. E.g.

    x, err := strconv.Atoi(s1)
     if err != nil {
      panic(err)
     }
     y, err := strconv.Atoi(s2)

    fmt.Println(x, y)

> It’s opt-in like generics, so I don’t see why it would be controversial to anyone?

It "breaks" the language in fundamental ways — much more fundamental than syntactic sugar for error handling — by making zero values and thus zero initialisation invalid.

You even get this as a fun interaction with generics:

    func Zero[T any]() T {
        var v T
        return v
    }

Small nitpick: panic/recover and error handling are orthogonal. Exceptions != errors.

> there is literally nothing you can do with errors in go except bubble them up, log them, or swallow them

You can also add additional context to the error before bubbling it up. But yes, that part of the point. Instead of bubbling them up, the programmer should instead reflect on whether it is better than just log and proceed, or completely swallow them. This is what error handling is about.

I assume you mean languages with exceptions.

You can't bubble up an exception, it's done automatically. That's a very important distinction. You can't make the decision to bubble up or not, because you do not have the required information - you don't know whether an exception can be thrown or not at any point. Therefore, you can't say you're making a decision at all.

Explicit error allows you to be able to make the decision.

I mean, yeah, most of the time what you do is add more text and bubble up. But:

1. The very fact that adding more text isn't really any more verbose than not encourages you to add more text, making errors more informative.

2. A non-negligible amount of times you do something else: carry on, or do something specific based on what kind of error it was. For instance, ignore an error if it's in a certain class; or create the file if it didn't exist; and so on.

Forcing the error handling doesn't seem to me that different than forcing you to explicitly cast between (say) int and int64. Part of me is annoyed with that too, but then I have PTSD flashbacks from 20 years of C programming and appreciate it.

The "Error Return Trace" described in the next section down also seems like an interesting alternative to a stack trace, possibly solving the same problem with less noise.

How well does it work in practice?

Zig 'error types' are a sum type, while Go ones are just values.

And even then this is just the same as the '?' operator Rust uses, which is mentioned in the post.

How do you feel about

    v, err := foo.Open()
    // …
    defer func() {
        if closeErr := v.Close(); closeErr != nil {
            err = fmt.Errorf("while closing %w: %v", err, closeErr)
        }
    }() 
  
    // …

FWIW I love Go, it’s my daily driver for most things. I still think it can get messy far too quickly

Error handling is the thing I hate the most about go. And none of the serious proposals I've seen would remove your ability to continue using `if err != nil`

You don't use gofmt?

You probably wouldn't have had the bad/mysterious error messages in production if they were just stack traces to begin with.

It does, it says which one of the two integers was incorrect

> Adapt or die

It's not my impression Go is dying. Seems rather overblown.

And this "but $other_lang has it! You must have it! Adapt or die!" type of reasoning is how you end up with C++.

Changing too quickly is a much bigger problem. It may not be ideal, but I think leaning towards being slow makes sense in this context.

Every person/company using Go chose to use it knowing how errors are handled.

Each new way of error handling seems to upset a large number of users, some of which may not have chosen Go had the newer system been in place originally.

If it is impossible to know which choice is correct, at least everyone has some baseline level of acceptance for the status quo.

Go adoption has only increased over time.

In this particular case the argument seems to be that there is not even consensus improvement is NEEDED. If you cant even agree on that then how do ever hope to agree to a change in the general sense.

You actually don't. In mistakes #52 "Handling an error twice" from the book "100 Go Mistakes and How to Avoid Them" by Teiva Harsanyi, the recommendation is to either return an error to the caller or handle the situation (and maybe logging it). Sometimes you wnat some extra information as to why it's an error, so you wrap it.

Go forces you to be explicit about error handling. Java syntax is not that much better. JavaScript, Kotlin, Swift,... is more about avoiding null pointer exception than proper error handling.

"biggest challenge", it's not multiple choice

The rub there is that you'll have varying styles in which error handling statements appear in your code. With simplistic instances appearing one way and less simplistic ones appearing similarly or differently depending on where each lands on the complexity spectrum. The idiomatic approach is for all instances to be written in the same way regardless of technical nuances.

All of that aside, I've come to learn that passing errors up the call stack without any wrapping or handling is a code smell. It is less than useless for me to attempt setting the value of cell A1 in an Excel sheet to "Foo" and then receive an out-of-range error because the developer made no attempt to even inform me of the context around the error. Let alone handling the error and attempting to correct state before giving up.

In my Excel example, the cause of the error was a data validation problem a couple columns over (F or so). The error was legitimately useless in troubleshooting.

How would you set a breakpoint on the error return case?

What if I wrap the error? Should that be squashed to one line? What is the heuristic?

This is a very good way to fight back against design by committee.

It could be seen as a big waste of time, but it sets a good precedent.

The proposals are not backwards incompatible. And just because you get used to something doesn't mean it is good.

And FWIW, my hatred of go error handling has not diminished with increased usage.

> I like the explicit error handling

You mean "verbose error handling". All other proposals are also explicit, just not as verbose.

I think that IDE functionality is fine for writing code, but shouldn’t be imposed for the UX of reading code, because code reading also happens a lot outside of IDEs, because it constrains the choice of editors, and because it creates fundamentally different “modes” of source code presentation. The visualizations will start to appear in comment threads like this one, and in other publications on the web, but copying them and pasting them into an editor will not work (will be invalid syntax). It creates unnecessary complications across the whole ecosystem. Language syntax should stand on its own, and shouldn’t need crutches like that to make it ergonomic to read.

I would simplify that to

  x = foo() ||| <error case>
  <happy case>

That is shorter and keeps the happy path unindented, even if it has additional such constructs, for example

  x = foo() ||| return Error(err, “foo failed”)
  y = bar() ||| return Error(err, “bar failed”)

This also grinds my gears when converting multiple-return functions to returns-a-channel functions. Generics help with that now.

> Rust's result type is just syntactic sugar around the multiple return value approach

That's really not true. Multiple return values means you always need to return some return value and some error value, even if they are dummy values (like nil). While a result type / sum type genuinely only contains one branch, not the other.

If you had a language that didn't have nil, it would genuinely be impossible to emulate sum type like behavior on top of multiple return values. It serves as an escape hatch, to create a value of some type when you don't actually have a meaningful value to give.

std::variant / std::expected / std::optional aren't syntactic sugar for std::pair either.

> And that may be the real truth of it: Error handling in Go just isn't ... that much of a problem to force action?

I you are right that this is the truth of it. Error handling just isn’t that big a problem. 13% reported it on the survey cited. That doesn’t seem that significant. And honestly, after writing Go, I barely notice error handling as I’m writing/reading code anyway. If anything I appreciate it a bit more than exceptions.

Always something that can be complained about. But it doesn’t mean every complaint is a huge deal.

This is also my feeling. And I wouldn't even have minded the ? syntax.

It seems that now that Ian's left the rest of the Go team is just being honest about what they are willing to spend their time on.

And I'm more than fine with that, because look at this comment section. You can't please everybody.

> generics debacle

Why debacle?

The proposals aren't reinventing exceptions. They are just making more ergonomic syntax for doing the same thing go error handling does today.

Rust is basically someone looking at ML languages and thinking what if we did that but just worse in every way.

> Unfortunately, as with the other error handling ideas, this new proposal was also quickly overrun with comments and many suggestions for minor tweaks, often based on individual preferences. Ian closed the proposal and moved the content into a discussion to facilitate the conversation and to collect further feedback. A slightly modified version was received a bit more positively but broad support remained elusive.

> After so many years of trying, with three full-fledged proposals by the Go team and literally hundreds (!) of community proposals, most of them variations on a theme, all of which failed to attract sufficient (let alone overwhelming) support, the question we now face is: how to proceed? Should we proceed at all?

> We think not.

You need to assign the error to a variable, probably. So it would have to be more something like:

  n := strconv.Atoi(s) or |err| {
      return fmt.Errorf("foo: %w", err)
  }

  n := strconv.Atoi(s) or |err| {
      if !errors.Is(err, pkg.ErrFoo)
          return fmt.Errorf("foo: %w", err)
      }
  }

I'm just making up syntax here to illustrate the point; doesn't look too brilliant to me. A func might be a bit more "Go-like":

  n := strconv.Atoi(s) or func(n int, err error) {
      return fmt.Errorf("foo: %w", err)
  }

Seems like it's only worth the cost of the change if it removes all three verbose lines per check, this only removes one.

If you do this, returning the error last is now part of the language rather than a convention. You’d be making a pretty large language change.. and for what? One line of code that’s already folded away by any modern editor?

Oh cool, you've reinvented perl.

It's a pale shadow of an actual Option/Result type, though, and the way most community and professional Elixir code uses ok-tuples is hardly what I would call rigorous. The with special form leads to sloppy pass-the-buck design IME, and nothing in the language design or Credo ruleset is likely to steer anyone to do better.

Writing it was never the problem if you're using proper tools, e.g. an actual IDE (IDEA does fine), or at least a snippet manager for your text editor. Inserting a wrapping error handling snippet requires two key presses.

It's reviewing mountains of that crap that's the problem, especially if there are non-trivial cases hidden in there, like returning the error when `err == nil` (mentioned by others in this thread).

You're getting downvoted, but this was what tptacek basically wrote about. Key points from his blog are that LLMs are good at tedium, and Go's structure is highly repetitive and amenable to LLM generation. The error handling tedium is probably part of why it's highly repetitive.

> I work mostly in Go. I’m confident the designers of the Go programming language didn’t set out to produce the most LLM-legible language in the industry. They succeeded nonetheless Go has just enough type safety, an extensive standard library, and a culture that prizes (often repetitive) idiom. LLMs kick ass generating it.

https://news.ycombinator.com/item?id=44163063 - 2386 comments

You would have to infer the intent of the code. One example, from a small project I'm working on:

    $ find . -name "*.go" | xargs grep 'if err !=' | wc -l   
     242
    $ find . -name "*.go" | xargs grep 'if err ==' | wc -l
      12

If you discard that as "error handling noise", you're in for a bug. Which is, by the way, perhaps the worst side-effect of verbose, repetitive error handling.

Apropos syntax highlighting: many themes in regular use (certainly most of the defaults) choose a low-contrast color for the comments. The comments are often the most important part of the code.

Goland folds it visually partially https://github.com/golang/vscode-go/issues/2311

I would love something like this, and if it exists, I've not come across it. Offloading a way of differentiating error handling syntax vs. normal code to the IDE seems like a nice way of handling this issue.

To take this analysis another level deeper: what has happened here is a classic example of bikeshedding — and, worse, fostering bikeshedding.

Everyone feels equipped to have an opinion about "what should be the syntax for an obvious bit of semantics." There's no expertise required to form such an opinion. And so there are as many opinions on offer as there are Go developers to give them.

Limit input on the subject to just e.g. the people capable of implementing the feature into the Go compiler, though, and a consensus would be reached quickly. Unlike drive-by opinion-havers, the language maintainers — people who have to actually continue to work with one-another (i.e. negotiate in an indefinite iterated prisoner's dilemma about how other language minutiae will work), are much more willing to give ground "this time" to just move on and get it working.

(Tangent: this "giving ground to get ground later" is commonly called "horse trading", but IMHO that paints it in a too-negative light. Horse trading is often the only reason anything gets done at all!)

> I love inaction as a default decision

The thing is, inaction is not simply "not taking an action"; Inaction is taking active action of accepting the current solution.

> I doubt that the best proposals are so horrible for some people that they’d hold a grudge and leave Go.

But people may leave go if they constantly avoid fixing any of problems with the language. The more time passes, the more unhappy people become with the language. It will be a death by a thousand cuts.

I love go. But their constant denial do fix obvious problems is tiring.

The article seems to admit that a `try` keyword restricted to statements / assignments only would combine the best parts and alleviate the major concerns of both the `try` and `?` proposals. It reads as though the concept has not been seriously discussed due simply to exhaustion.

Yeah this bugs me about the decision process too, but Go places more importance on backwards compatibility and stability than most other languages so it does align with their values. I'm not the biggest fan of Go but its nice having a language around that favors simplicity and stability.

> I love inaction as a default decision, but sometimes a decision is better than nothing. It reminds me of a groups when you can’t decide what to have for dinner – the best course of action isn’t to not eat at all, it’s to accept that everyone won’t be happy all the time, and take ownership of that unhappiness, if necessary, during the brief period of time when some people are upset.

Invalid comparison - eating one foodstuff or another affects a few people for a few hours. Significantly changing a popular language affects every single user of it forever.

> sometimes a decision is better than nothing

Not in this case. The most popular Go proposal/issue of all times was 'leave "if err != nil" alone': https://github.com/golang/go/issues?q=is%3Aissue%20%20sort%3...

It's true that Google is "design by committee" and consensus driven, but the Go team has been particularly obtuse about things, seemingly not understanding which opinions are valid and which are confused.

I'd happily come up with criticisms of any specific proposal and bikeshed it, but any one of these proposals would be preferable to the status quo.

I'd understand if they decided they needed more time to continue iterating on and analyzing proposals to find the right solution, but simply declaring that they'll just suspend the whole effort because they can't come to a consensus is rather infuriating.

Sometimes doing nothing is the right thing to do. (Quote from Until Dawn)

Go chose not to change the error handling - Nature remained in balance.

> They know from developer surveys that verbose and repetitive error handling is literally the number 1 issue.

Agreement on a problem does not imply agreement on a solution.

It's not about perfection. It's about not having a solution that gets anywhere near a majority approval.

Let's say your neighborhood has an empty plot of land owned by the city that is currently a pile of broken chunks of concrete, trash, and tangled wire. It's easy to imagine that there is unanimous agreement by everyone in the neighborhood that something better should be placed there.

But the parents want a playground, the pet owners want a dog park, the homeless advocates want a shelter, the nature lovers want a forest, etc. None of them will agree to spend their tax dollars on a solution that is useless to them, so no solution wins even though they all want the problem solved.

> They know from developer surveys that verbose and repetitive error handling is literally the number 1 issue.

According to 13% of respondents. So yes, it's the "#1 issue", but also not by a huge overwhelming majority or anything.

Python is a bit of a counter-example these days. I think they're in a good place right now, but it's hard to argue they've stuck to the premise of "There should be one-- and preferably only one --obvious way to do it."

- I need to do string interpolation: am I using f-strings or `string.format` or the modulo operator?

- I need to do something in a loop. Well, I can do that. But I could also just do a list or sequence comprehension... Or I could get fancy and combine the two!

And such and so-on, but these are the top examples.

Changing these things strictly adds cognitive load because you will eventually encounter libraries that use the other pattern if you're familiar with the one pattern. And at the limit of what this can do to a language, you get C++, where the spec exceeds the length of the Bible and many bits of it create undefined behavior when used together.

I think Go's project owners are very justifiably paranoid about the consequences of opening the Pandora's box on new features, even if it means users have to deal with some line-noise in the code.

Yeah, this is the single biggest reason I avoid go - I just don't want to clutter my "happy path" logic. It makes things harder to reason about.

"Errors are values", sure. Numbers are values and Lists are values. I use them differently, though.

I wonder if there could be "stupid" preprocessing step where I could unclutter go code, where you'd make a new token like "?=", that got replaced before compile time. For instance, "x ?= function.call();" would expand to "x, err := function.call(); if (err != nil) return err;"

> ...having only 2 when it comes to error handling does not seem like a big deal. I imagine people will just use their preference...

I foresee endless PR arguments about whether err != nil is the best practice or whatever alternative exists. Back-and-forth based on preference, PRs getting blocked since someone is using the "other" style, etc. Finally the org is tired of all this arguing and demands everyone settle on the one true style (which doesn't exist), and forces everyone to use that style. That is where the "forced to use it" comes from.

From the early days, Go has taken principled stands on matters like this, striving for simplicity and one way to do something. For example, `go fmt` cut through all the tabs vs. space nonsense by edict. "Gofmt's style is no one's favorite, yet gofmt is everyone's favorite."

> I don't really understand this decision.

The decision is disappointing, but understandable.

The blog post attempted to explain it, but it comes down to: A lot of energy has been expended without the community and the core team reaching any form of consensus. The current error handling mechanism has entrenched itself as idiomatic for a very long time now. And since the promising ones among the various proposals involve language changes, the core team, which is stretched already, isn't willing to commit to it at this time, especially given the impact.

The language was first designed without consensus and then released. It was used anyways.

But now a sort of democracy is required for changes. I’m not sure this is necessary.

people that answer surveys don't represent all Go developers, many of us are fine with the error status quo

This doesn't actually makes the process simpler.

Error handling in Go is not just writing "if err != nil { return nil, err }" for every line. You are supposed to enrich the error to add more context to it. For example:

    result, err := addTwoNumbers(a, b)
    if err != nil {
      return fmt.Errorf("addTwoNumbers(%d, %d) = %v", a, b, err)
    }

Not to mention, those helper functions don't account for cases where you don't just want to bubble up an error. What if you want to do more things, like log, emit metrics, clean up resources, and so on? How do you deal with that with the "Handle()" function?

Yeah once you've been using it long enough for the Stockholm syndrome to set in, you come to terms with the hostile parts of the language.

This, it’s always the new people complaining about error handling.

I have many things to complain about for other languages that I’m sure are top-tier complaints too

I have a similar level of experience with Go, and I would go so far as to say it is in fact one of the best features of the language.

I wouldn’t be surprised that when the pro-exception-handling crowd eventually wins, it will lead to hard forks and severe fragmentation of the entire ecosystem.

That's just survivorship bias isn't it? The newcomers who find Go's design and/or leadership obnoxious get a job that doesn't involve doing something that they dislike.

They clearly are wrestling with these issues, which to me seems like taking the feedback seriously. Taking feedback seriously doesn’t imply you have to say yes to every request. That just gives you a design-by-committee junk drawer language. We already have enough of those, so personally I’m glad the Go team sticks to its guns and says no most of the time.

I don't know that there's whining about "having to handle errors" in principle, it's pretty clearly a complaint with the syntax and semantics of doing so

Some languages even make omitting error handling impossible! (e.g. Result sum types). None have anywhere near the amount of "whining" Go seems to attract

I've never seen a single internal compiler issue in 10 years of working in Go.

What error are you talking about?

In that case, you might enjoy this part of the article:

> For the foreseeable future, the Go team will stop pursuing syntactic language changes for error handling

If you do stuff the language doesn’t support, it’s not the languages problem.