Hacker News Reader

Comment by knighthack | Hacker News Reader

I'm not sure why allowances are made for Zig's verbosity, but not Go's.

What's good for the goose should be good for the gander.

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.

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.

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

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

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.

Zig's verbosity goes hand in hand with a strong type system and a closeness to the hardware. You don't get any such benefits from Go's verbosity.

I think a better word may be "explicitness". Zig is sometimes verbose because you have to spell things out. Can't say much about Go, but it seems it has more going on under the hood.

Reply on news.ycombinator.com