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

Post by arp242 » Wed, Nov 29, 2023, 11:36 PM UTC

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.

Post by throwawaymaths » Thu, Nov 30, 2023, 12:01 AM UTC

ForkMeOnTinder wrote: post #30

klyrs wrote: post #24

Earlier quoted context omitted.

Nope, no operator overloading. As I understand it, the philosophy is to not hide O(n) behavior behind notation that looks O(1).

And what's funny about that stance is mathematical operators aren't actually O(1). https://en.wikipedia.org/wiki/Computational_complexity_of_ma... You don't want to know what the innocent-looking `*` in this function compiles to: fn square(num: u10000) u10000 { return num * num; }

Post by tester756 » Thu, Nov 30, 2023, 12:06 AM UTC

dilyevsky wrote: post #49

ForkMeOnTinder wrote: post #26

Earlier quoted context omitted.

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

Post by tialaramex » Thu, Nov 30, 2023, 12:15 AM UTC

alphazard wrote: post #59

zgk7iqea wrote: post #56

go is step by step reinventing exceptions

Exceptions typically unwind the stack, producing a stack trace similar to what certain Go error types already do. Go's panic does actually unwind the stack. In a sense, Go has had Java/Python style exceptions, from the beginning, through panic and recover. This project distinguishes itself from that pattern in the README. As far as error handling is concerned, errors as values is the modern thinking. Go is not behind…

Post by bensecure » Thu, Nov 30, 2023, 12:21 AM UTC

tialaramex wrote: post #67

alphazard wrote: post #59

Earlier quoted context omitted.

Exceptions typically unwind the stack, producing a stack trace similar to what certain Go error types already do. Go's panic does actually unwind the stack. In a sense, Go has had Java/Python style exceptions, from the beginning, through panic and recover. This project distinguishes itself from that pattern in the README. As far as error handling is concerned, errors as values is the modern thinking. Go is not behind…

> If you squint, the `(T, error)` return type is very similar to Rust's `Result` This requires the kind of squinting where 9 x 9 = 81 is basically the same as 9 + 9 = 18 right? I mean, they're roughly the same symbols, albeit one at slightly different angle, and in a different order... Result is a sum type, as are a lot of key things in Rust. Take the Rust type Result - this has three possible values, Ok(true), Ok(fa…