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

Show HN: Error return traces for Go, inspired by Zig

github.com

Post reply on HN
Print view View original

41–50 of 92 posts

Re: Show HN: Error return traces for Go, inspired by Zig

#41

Post by mrkeen »

kaba0 wrote: post #18
packetlost wrote: post #10

Earlier quoted context omitted.

Exceptions are only better than C style error return numbers but worse than pretty much every other model of error handling we have today.

Based on what exactly? I do think that e.g. rust’s error handling is quite okay with proper algebraic data types, but (checked) exceptions are similarly safe and ergonomic to use. The worst is without doubt the C style, whose legacy Go happily lengthens by doing the exact same thing, but natively in the language.

Checked exceptions are not ergonomic.

Whatever other benefits they might have are lost when every Java developer rethrows every checked exception as a more ergonomic RuntimeException.

Re: Show HN: Error return traces for Go, inspired by Zig

#42

Post by kaba0 »

mrkeen wrote: post #41
kaba0 wrote: post #18

Earlier quoted context omitted.

Based on what exactly? I do think that e.g. rust’s error handling is quite okay with proper algebraic data types, but (checked) exceptions are similarly safe and ergonomic to use. The worst is without doubt the C style, whose legacy Go happily lengthens by doing the exact same thing, but natively in the language.

Checked exceptions are not ergonomic. Whatever other benefits they might have are lost when every Java developer rethrows every checked exception as a more ergonomic RuntimeException.

Still better than losing an error case. But java’s solution is not the most ergonomic, no one was talking about that implementation.

Re: Show HN: Error return traces for Go, inspired by Zig

#43

Post by jerf »

mordechai9000 wrote: post #28
riku_iki wrote: post #12

Earlier quoted context omitted.

There is an opposite opinion on this

I just picked up Go and thought I might use it for Advent of Code, to help gain some familiarity. The error handling kind of threw me off, though. I am coming from typescript most recently, and I think crashing on unhandled errors is a good thing. I have bad memories of perl doing unintended things after failing to catch an error. But I am willing to go out of my comfort zone. I think I'll probably have to find some…

The "standard linter" in Go is https://golangci-lint.run/ , which includes [1] the absolutely-vital errcheck which will do that for you.

For an Advent of Code challenge you may want to turn off a lot of other things, since the linter is broadly tuned for production, public code by default and you're creating burner code and don't care whether or not you have godoc comments for your functions, for instance. But I suggest using golangci-lint rather than errcheck directly because there's some other things you may find useful, like ineffassign, exportloopref, etc.

I highly recommend using Go with linters... but then, I highly recommend using any language with all the lint-like support you can get from the very beginning of any project, so I wouldn't read too much into that.

[1]: https://golangci-lint.run/usage/linters/

Re: Show HN: Error return traces for Go, inspired by Zig

#44

Post by Groxx »

oefrha wrote: post #21
Groxx wrote: post #11

Earlier quoted context omitted.

Except for the stack trace part, which is a gigantic reason why it was popular. tbh I'm not sure what the current popular option is for wrapping with stack traces. Re join: it isn't a joiner-error, it has no need to do anything for that. Just stdlib-join-then-wrap.

It’s pretty easy to write your own Errorf() wrapper or some sort of WithStack() that stores runtime/debug.Stack() output. github.com/pkg/errors offers more flexibility in formatting though.

Well, sure, but by that metric this library is even easier to build yourself since it's only gathering a single stack entry per wrap. And it has no backwards compatibility to worry about.

"You can build X by hand too" has little to do with why people choose to create or use libraries.

Re: Show HN: Error return traces for Go, inspired by Zig

#45

Post by pstuart »

oefrha wrote: post #9
Groxx wrote: post #7

Earlier quoted context omitted.

At the very least: > This repository has been archived by the owner on Dec 1, 2021. It is now read-only. It's largely complete so it is essentially fine at the moment, but it won't be adapted to future language or community changes. A future landmine.

It’s archived mainly because it’s been superseded by fmt.Errorf() with the %w directive. Go 1.20 also introduced errors.Join() and multi-%w which github.com/pkg/errors lack, so using for green field projects is very ill-advised.

