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

101–110 of 243 posts

Re: New in Go 1.20: wrapping multiple errors

#101

Post by nvarsj »

kajaktum wrote: post #61
nvarsj wrote: post #38

I find it ironic that golang refuses to introduce exceptions, but instead is slowly turning errors into a crappy substitute. I feel like a modern language should do either two things with errors: exceptions, or a result monad. Since the language is GC'd and doesn't have language support to make a result type practical, it seems like exceptions are a no brainer.

>Since the language is GC'd and doesn't have language support to make a result type practical, it seems like exceptions are a no brainer. Elaborate? What prevents Go from introducing result monad aside from the syntax?

I'm sure it could introduce something _like_ a result monad, but with the associated very clunky/verbose syntax in golang which reduces to conditionals and lots of type casts. I guess this is sort of where error is going.

Something like Rust's '?' operator comes to mind. Also, pattern matching with parameter extraction.

Re: New in Go 1.20: wrapping multiple errors

#102

Post by pjmlp »

switch007 wrote: post #13
kaba0 wrote: post #10

Earlier quoted context omitted.

For all that you have the JVM ecosystem with multiple better languages (including Java itself)

3 second builds?

Yes, thanks to compile on save on IDEs.

Also Turbo Pascal, Modula-2, Delphi, VB 6 were already doing that in 1990's hardware.

Here Turbo Pascal 5.5 marketing material from 1989, 34 000 lines per minute.

https://archive.org/details/TurboPascal55

Go compile times are a reason to admire only for those that never used such compiler toolchains.

Re: New in Go 1.20: wrapping multiple errors

#103

Post by topicseed »

Errors are undeniably verbose but they incite the developer to consider them, and add context or information to them. I wouldn't say they're a massive issue.

Now, enums I find myself missing, and the same goes for parsing dates from strings. Holy moly.

Otherwise, it's a straight to the point language and I get stuff done with it. Less tinkering, less overthinking, it just gets stuff done.

Re: New in Go 1.20: wrapping multiple errors

#104

Post by pjmlp »

vsnf wrote: post #80
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.…

> It wasn't obvious in the beginning, but now... Was it not obvious at the beginning that this was a bad idea? What was the state of programming languages where consciously tossing out progress was considered not on, its face, insane?

In a sense this is a tradition that the Go authors already followed once when designing C.

"Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own. "

-- https://www.bell-labs.com/usr/dmr/www/chist.html

Re: New in Go 1.20: wrapping multiple errors

#105

Post by insanitybit »

twsted wrote: post #97
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...

I get where you're coming from but consider that C++ has added an obscene number of features and it somehow all works. You can say "that's bad that they added tons of features" and I'll agree with you, but the fact that they've been able to do so is impressive and speaks to a powerful design process.

Re: New in Go 1.20: wrapping multiple errors

#106

Post by pjmlp »

foldr wrote: post #95
pjmlp wrote: post #88

Earlier quoted context omitted.

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

So somehow needing a language server to work around language design flaws is alright for Go then.

Re: New in Go 1.20: wrapping multiple errors

#107

Post by nprateem »

I still feel there's space for a middle ground language. One that:

* compiles (ie no interpreter/VM required)

* is statically typed and has generics

* has exceptions or option types

* doesn't have a borrow checker

* isn't purely functional but has map, filter, pattern matching, etc

* has reasonable traction

Is there anything like this?

Re: New in Go 1.20: wrapping multiple errors

#108

Post by Smaug123 »

cube2222 wrote: post #75
Smaug123 wrote: post #62

Earlier quoted context omitted.

> I much prefer it to exceptions as it makes you think about each error and makes people wrap errors with helpful context everywhere… This would be absolutely fine, for the reasons you state, if Go made you deal with the error. But because it will silently allow you to completely ignore the error, your statement that it "makes you think about each error" is quite optimistic. In an exceptionful language, the runtime w…

That is a fair point and it's why I use errcheck[0]. [0]: https://github.com/kisielk/errcheck

Magic! I just checked, and this found the bug in a Go tool I use that bit me a couple of months ago, which I'm still smarting from. Thanks!

Re: New in Go 1.20: wrapping multiple errors

#109

Post by shakow »

insanitybit wrote: post #84
p-e-w wrote: post #20

Earlier quoted context omitted.

The biggest mystery to me is how poorly designed Go is considering its illustrious creators. Thompson and Pike are living legends. They had absolutely nothing left to prove. Yet they came together for another major project, backed by the most powerful technology corporation in the world, and they produced... this? Go feels like a random hodgepodge of ideas from three or four computer science undergraduates – not like…

The mistake was designing around "simplicity" - a nebulous, unattainable goal. It's sort of like designing around "happiness" - who is to say what happiness is? Is happiness satisfaction? Ecstasy? Fulfillment? Does it require some sadness? How nebulous it is is really well demonstrated in Pike's talk[0] where he somehow believes that a for loop is "simpler" than methods like "filter" and "map", and makes the very str…

Even for bad/inexperiences/stressed/inattentive/... developers, Go is a minefield.

Just a trivial example: trying to use append(x, y) without re-assigning to x? Congrats, it will compile without warnings, work fine for a while, then at one point append will reallocate and bang, have fun letting the newbie debug that on a Friday evening.

Re: New in Go 1.20: wrapping multiple errors

#110

Post by shakow »

bamboozled wrote: post #77
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…

Sorry, but what are you talking about? Poorly designed? A lot of incredibly good software is written in Golang and while that might not mean it's the best language ever designed, it would be hard to say it's "poorly designed" based on that fact alone?

Incredibly good software has been written in JS, that does not make a good language out of it.

To a competent team, a bad language is an hindrance, not a deadly obstacle.

Post reply on HN