[Zambyte]

FWIW Zig has error handling that is nearly semantically identical to Go (errors as return values, the big semantic difference being tagged unions instead of multiple return values for errors), but wraps the `if err != nil { return err}` pattern in a single `try` keyword. That's the verbosity that I see people usually complaining about in Go, and Zig addresses it.

[kbolino]

The way Zig addresses it also discards all of the runtime variability too. In Go, an error can say something like

    unmarshaling struct type Foo: in field Bar int: failed to parse value "abc" as integer

Whereas in Zig, an error can only say something that's known at compile time, like IntParse, and you will have to use another mechanism (e.g. logging) to actually trace the error.

[metaltyphoon]

Yep. Errors carry no context whatsoever and you have no idea where they came from.

[Zambyte]

You can trace error returns with the builtin @errorReturnTrace function.

https://ziglang.org/documentation/0.14.1/#errorReturnTrace

https://ziglang.org/documentation/0.14.1/#Error-Return-Trace...

[gf000]

I mean, this is definitely not a strong suit of go either. In Zig you can just pass in a pointer though to add additional context.