I think Go should have shipped with generics from day one as well.

But you breezily claiming they made the same blunder as Java omits the fact that they didn't make the same blunder as Rust and Swift and end up with nightmarish compile times because of their type system.

Almost every language feature has difficult trade-offs. They considered iteration time a priority one feature and designed the language as such. It's very easy for someone looking at a language on paper to undervalue that feature but when you sit down and talk to users or watch them work, you realize that a fast feedback loop makes them more productive than almost any brilliant type system feature you can imagine.

> lets not forget that the Go team made the same blunder made by Java

To be fair, they were working on parametric polymorphism since the beginning. There are countless public proposals, and many more that never made it beyond the walls of Google.

Problem was that they struggled to find a design that didn't make the same blunder as Java. I'm sure it would have been easy to add Java-style generics early on, but... yikes. Even the Java team themselves warned the Go team to not make that mistake.

Even Rust and F#[1] don't have (generalized) do notation, what makes it remotely relevant to a decidedly non-ML-esque language like Go?

[1] Okay fine, you can fake it with enough SRTPs, but Don Syme will come and burn your house down.

I don't get why people keep thinking it was forgotten; I will just charitably assume that people saying this just don't have much background on the Go programming language. The reason why is because implementing that in any reasonable fashion would require massive changes to the language. For example, you can't build Either/Maybe in Go (well, of course you can with some hackiness, but it won't really achieve the same thing) in the first place, and I doubt hacking it in as a magic type that does stuff that can't be done elsewhere is something the Go developers would want to do (any more than they already have to, anyway.)

Am I missing something? Is this really a good idea for a language that can't express monads naturally?

Well, Rust's `?` was initially designed as a hardcoded/poor man's `Either` monad. They quote `?` as being one of the proposals they consider, so I think that counts?

Source: I'm one of the people who designed it.

It was not forgotten. Maybe/Either and 'do-notation' are literally what Rust does with Option/Result and '?', and that is mentioned a lot.

That said as mentioned in a lot of places, changing errors to be sum types is not the approach they're looking for, since it would create a split between APIs across the ecosystem.

> and yet nowhere on that page is the Haskell-solution mentioned

What do you mean? Much of the discussion around errors from above link is clearly based on the ideas of Haskell/monads. Did you foolishly search for "monad" and call it a day without actually reading it in full to reach this conclusion?

In fact, I would even suggest that the general consensus found there is that a monadic-like solution is the way forward, but it remains unclear how to make that make sense in Go without changing just about everything else about the language to go along with it. Thus the standstill we're at now.

> is the problem just not being able to decide / please everyone,

Reading this article? in fact yes(?):

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

This is a problem of the go designers, in the sense that are not capable to accept the solutions that are viable because none are total to their ideals.

And never will find one.

____

I have use more than 20 langs and even try to build one and is correct that this is a real unsolved problem, where your best option is to pick one way and accept that it will optimize for some cases at huge cost when you divert.

But is know that the current way of Go (that is a insignificant improvement over the C way) sucks and ANY of the other ways are truly better (to the point that I think go is the only lunatic in town that take this path!), but none will be perfect for all the scenarios.

Go has specific goals like not hiding control flow. This would go against those goals, at least the ways people have thought to do it so far.

The thing is, it’s not actually a major problem. It’s the thing that gets the most complaints for sure, and rubs folks from other languages the wrong way often. But it’s an intentional design that is aware of its tradeoffs. As a 10 year Go veteran, I strongly prefer Go’s approach to most other languages. Implicit control flow is a nightmare that is best avoided, imo.

It’s okay for Go to be different than other languages. For folks who can’t stand it, there are lots of other options. As it is, Go is massively successful and most active Go programmers don’t mind the error handling situation. The complaints are mostly from folks who didn’t choose it themselves or don’t even actually use it.

The fact that this is the biggest complaint about Go proves to me the language is pretty darn incredible.

I think the two big things for Go are:

1. Minimalism.

Go has always had an ethos of extreme minimalism and have deliberately cultivated an ecosystem and userbase that also places a premium on that. Whereas, say, the Perl ecosystem would be delighted to have the language add one or seven knew ways of solving the same problem, the Go userbase doesn't want that. They want one way to do things and highly value consistency, idiomatic code, and not having to make unnecessary implementation choices when programming.