It would be great if the internals added %W as an option that would also include the relevant trace. Shouldn't be unreasonable or impossible.

Re: Show HN: Error return traces for Go, inspired by Zig

#46

Post by xh-dude »

zoogeny wrote: post #36
pixelpoet wrote: post #15

(Aside about Zig, sorry. Although this applies to Go as well, I think?) Urgh I am so keen to switch to Zig but their attitude towards having vector operators just completely kills the viability for me as a graphics programmer. I've asked in their Discord, Andrew Kelley himself passed on commenting (I know his stance, every C++ dev wants their fav feature), but the reality remains that it's just infeasible to do with…

I was watching a recent talk about the new Mojo language [1]. There is a section on SIMD and how they treat scalar values as a special case of vector operations (around the 33 min time). It does seem that tensors are one of the core abstractions for modern ML systems. I've heard people joke that AI is just matrix multiplication. Python is such a flexible language that creating abstractions around its syntax was super…

Julia has good ideas, interesting trade-offs here as well. ISTM the deep problem is that there’s so much room for optimization under composition of operations or with invariants not captured in types that the typical LinAlg library will never capture. But I agree most languages should be anticipating that users need something helpful here.

Re: Show HN: Error return traces for Go, inspired by Zig

#47

Post by marhee »

avg_dev wrote: post #16
abhinavg wrote: post #6

Earlier quoted context omitted.

The README covers the idea behind errtrace in more details, but the primary difference is in what is captured: pkg/errors captures a stack trace of when the error occurred, and attaches it to the error. This information doesn't change as the error moves through the program. errtrace captures a 'return trace'--every 'return' statement that the error passes through. This information is appended to at each return site.…

How does one go about implementing something like this? I am quite curious.

I suspect it is based on https://pkg.go.dev/runtime#Caller

Re: Show HN: Error return traces for Go, inspired by Zig

#48

Post by packetlost »

kaba0 wrote: post #42
mrkeen wrote: post #41

Earlier quoted context omitted.

Checked exceptions are not ergonomic. Whatever other benefits they might have are lost when every Java developer rethrows every checked exception as a more ergonomic RuntimeException.

Still better than losing an error case. But java’s solution is not the most ergonomic, no one was talking about that implementation.

What checked exception implementation do you have in mind then?

Re: Show HN: Error return traces for Go, inspired by Zig

#49

Post by dilyevsky »

ForkMeOnTinder wrote: post #26
pixelpoet wrote: post #15

(Aside about Zig, sorry. Although this applies to Go as well, I think?) Urgh I am so keen to switch to Zig but their attitude towards having vector operators just completely kills the viability for me as a graphics programmer. I've asked in their Discord, Andrew Kelley himself passed on commenting (I know his stance, every C++ dev wants their fav feature), but the reality remains that it's just infeasible to do with…

That's one of the downsides of a BDFL. Zig is like 98% amazing, and 2% strange decisions that I think could have been avoided if the creator had more experience with languages other than C and Javascript. I'm still a happy Zig user though, and hey, there's still time before 1.0.

Not supporting operator overloading is not a “strange decision” it’s widely hated feature outside of very specific domains (like maths and graphics) and every shop i worked at which bothered with a c++ guideline banned it

Re: Show HN: Error return traces for Go, inspired by Zig

#50

Post by riku_iki »

mrkeen wrote: post #41
kaba0 wrote: post #18

Earlier quoted context omitted.

Based on what exactly? I do think that e.g. rust’s error handling is quite okay with proper algebraic data types, but (checked) exceptions are similarly safe and ergonomic to use. The worst is without doubt the C style, whose legacy Go happily lengthens by doing the exact same thing, but natively in the language.

Checked exceptions are not ergonomic. Whatever other benefits they might have are lost when every Java developer rethrows every checked exception as a more ergonomic RuntimeException.

> Checked exceptions are not ergonomic.

its about the same ergonomics as rust error handling. Its just many people don't like to check exceptions, similarly many people write python code without explicit types.

Post reply on HN