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

New in Go 1.20: wrapping multiple errors

lukas.zapletalovi.com

Post reply on HN
Print view View original

91–100 of 243 posts

Re: New in Go 1.20: wrapping multiple errors

#91

Post by pjmlp »

p-e-w wrote: post #3

Years and years of discussions about Go's poor and verbose error handling, with multiple sensible proposals being rejected, and this is the improvement that finally makes it into a release? What Go demonstrates above all else is how successful a poorly designed language can be if it has a great compiler, an amazing standard library, and high-quality official tooling. Many "features" of Go are borderline insane (date…

It only worked out because language authors are on Google's paychecks.

Their former language designs (see Limbo and Alef) weren't as successful.

Go is basically Limbo with a bit of Oberon-2 facelift.

Re: New in Go 1.20: wrapping multiple errors

#92

Post by p-e-w »

lelanthran wrote: post #60
p-e-w wrote: post #3

Years and years of discussions about Go's poor and verbose error handling, with multiple sensible proposals being rejected, and this is the improvement that finally makes it into a release? What Go demonstrates above all else is how successful a poorly designed language can be if it has a great compiler, an amazing standard library, and high-quality official tooling. Many "features" of Go are borderline insane (date…

> Go repeats design mistakes that were recognized as mistakes decades ago (nil pointers) All popular languages have some way to encode the fact that a value is absent. When languages that don't support nil/null values become popular, you might have a point in claiming that it was a mistake. Right now it makes no sense to make that claim.

Rust doesn't have nil/null values. It has an Option type that enforces at compile time that you explicitly handle missing values, through pattern matching, transformations, or unwraps.

This makes 95% of the problems associated with nil/null pointers magically disappear. The difference this makes for the safety of large-scale systems is huge.

Re: New in Go 1.20: wrapping multiple errors

#93

Post by nprateem »

p-e-w wrote: post #3

Years and years of discussions about Go's poor and verbose error handling, with multiple sensible proposals being rejected, and this is the improvement that finally makes it into a release? What Go demonstrates above all else is how successful a poorly designed language can be if it has a great compiler, an amazing standard library, and high-quality official tooling. Many "features" of Go are borderline insane (date…

You took the words out of my mouth

Re: New in Go 1.20: wrapping multiple errors

#94

Post by divan »

masklinn wrote: post #69
divan wrote: post #40

Earlier quoted context omitted.

But why? It's so handy in practice! I work a lot with times (not just dates) and having strings like "15:04" make it immediately recognizible, consise and just right. What I actually lack in Go's time is ability to work with time only without timezone (like, event starts at "12:00", regardless of timezone). But here is the thing - Go is a programming language, and not "framework with solutions for every use case" as…

> But here is the thing - Go is a programming language, and not "framework with solutions for every use case" as many others. So... why did they provide a terrible time formatting routine in the first place if it's not a solution to use cases?

Because they're not that smart as HN commenters, obviously. Be compassionate.

Re: New in Go 1.20: wrapping multiple errors

#95

Post by foldr »

pjmlp wrote: post #88
cube2222 wrote: post #66

Earlier quoted context omitted.

> And God forbid I needed to extend this interface and missed to add the new method to one of the 32 types implementing it, so that it blows on my face in prod at 3AM. The language has static type-checking. If to you it's a regular thing that something like this blows up in your face, maybe it's the code base doing too many things dynamically, and not the language? > Great, now I'll have to pull a rickety 3rd-package…

> Or just use any of the popular Go code editors/plugins which give you a "show me all implementations". And me thinking the Go culture is against languages that tend to come with IDEs...

You don't need an IDE to do that. More or les anything that can hook up with the Go language server will do the job.

Re: New in Go 1.20: wrapping multiple errors

#96

Post by shakow »

Thaxll wrote: post #86
p-e-w wrote: post #29

Earlier quoted context omitted.