In every programming language, there is a cost to adding features, but that cost is relatively higher in Go.

2. Concurrency.

Concurrency, channels, and goroutines are central to the design of the language. While I'm sure you can combine exception handling with CSP-based concurrency, I wouldn't guarantee that the resulting language is easy to use correctly. What happens when an uncaught exception unwinds the entire stack of a goroutine? How does that affect other goroutines that it spawned or that spawned it? What does it do to goroutines that are waiting on channels that expect to hear from it?

There may be a good design there, but it may also be that it's just really really hard to reason about programs that heavily use CSP-style concurrency and exceptions for error handling.

The Go designers cared more about concurrency than error handling, so they chose a simpler error handling model that doesn't interfere with goroutines as much. (I understand that panics complicate this story. I'm not a Go expert. This is just what I've inferred from the outside.)

The language is designed for Google, which hires thousands of newly graduated devs every year. They also have millions of lines of code. In this environment they value easy of onboarding devs and maintaining the codebase over almost everything else. So they are saddled with bad decisions made a long time ago because they are extremely reluctant to introduce any new features and especially breaking changes.

FWIW, I have designed several programming languages and I have contributed (small bits) to the design of two of the most popular programming languages around.

I understand many of Go's design choices, I find them intellectually pleasing, but I tend to dislike them in practice.

That being said, my complaints about Go's error-handling are not the `if err != nil`. It's verbose but readable. My complaints are:

1. Returning bogus values alongside errors.

2. Designing the error mechanism based on the assumptions that errors are primarily meant to be logged and that you have to get out of your way to develop errors that can actually be handled.

To be fair there are lots of people who have used multiple programming languages at expert levels that complain about go - in the same ways - as well! They might not be expert programming language designers, but they have breadth of experience, and even some of them have written their own programming languages too.

Assuming that all complainants are just idiots is purely misinformed and quite frankly a bit of gaslighting.

Protected pages are a feature of all wikis

unfortunately too much spam but the review process is much lighter

Golang is also ugly, for example some fields start with a capital letter and some do not.

Also I don't understand how to implement transparent proxies in Go for reactive UI programming.

Whereas Go has taken the approach of designing everything "later".

Isn't "design by popular vote" an extreme version of "design by committee"? Go won't implement error handling syntax because it can't reach community consensus.

Ugly is subjective, but which part of the syntax is inconsistent?

This is the kind of criticism made by people who've spent less than a few days working with a language. Just glancing at some code from a distance. There's nothing actually wrong with it besides being foreign from what you are used to. After you gain some familiarity, it doesn't look ugly or beautiful it just looks like syntax.

This might be a valid point if Go wasn’t an atrociously ugly and verbose language with some of the worst design out there.

> Programming languages are designed systems, they need to make sense holistically.

Of all the languages in common use, golang is the one that makes the least sense holistically. Return values are tuples, but there's nothing that lets you operate on them. Enums aren't actually limited to the values you define, so there's no way to ensure your switch cases are exhaustive when one is added in the future. Requiring meaningful zero values means that your error cases return valid, meaningful values that can accidentally be used when they return with an error.

This opinion is clearly far more arguable than you might think.

13% mentioned that error handling was the biggest challenge with using Go. This was not a multiple choice question, but you had to pick one answer. We don't know how many people would consider it challenging. (This is typically why you have a 1-10 scale per choice.)

This doesn't mean the rest of the 87% enjoy it. Honestly, I'd rather the next survey included a question "are you satisfied with the current error handling approach"

That survey specifically asked for the "biggest" challenge. One could make a compelling argument for the survey answer "learning how to write Go effectively" being an extremely bad option to put on a survey, because it at-least partially catch-alls every other answer. Its no wonder it got first place.

No, actually, an operator that's essentially a macro for this entirely boilerplate operation would be less terrible, exactly the same decision Rust made for the exact same reason. So would Cox's proposal, so would others. Doing nothing, as a permanent solution, because you can't figure out which of the better things you should do, is not a virtue. You may be confusing it with the virtue of holding out on simpler solutions while a better solution is implemented, or the virtue of not solving things which aren't problems, but this is a problem and they have intentionally blocked the solution indefinitely.

