Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What canceled my Go context?

rednafi.com

Post reply on HN
Print view View original

51–60 of 70 posts

Re: What canceled my Go context?

#51

Post by 9rx »

grey-area wrote: post #19
lemoncucumber wrote: post #12

It’s great that they identified this (incredibly common) pain point and introduced a way to solve it, but I can’t help being disappointed. Reading the examples I found myself thinking, “that looks like a really useful pattern, I should bookmark this so I can adopt it whenever I write code like that.” The fact that I’m considering bookmarking a blog post about complex boilerplate that I would want to use 100% of the t…

I agree go’s error handling feels a bit clunky, though I prefer the local error handling and passing up the chain (if it were a bit more ergonomic) to exceptions, which IMO have a lot of other problems. The main problems seem to me to be boilerplate and error types being so simplistic (interface just has a method returning a string). Boilerplate definitely seems solvable and a proper error interface too. I tend to us…

> I agree go’s error handling feels a bit clunky

It should be the same handling as all other types. If it feels clunkier than any other type, you've not found a good design yet. Keep trying new ideas.

Re: What canceled my Go context?

#52

Post by themafia »

lemoncucumber wrote: post #12

It’s great that they identified this (incredibly common) pain point and introduced a way to solve it, but I can’t help being disappointed. Reading the examples I found myself thinking, “that looks like a really useful pattern, I should bookmark this so I can adopt it whenever I write code like that.” The fact that I’m considering bookmarking a blog post about complex boilerplate that I would want to use 100% of the t…

> It feels like you’re constantly fighting the language

I disagree. I feel like I constantly understand precisely what the language is and is not going to do. This is more valuable to me than languages with 100 sigils that all invoke some kind of "magic path" through my code.

> forces you to handle errors but 99% of the time that means just returning the error after possibly wrapping it

How do you universally handle an inventory error? The _path_ to and from the error is more important than the error or it's handling clauses.

> After a decade of writing Go I still don’t have a good rule of thumb for when I should wrap an error with more info or return it as-is.

Isn't the point of the above that no matter which you choose the code is mostly the same? How much of an impact is this to refactor when you change your mind? For me it's almost zero. That right there is why I use go.

Re: What canceled my Go context?

#53

Post by grey-area »

9rx wrote: post #51
grey-area wrote: post #19

Earlier quoted context omitted.

I agree go’s error handling feels a bit clunky, though I prefer the local error handling and passing up the chain (if it were a bit more ergonomic) to exceptions, which IMO have a lot of other problems. The main problems seem to me to be boilerplate and error types being so simplistic (interface just has a method returning a string). Boilerplate definitely seems solvable and a proper error interface too. I tend to us…

> I agree go’s error handling feels a bit clunky It should be the same handling as all other types. If it feels clunkier than any other type, you've not found a good design yet. Keep trying new ideas.

Well two things to me feel clunky, first is less serious but leads to lots of verbosity:

1. if err != nil is verbose and distracting and happens a lot. I'd prefer say Ian Lance Taylor's suggestion of something like this where you're just going to return it vs standard boilerplate which has to return other stuff along with the error:

// ? Returns error if non-nil, otherwise continue

data, err := os.ReadFile(path) ?

// Current situation

data, err := os.ReadFile(path)

if err != nil {

  return x,y,z,err
}

The second is a problem of culture more than anything but the stdlib is to blame:

2. The errors pkg and error interface has very basic string-based errors. This is used throughout the stdlib and of course in a lot of go code so we are forced to interact with it. It also encourages people to string match on errors to identify them etc etc. Yes you can use your own error types and error interfaces but this then creates interop problems and inevitably many pkgs you use return the error interface. I use my own error types, but still have to use error a lot due to stdlib etc. The wrapping they added and the annotation they encourage is also pretty horrible IMO, returning a bunch of concatted strings.

So these are not things that end users of the language can fix. Surely we can do better than this for error handling?

Re: What canceled my Go context?

#54

Post by 9rx »

grey-area wrote: post #53
9rx wrote: post #51

Earlier quoted context omitted.

> I agree go’s error handling feels a bit clunky It should be the same handling as all other types. If it feels clunkier than any other type, you've not found a good design yet. Keep trying new ideas.

Well two things to me feel clunky, first is less serious but leads to lots of verbosity: 1. if err != nil is verbose and distracting and happens a lot . I'd prefer say Ian Lance Taylor's suggestion of something like this where you're just going to return it vs standard boilerplate which has to return other stuff along with the error: // ? Returns error if non-nil, otherwise continue data, err := os.ReadFile(path) ? /…

> if err != nil is verbose and distracting and happens a lot.