Well, the proof is in the pudding, and the pudding has spoken and found Go wanting, compared to its most direct competitor, Rust. Even though Go appeared earlier than Rust, and Go's creators are much more famous than Rust's, and the corporation behind Go is much more influential than that behind Rust, adoption of Rust is skyrocketing for mission critical systems while (apart from the container ecosystem) Go is much l…

And yet Go is much more popular than Rust.

And PHP is more popular than both of them, so it's not tomorrow that gauging the qualities of a language on the use the vulgum pecus makes of it will be a good idea.

Re: New in Go 1.20: wrapping multiple errors

#97

Post by twsted »

knorker wrote: post #21

When comparing how Go changes with how C++ changes, one gets renewed appreciation for how good of a job the C++ designers are doing. The more Go evolves, the more clear it gets that it has a very poorly designed foundation. I say that as someone who's coded and reviewed a lot of Go code. Maybe they should not have skipped 40 years of language theory when first creating it. It wasn't obvious in the beginning, but now.…

> When comparing how Go changes with how C++ changes, one gets renewed appreciation for how good of a job the C++ designers are doing.

We must live in a different world...

Re: New in Go 1.20: wrapping multiple errors

#98

Post by Smaug123 »

Thaxll wrote: post #86
p-e-w wrote: post #29

Earlier quoted context omitted.

Well, the proof is in the pudding, and the pudding has spoken and found Go wanting, compared to its most direct competitor, Rust. Even though Go appeared earlier than Rust, and Go's creators are much more famous than Rust's, and the corporation behind Go is much more influential than that behind Rust, adoption of Rust is skyrocketing for mission critical systems while (apart from the container ecosystem) Go is much l…

And yet Go is much more popular than Rust.

… is it? For example, the Stack Overflow survey says Rust was loved by 86% of its users, while Go by 64%. Rust also beat Go on the percentage of respondents who wanted to use it. (But Golang was used by 2% more respondents than Rust, at 11.15% vs 9.32%.)

https://survey.stackoverflow.co/2022/#section-most-loved-dre...

Re: New in Go 1.20: wrapping multiple errors

#99

Post by foldr »

shakow wrote: post #90
cube2222 wrote: post #66

Earlier quoted context omitted.

> And God forbid I needed to extend this interface and missed to add the new method to one of the 32 types implementing it, so that it blows on my face in prod at 3AM. The language has static type-checking. If to you it's a regular thing that something like this blows up in your face, maybe it's the code base doing too many things dynamically, and not the language? > Great, now I'll have to pull a rickety 3rd-package…

> The language has static type-checking. No it does not, at least not completely. When you carry around pointers to struct implementing interfaces, it does not check for anything at compile time. > Or just use any of the popular Go code editors/plugins which give you a "show me all implementations". Does not work all the time, hence my use of the ‶rickety″ adjective. > This makes understanding what a piece of code is…

>When you carry around pointers to struct implementing interfaces, it does not check for anything at compile time.

What exactly do you mean here? You can't assign a value that doesn't implement an interface Foo to a variable of type Foo. That will cause a compile time error.

Re: New in Go 1.20: wrapping multiple errors

#100

Post by lelanthran »

p-e-w wrote: post #92
lelanthran wrote: post #60

Earlier quoted context omitted.

> Go repeats design mistakes that were recognized as mistakes decades ago (nil pointers) All popular languages have some way to encode the fact that a value is absent. When languages that don't support nil/null values become popular, you might have a point in claiming that it was a mistake. Right now it makes no sense to make that claim.

Rust doesn't have nil/null values. It has an Option type that enforces at compile time that you explicitly handle missing values, through pattern matching, transformations, or unwraps. This makes 95% of the problems associated with nil/null pointers magically disappear. The difference this makes for the safety of large-scale systems is huge.

> Rust doesn't have nil/null values.

Yeah, and it's also not popular. The reason I said "popular" is because the popular languages are addressing pain-points for devs.

If nil/null was a pain point, none of the popular languages would allow nil/null values.

The simple fact is that, for many developers, there is a pressing need to indicate lack of a value. Languages that don't address this pain-point never really get taken up en masse.

Post reply on HN