I do something similar. I leave a comment but with a short comment why it’s inverted.

It’s usually pretty obvious why: eg

    if err == nil { 
         // we can exit early because we don’t need to keep retrying

I know diddly/squat about Go, but from similar patterns in aeons past, would "nil == err" work as a way to make it stand out?

Something slightly more elegant (in my subjective opinion) you could do is write

  if !(err != nil) {

Would be nice if code editors colored it differently so it's easier to see.

return nil

would be clearer, I think. Seems like it's the same but would color differently in my editor.

I think its more of a comment that "err != nil" is used in the vast majority of cases, so you start to treat it as noise and skim it.

> then you have _that_ "littering" your code, instead of the syntax.

Yes, exactly. The unusual thing _should_ look unusual.

The same logic could apply to the oppositions they cited to the `try` function though; an editor could easily make it stick out to alleviate it blending in when nested inside blocks. This is exactly why nobody ever accidentally confuses `.await` in Rust for a struct field even though from a plaintext perspective it's syntactically identical. If you're going to utilize the editor to carry the heavy weight, you might as well just pick literally any new syntax that replaces all of the extra typing with something more terse.

At this point I make all my functions return error even if they don't need it. You're usually one change away from discovering they actually do.

On every project I ship I require golangci-lint to pass to allow merge, which forces you to explicitly handle or ignore errors. It forbids implicitly ignoring errors.

Note that ignoring errors doesn't necessarily lead ti a crash; there are plenty of functions where an error won't ever happen in practice, either because preconditions are checked by the program before the function call or because the function's implementation has changed and the error return is vestigal.

> which will lead to a crash

No it won't. It could lead to a crash or some other nasty bug, but this is absolutely not a fact you can design around, because it's not always true.

In primarily throwable languages, it's more idiomatic to not include much error handling throughout the stack but rather only at the ends with a throw and a try/catch. Catching errors in the middle is less idiomatic.

Whereas in Go, the error is visible everywhere. As a developer I see its path more easily since it's always there, and so I have a better mind to handle it right there.

Additionally, it's less easy to group errors together. A try/catch with multiple throwable functions catches an error...which function threw it though? If you want to actually handle an error, I'd prefer handling it from a particular function and not guessing which it came from.

Java with type-checked exceptions is nice. I wish Swift did that a bit better.

I've been programming in PHP since 2002 and Go since 2011. At work I work primarily with two large PHP codebases, 1 about ~half a million lines of code, and the other about ~3 million lines of code. I'm porting PHP code to Go and writing some new code, like cron jobs, in Go. There's about 55,000 lines of Go code at this point.

What I have learned in this time is: Go is a very good, very high quality, very well designed language. PHP is a terrible, terrible, terrible language -- at least if your mission is creating highly reliable software. If your goal is rapid prototyping of the visual appearance of a webpage, PHP is good for that -- that's what it was originally invented for, back in the 1990s, and it's still the best language for that specific use case.

In PHP, if you are looking at a line of code, it's impossible to tell what happens if an error occurs. There's an error_reporting level that can be changed anywhere else in the codebase at any time. So an error might be thrown in the user's face, or not -- depending on the error_reporting level and what the error is. This can also interact with output buffering. (I guess if the "@" sign is present, at least then you know output of an error message is suppressed.) There's a error_handler function that could be set. Oh but it gets worse! Even if you have the entire codebase and can scour every line of code, and trace every possible execution path, you still can't tell what will happen if an error occurs at the line of code you are looking at -- because there are php.ini settings that come into play!

This is without even mentioning the try/catch exception handling system, which PHP also has, and that you think is such a good thing. So if an error happens on the line you are looking at, execution may switch to somewhere above you in the call stack. But (at least in theory) if you have the complete source code, you can figure out all the places where that might be.

This is an absolute nightmare if you care about reliability. The worst thing you could possibly have in a programming language if you care about reliability is to be unable to tell what happens when an error occurs and reason about the program's behavior.

Contrast this with Go. In Go, I can know what happens if an error occurs because it's right there. There's an "if err != nil {..." block that tells me exactly what happens.

By porting code to Go, I've been able to increase the reliability tremendously. The thing about go, is that using Go doesn't automatically give you reliability -- you have to learn the techniques and tools in Go that give you reliability. But once you do that, the quality of software you can produce is vastly higher.

I've spent the last decade or so learning this. Learning how to structure the code to make maximum use of the compiler's static type checking to catch errors. Making use of the static analysis tools that catch errors. Using a combination of errcheck and staticcheck (mentioned elsewhere in this discussion), you can guarantee every err return value is actually checked and handled. So the oft-cited language flaw of Go allowing you to forget to handle errors becomes a non-issue. Go has built-in support for unit tests and the excellent polymorphism system makes tests easier to make than in PHP. And, getting back to the topic at hand, in Go, I created my own system for handling the err values that get returned so junk errors created by hackers trying to find security vulnerabilities on our server get filtered out, while actual errors that I need to fix get logged and brought swiftly to my attention. Can you do something similar in PHP? In theory, perhaps, but we are to afraid of breaking things to try to massively refactor our ~2 million lines of PHP code in order to do that. So we have various log files and database entries that get clogged with errors, and sometimes we notice errors that we need to fix, but usually we don't. Usually we don't know anything is wrong until we get customer complaints on the Help Desk.

Anyway, I'm glad the Go team rejected the idea of changing Go's error handling. Is Go's error handling verbose, tedious, and repetitive? Yes. But it's also unambiguous and gives you total control over how your program responds when an error occurs, which is exactly what you want if you want to write software with the maximum reliability.

Don't just take my word for it. Notice how lots of "cloud infrastructure" is written in Go. Kubernetes is written in Go, Docker is written in Go, Terraform is written in Go, etc.

Yes, I know some people, like Facebook, have managed to write decently reliable code in PHP. But I suspect Facebook has thrown massive amounts of dollars and people at the problem. Various other PHP projects, like certain website creation systems that shall not be named, have a reputation for being buggy.

Sorry, I couldn't let you say PHP has better error handling without a response. It may be "better" for having more compact, prettier looking code. But it's not better for writing actually reliable software. If you want to write actually reliable software, Go is way better.

But, of course, makes the incorrect assumption that <T, E> are dependent variables. The idiomatic Go approach is much more representative of reality. Tradeoffs, as always.

Test coverage as a target metric is stupid.

It this really bothers you, convince your team to use courtney and focus on the more relevant error branches: the ones where (1) a novel error value is produced or (2) handled rather than those that simply bubble it up.

https://github.com/dave/courtney

writing a small book on the topic and somehow missing it is the point, not that technically the text is claiming it, the subtext is doing it.

> how clear and useful it is. Perhaps, but do you really need all that?

Do I need clear and useful things? Maybe not. Would I like to have them anyway? Yes.

Years ago, I configured a Java project's logging framework to automatically exclude all the "uninteresting" frames in stack traces. It was beautiful. Every stack trace showed just the path taken through our application. And we could see the stack of "caused-by" exceptions, and common frames (across exceptions) were automatically cut out, too.

Granted, I'm pretty sure logback's complexity is anathema to Go. But my goodness, it had some nice features...

And then you just throw the stack trace in IntelliJ's "analyze stacktrace" box and you get clickable links to each line in every relevant file... I can dream.

> the wrapping is very greppable when done well

Yeah, that's my other problem with it. _When done well._ Every time I write an `if err != nil {}` block, I need to decide whether to return the error as is (`return err`) or decorate it with further context (`return fmt.Errorf("stuff broke: %w", err)`). (Or use `%v` if I don't want to wrap. Yet another little nuance I find myself needing to explain to junior devs over and over. And don't get me started about putting that in the `fmt` package.)

So anyway, I've seen monstrosities of errors where there were 6+ "statement: statement: statement: statement: statement: final error" that felt like a dark comedy. I've also seen very high-level errors where I dearly wished for some intermediate context, but instead just had "failed to do a thing: EOF".

That all being said, stack traces are really expensive. So, you end up with some "fun" optimizations: https://stackoverflow.com/questions/58696093/when-does-jvm-s...

Whenever I get an error in NodeJS without a stack trace I am pretty pissed off about it. When my program is failing for some reason I really want to know where it came from, and the stack is hugely helpful in narrowing down the possibility space.

I'm not arguing that stack frames are as good as manually written error traces can be - they're clearly not. I am simply amazed that people include "generate error traces" as a form of "handling" an error.

The argument for explicit error values is often something like "it encourages people to actually handle their errors, rather than ignoring them". And on the face of it, this has some merit: we've all seen code that assumes an HTTP request can't fail, and now a small timeout crashes the entire backup procedure or whatever.

But if "handle the error" simply means "decorate it with a trace and return it", then exceptions already do this, then you're really admitting that there is no fundamental difference from a exception, because this is exactly what exceptions do, all on their own. Sure, they produce less useful traces, but that's usually a tiny difference. After all, the argument wasn't "you'll get better stack traces than exceptions give you", it was "people will be more careful to handle errors".

This is also relevant, because if the goal is to get better error traces, that can also be done with exceptions, with just some small improvements to syntax and semantics (e.g. add syntax for decorating a call site with user supplied context that will get included in any exception bubbled from it; add support in an exception to only print non-library stack frames, add support in the language to declare certain variables as "important" and have them auto-included in stack traces - many ideas).

We already have languages that ship features. Go is a lone lighthouse of stability in a sea of fancy languages. I'll play with your fancy languages, but I build my own projects that I actually use in Go because I can trust that it will keep working for a long time and if/when I need to go back to it to fix something in a couple of years I don't need to re-learn a bunch of crap that might have seeped through dependencies or the stdlib.

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

My guess is they will still write Go even if error handling stays the same forever.

The saddest part is that Go's designers decided to use MRV but pretty much just as bad tuples: as far as I can tell the only thing Go uses MRV for which tuple wouldn't be better as is post-updating named return values, and you could probably just update those via the container.

Common Lisp actually does cool things (if a bit niche) things with MRVs, they're side-channels through which you can obtain additional information if you need it e.g. every common lisp rounding functions returns rounded value... and the remainder as an extra value.

So if you call

  (let ((v (round 5 2)))
    (format t "~D" v))

  (multiple-value-bind (q r) (round 5 2)
    (format t "~D ~D" q r))

That's technically not true.

You can pass multiple return values of a function as parameters to another function if they fit the signature.

for example:

  func process[T any](value T, err error) {
    if err != nil {
      // handle error
    }
    // handle value
  }

  for {
    process(fetchFoo(ctx))
    process(fetchBar(ctx))
  }

What else would you want to do with them? Maybe in rare cases you'd want to structure them into an array or something, but the inverse isn't possible either [e.g. func f(a, b, c int) -> f(<destructure array into arguments>)] so it isn't like it is inconsistent.

Perhaps what you are really trying to say is that multiple function arguments is insane full stop. You can pass in an array/tuple to the single input just the same. But pretty much every language has settled on them these days – so it would be utterly bizarre to not support them both in and out. We may not have known any better in the C days, but multiple input arguments with only one output argument is plain crazy in a modern language. You can't even write an identity function.

> they can’t add them because of their bizarre insistence that every type has to have a designated zero value.

Nothing prevents adding union types with a zero value. Sure it sucks, but so do universal zero values in pretty much every other situation so that's not really a change.

> every type has to have a designated zero value

This bonkers design decision is, as far as I can tell, the underlying infectious cause of nearly every real issue with the language.

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

Which is exactly what Rust does -- if the error returned by the function does not match the error type of `?` expression, but the error can be converted using the `From` trait, then the conversion is automatically performed. You can write out the conversion implementation manually, or derive it with a crate like thiserror:

    #[derive(Error)]
    enum MyError {
        #[error("Failed to read file")
        IoError(#[from] std::io::Error)
        // ...
    }

    fn foo() -> Result<(), MyError> {
        let data = std::fs::read("/some/file")?;
        // ...
    }

    fn foo() -> Result<(), MyError> {
        let data = std::fs::read("/some/file").map_err(MyError::IoError)?;
        // ...
    }

> The convenience of writing `?` means nobody will bother wrapping errors anymore.

A thread from two days ago bemoans this point:

https://news.ycombinator.com/item?id=44149809

> What would Rust's "From" look like, for example?

Idiomatic Go type-erases error types into `error`, when there is even a known type in the first place.

Thus `From` is not a consideration, because the only `From` you need is

    impl<'a, E> From<E> for Box<dyn Error + 'a>
    where
        E: Error + 'a,

Sorry, I wasnt specific in that part. When I say 'rust style' Im really just referring to a union type of `result | error`, with a way to check the state (eg isError and isResult) along with a way to get the state (eg getResult and getError). Optionally '?' and '!' as sugar.

That said, the other responder points out why the sum type approach is not favored (which is news to me, since like I said I havent followed the discussion)

It's trickier than that, unfortunately. There has to be at least one new variable on the left side of := but any other variables that already exist in the same scope will simply be assigned to. However, if you use := in a nested block, then the variable is redeclared and shadows the outer-scope variable.

As I understand it, go has some special handling for this scenario because its so prevalent which special cases reassignment. The linked article touches on it

> There are exceptions to this rule in areas with high “foot traffic”: assignments come to mind. Ironically, the ability to redeclare a variable in short variable declarations (:=) was introduced to address a problem that arose because of error handling: without redeclarations, sequences of error checks require a differently named err variable for each check (or additional separate variable declarations)

Oh no, you are making the classic mistake of assuming Go’s designers did something that would make sense, rather than picking the most insane possible design in a given situation.

This is from a while back but was the first thing I thought of: https://gist.github.com/J-Swift/96cde097cc324de1f8e899ba30a1...

I ripped most of it off of someone else, link in the gist

Not a compiler check, but staticcheck is widely used:

    % staticcheck test.go
    test.go:7:2: this value of err is never used (SA4006)

Yeah, as one data point, https://staticcheck.dev/docs/checks/#SA4006 has existed since 2017.

There very much is not. There is a compiler error you can’t disable if a variable is completely unused and that is it.

yes

I guess those are fair criticisms in the abstract, but personally I can’t recall a single time either has caused a bug for me in practice. I also can’t ever recall seeing an LLM or autocomplete mess it up (just my personal experience—I’m sure it can happen).

I don’t see how it breaks anything if it’s opt-in. By default you get the current behavior with zero value initialization if that’s what you want (and in many cases it is). But if you’d rather force an explicit value to be supplied, what’s the harm?

No. Exceptions means the default is to bubble up. You can always write special handling code to prevent bubbling it up if you want in a language with exceptions.

So it's:

Rely on the programmer to identify that an error was made and in 95% of situations just bubble it up, do something useful 5% of the time, but "deal with" the error 100% of the time OR

Rely on the programmer to identify the 5% of situations where they don't want the error to just bubble up and add special handling for that case specifically.

> making errors more informative.

It makes them almost as informative as languages with stack traces! Imagine if Go had a syntax like python's

    raise Exception("bad thing happened") from err

Just write `defer v.Close()`? In almost all cases, `close(2)` errors can be safely ignored. Rust also does this: https://github.com/rust-lang/rust/blob/792fc2b033aea7ea7b766...

I have yet to see a proposal that retains what I love about the status quo: conscientious error handling.

The language’s status quo forces everyone to think about errors more deeply than in other languages and acknowledges that the error case is as critical and worthy of the programmer’s attention.

The whole point of gofmt is that you type in whatever you like and gofmt sorts it out for you. So if you're typing your code in a HN comment box, you'd surely just enter it roughly like that - though i recommend not even including the syntactically irrelevant spaces shown here. Your space bar does have a MTBF you know, and it's measured in activations... let gofmt take the strain. It can waste your screen space for you!

gofmt is the good bit about working in Go. Pretty much everybody uses it, and so you can use it too. Some other languages have similar tools, but they're not as pervasive, so it's far too easy to end up in a situation where you can't use the tool because it would just make too much of a mess of the inconsistently manually-formatted stuff that's already there.

It works really, really well, in part because it's also capable of tracking where an error is turned into another. And the error return trace ends where the stack trace begins (when an error is turned into a panic) so you don't even have to know what an error trace is, because it just makes sense intuitively.

Stack traces are full of noise by comparison and don't have context added by the programmer at each frame. For me, Go error chains are much easier to work with. I can see the entire flow of the error at a glance, and can zero in on the relevant call in seconds with a single codebase search.

Depending on the framework stacks aren't be bad, they are just downright horrifying.

Why can't Atoi report that?

I never said Go is dying. I said go must adapt, or it will die. That's future-tense.

Sure, you can end up with C++ (which is still by some measures the most popular programming language in the world, so that's not a bad place to be). You can also end up with Rust, or Kotlin, or any one of the literally every other programming languages in any ranking's Top 30, all of which have more ergonomic error handling.

A better example in the opposite direction is Java: Its a language that spent years refusing to adapt to the ever-changing needs of software engineers. Its legacy now. That is not Go's present, but it is Go's future at its current pace. Still powering a ton of projects, but never talked about except in disdain like "ugh that Go service is such tech debt, can we get time modernize it next sprint". I don't want that for the language.

Changing too quickly is not a problem. Changing too quickly can lead to problems.

I don't agree that the problems it leads to are bigger problems than stagnation. I also don't believe they're smaller problems; sorting the problems by size is intractable, as it is situation dependent.

The challenge is in the definition of "too quickly"; if fifteen years of stagnation in addressing more productive error handling is the "right pace" of innovation, or lack-there-of; is twenty years? Thirty years? One hundred years? How do you decide when the time is right? Is the Go team just waiting out the tides of the Vox Populi, and maybe one day a unified opinion from the masses will coalesce?

That's weak.

There's no methodologically sound way to measure its popularity available to most people to make an argument on its popularity one way or the other. That's why I didn't, and that's why you shouldn't either.

I return the error to the caller. The caller returns it to their caller. 5 frames up, someone gets a [syscall.EINVAL], and has to figure out what to do about it. Perhaps it's time to log it?

If I had to write my own "100 mistakes" book, "assuming the callee knows what to do" would be somewhere in the top 20, down below "I won't need to debug this".

Inline breakpoint, the same way you set a breakpoint on an expression in any language

You wouldn't. Rust's ? operator doesn't permit that either. If you need to put a breakpoint there, put a line break there.

Sure, why not? Let the programmer decide if they want one line or three lines; the tool can permit both. Gofmt is line-length-agnostic—breaking up long lines is already considered to be the programmer's responsibility.

I have the opposite opinion, I guess! We've been trying to solve everything with language syntax for a long time and it's a bit of a dead end, as the OP shows. Better to start trying new things.

Anyway you can always copy paste it in the normal linear format.

You can argue that is what an exception is. A more ergonomic way to deal with errors that handles propagation for you.

Obviously I'm being terse for argument.

You can easily imagine

  InvokeWithErrorLogger(fn, fnparam, log)

  InvokeWithErrorAnnotator(fn, fnparam, annotatorFn)

> But people may leave go if they constantly avoid fixing any of problems with the language.

For many people the current Go error handling just isn't a problem. Some even prefer it over the overengineered solutions in other languages. This brutalist simplicity is a core design feature I personally enjoy the most with Go, and forcing me to use some syntax sugar or new keywords would make it less enjoyable to use. I also don't think that generics were a net benefit, but at least I'm not forced to use them.

Go is a cemented language at this point, warts and all. People who don't like it likely won't come around if the issues they're so vocal about were fixed. It's not like there's a shortage of languages to choose from.

Pro and con. It hinders progress, but it can also arrest the "enshittification" of a language that takes place when it slowly adds complexity and features and support for whole paradigms.

Python does offer a lot more utility for the expert these days, but it also went from the maxim of "There is one obvious way to do it" to having 5-6 ways to format strings, adding more things to be familiar with, causing refactoring churn as people chase the latest way to do it, etc.

I'm a C++ developer. I wouldn't want to go back to older versions of the language, but it's also very hard to recruit any newer programmers into using it willingly, and the sheer amount of stuff in it that exists concurrently is a big reason why.

But not changing has the same effect, also "forever" (and it also affects many non-users who could become users), so this is not a good argument for doing nothing

If go had started out having different syntax for error handling, would these same people request that it change to what go currently does? Or is this just resistance to change, and wanting to keep what they are used to?

I suspect it is the latter.

“Simply declaring” is inaccurate description of the Go team’s decision. The team built several proposals, reviewed dozens more, and refined the process by gathering user feedback in multiple channels.

The Go team thoroughly explored the design space for seven years and did not find community consensus.

Even if people in your example couldn't agree on a particular alternative, the outcome still is a less attractive area, maybe some will move out and fewer people move in. So, any solution would be better than the status quo - and they all would probably agree on that.

The lack of a good error handling story to a lot of people puts go in a mental trash bin of sorts. Similar (but different) reasons eg Java goes to a mental trash bin. I think leaving this issue unhandled will only make go look worse and worse in comparisons as the programming language landscape evolves. It might take 10 or 20 years but it'll always be unique in having "trash bin worthy" error handling. (this can perhaps be argued - maybe exceptions are worse, but at least they're standard).

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

You'll never get it in any non-gamed environment.

In democratic voting in FPtP systems if there isn't a majority winner you'll take the top two and go to runoffs forcing those that are voting to pick the best of the bad choices.

This is the same thing that will typically happen in the city you're talking about, hence why most democracies are representative and not direct.

Honestly this is only because they made a bad survey. A ranked choice is better.

Lets say you have 5 choices. You give each choice a voting weight of 1 (not an issue) to (5 biggest issue). You only get to pick a weight once.

So in this type of voting even if everybody put error handling and #4 it could still win by a large margin if the 5 values were spread out over other concerns.

There's no happy path in programming. Errors are just some of the many states in the code and the transition to them doesn't disappear magically because you chose to not specify them. Actually returning an error is just a choice, you can chose to handle the situation, maybe log the error and go on your merry way. Or you panic() and cancel the whole call stack back to a recover(). I like Go because it forces you to be explicit.

This paragraph alone is fundamentally better than the page or so of text in the blog post.

I'm not sure what it is about the style of technical writing I've seen lately but just directly getting to the point versus trying to obfuscate the thesis on a potentially controversial topic is increasingly rare

The module system shows the Go core team will make unilateral changes if they feel like it. But if I read this correctly, there’s not a consensus even amongst the Go team on what to do here.

What I wonder about is the pool of potential Go developers. Is the error handling issue serious enough to stop developers from even considering Go? Go would have been an obviously better choice than most languages 30 years ago, but today there are many more good options.

I suspect a lot of us don’t have strong feelings either way and don’t find the verbosity “hostile”. No need for Stockholm syndrome if you don’t feel like a prisoner.

Of course you may have been joking, in which case “haha”. xD

If you say so. For me it's always been the opposite - I'm excited at the start about all the cool features, then slowly get disillusioned because of the warts.

I appreciate the argument that things can often be difficult for noobs but actually fine or better than alternatives once you get used to them.

But on the other hand, people who are "used to the way things are" are often the worst people to evaluate whether changes are beneficial. It seems like the new people are the ones that should be listened to most carefully.

I'm not saying the Go team was wrong in this decision, just that your heuristic isn't necessarily a good one.

It’s fun, because when a newcomer joins a team, people tend to remind them that their bison is fresh and they might be seeing pain we got accustomed to. That’s usually said in a positive manner.

To be honest, I really don't believe that will happen in the future. All of the proposals pretty much just add syntactical sugar, and even those have failed to gain consensus.

That's okay. Not everyone needs to like Go. Pleasing every programmer on the planet is an unreasonable thing to ask for. It's also impossible because some preferences conflict.

How is Go not a design-by-committee language? They don't have a single lead language developer or benevolent dictator, and as this blog demonstrates, they're very much driven by consensus.

Not OP, but I found a compiler bug in the initial release of 1.18, though it was also quickly fixed: https://github.com/golang/go/issues/51733

I did nothing weird, played around a bit with the new iterators.

Internal compiler errors are very much the implementation's problem.

UPDATE: See comment below for full error message and a link to the code.