if err != nil is no more or less verbose than if x > y. You may have a point that Go could do branching better in general, but that isn't about errors specifically.

If there is something about errors that happening a lot then that still questions your design. Keep trying new ideas until it isn't happening a lot.

> Surely we can do better than this for error handling?

Surely we can do better for handling of all types? And in theory we can. In practice, it is like the story of generics in Go: Nobody smart enough to figure out a good solution wants to put in the work. Google eventually found a domain expert in generics to bring in as a contractor to come up with a design, but, even assuming Google is still willing to invest a lot of money in the new budget-tightening tech landscape, it is not clear who that person is in this case.

Ian Lance Taylor, as you mention, tried quite hard — with work spanning over many years — in both in both cases to find a solution, which we should commend him for, but that type of design isn't really his primary wheelhouse.

Re: What canceled my Go context?

#55

Post by pjmlp »

lemoncucumber wrote: post #12

It’s great that they identified this (incredibly common) pain point and introduced a way to solve it, but I can’t help being disappointed. Reading the examples I found myself thinking, “that looks like a really useful pattern, I should bookmark this so I can adopt it whenever I write code like that.” The fact that I’m considering bookmarking a blog post about complex boilerplate that I would want to use 100% of the t…

Go 2.0 already exists, Java, D, C#, Swift, F#, OCaml,....

The community is special and now with the original authors mostly gone, and AI into the mix, I don't see it ever happen.

We will get ridiculous Go 1.xyzabc version numbers.

Re: What canceled my Go context?

#56

Post by malklera »

I am new enough to programming that I actually have no concrete idea what a context is; I just use it when a library asks for it.

> lemoncucumber

> it can be tempting to keep adding layer upon layer of wrapping resulting in an unwieldy error string that’s practically a hand-rolled stacktrace

I thought this was the whole reason to wrap errors, to know where they passed up the chain.

Funny how it seems no matter the subject, if Go is involved, errors get discussed.

Re: What canceled my Go context?

#57

Post by ErroneousBosh »

pjmlp wrote: post #55
lemoncucumber wrote: post #12

It’s great that they identified this (incredibly common) pain point and introduced a way to solve it, but I can’t help being disappointed. Reading the examples I found myself thinking, “that looks like a really useful pattern, I should bookmark this so I can adopt it whenever I write code like that.” The fact that I’m considering bookmarking a blog post about complex boilerplate that I would want to use 100% of the t…

Go 2.0 already exists, Java, D, C#, Swift, F#, OCaml,.... The community is special and now with the original authors mostly gone, and AI into the mix, I don't see it ever happen. We will get ridiculous Go 1.xyzabc version numbers.

Go compiles to machine-native language.

Java, C# and so on are scripting languages that compile to bytecode that's then run by a painfully slow interpreter.

Re: What canceled my Go context?

#58

Post by pjmlp »

ErroneousBosh wrote: post #57
pjmlp wrote: post #55

Earlier quoted context omitted.

Go 2.0 already exists, Java, D, C#, Swift, F#, OCaml,.... The community is special and now with the original authors mostly gone, and AI into the mix, I don't see it ever happen. We will get ridiculous Go 1.xyzabc version numbers.

Go compiles to machine-native language. Java, C# and so on are scripting languages that compile to bytecode that's then run by a painfully slow interpreter.

Not at all, information is out there in case you want to properly educate yourself on what dynamic compilers are, and what AOT options exist since the 2000's.

Re: What canceled my Go context?

#60

Post by saghm »

9rx wrote: post #54
grey-area wrote: post #53

Earlier quoted context omitted.

Well two things to me feel clunky, first is less serious but leads to lots of verbosity: 1. if err != nil is verbose and distracting and happens a lot . I'd prefer say Ian Lance Taylor's suggestion of something like this where you're just going to return it vs standard boilerplate which has to return other stuff along with the error: // ? Returns error if non-nil, otherwise continue data, err := os.ReadFile(path) ? /…

> if err != nil is verbose and distracting and happens a lot. if err != nil is no more or less verbose than if x > y. You may have a point that Go could do branching better in general, but that isn't about errors specifically. If there is something about errors that happening a lot then that still questions your design. Keep trying new ideas until it isn't happening a lot. > Surely we can do better than this for erro…

> if err != nil is no more or less verbose than if x > y. You may have a point that Go could do branching better in general, but that isn't about errors specifically.

In practice though, there's not nearly as many cases where someone needs to repeat `if x > y { return x }` a bunch of times in the same function. Whether the issue is "about errors" specifically doesn't really change the relatively common view that it's an annoying pattern. It's not surprising that some people might be more interested in fixing the practical annoyance that they deal with every day even if it's not a solution to the general problem that no one has made progress on for over a decade.

Post reply on HN