Live data from Hacker News

Major standard library changes in Go 1.20

blog.carlmjohnson.net

1–10 of 265 posts

Re: Major standard library changes in Go 1.20

#2
Just when you think you have The Best Way of handling errors in Go figured out, they add yet another paradigm.

Is a shared err type package on the way out? I use it to bubble up HTTP status codes consistently, is there a better way? Should you always use sentinel errors?

Re: Major standard library changes in Go 1.20

#3

Just when you think you have The Best Way of handling errors in Go figured out, they add yet another paradigm. Is a shared err type package on the way out? I use it to bubble up HTTP status codes consistently, is there a better way? Should you always use sentinel errors?

The only constant is change. Especially with Go, apparently. It's hard to evaluate the comparison of Golang of today to the one I originally discovered 11 years ago in 2012.

Then, it was a breath of fresh air. Nowadays.. I find myself sighing. It works but the joy has faded.

Bit rot is life.

Re: Major standard library changes in Go 1.20

#4

Just when you think you have The Best Way of handling errors in Go figured out, they add yet another paradigm. Is a shared err type package on the way out? I use it to bubble up HTTP status codes consistently, is there a better way? Should you always use sentinel errors?

It’s the same paradigm. You still have to do if err != nil. Multierrors have been in the community forever. It’s just been added to the standard library is all.

Re: Major standard library changes in Go 1.20

#5

Just when you think you have The Best Way of handling errors in Go figured out, they add yet another paradigm. Is a shared err type package on the way out? I use it to bubble up HTTP status codes consistently, is there a better way? Should you always use sentinel errors?

It’s the same paradigm. You still have to do if err != nil. Multierrors have been in the community forever. It’s just been added to the standard library is all.

[deleted]

Re: Major standard library changes in Go 1.20

#7

Just when you think you have The Best Way of handling errors in Go figured out, they add yet another paradigm. Is a shared err type package on the way out? I use it to bubble up HTTP status codes consistently, is there a better way? Should you always use sentinel errors?

Sentinel errors are only one way, and definitely not the best way imo. `errors.As` gets you the ability to recursively and multierror-safely check to see if somewhere in the stack, an error of a certain type is found, and access its extra data, to determine e.g. which status code is most appropriate based on any extra data in that type.

I think shared types from a package make a ton of sense and are really practical for writing flexible and maintainable code.

Re: Major standard library changes in Go 1.20

#9

[flagged]

For your information, I understand what is meant by stochastic parrot, but after interacting with ChatGPT quite a bit it is clear to me it is doing real thinking.

One way you can verify this is to ask for its opinion about novel things, for example you can invent something new and ask its ideas about it. It will give genuine feedback that shows understanding and does not show parroting behavior. Soon you will be able to ask it to build you the damn thing as well, and that should put an end to the idea that it is just parroting. It's not quite there so sometimes it does indeed seem to just parrot.

But it has real thoughts as well.

Re: Major standard library changes in Go 1.20

#10
Very useful! I'll be playing with the error tree additions and studying the HTTP interface extension to see if I can replicate the pattern for https://github.com/bbkane/warg values. Id like to be able to have value-specific output for different types of --help , even ones not in warg
Post reply on HN