3 ms·

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.

• nurbl 1y ago
  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.
• ummonk 1y ago
  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.
• Zambyte 1y ago
  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 1y ago
    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 1y ago
      Yep. Errors carry no context whatsoever and you have no idea where they came from.
      • Zambyte 1y ago
        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/#errorReturnTrace https://ziglang.org/documentation/0.14.1/#Error-Return-Traces https://ziglang.org/documentation/0.14.1/#Error-Return-Trace...
      • gf000 1y ago
        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.