[qezz]

In Zig you need an allocator to allocate anything, so whenever you need to add some extra information to an error, you pass a diagnostics object as an output argument to a potentially failing function. In this case it becomes a bit harder to compare it to Go's errors, each with pros and cons. I think comparing Go errors to Rust errors would be more fair.

There are some articles about the diagnostic pattern in Zig, e.g. [1], [2]

[1] https://github.com/ziglang/zig/issues/2647#issuecomment-5898...

[2] https://mikemikeb.com/blog/zig_error_payloads/

[tialaramex]

How so? In Rust you also need an allocator to allocate anything. Zig's diagnostics idiom is just that, an idiom. It would be very weird to do this in Rust, but then it's a pretty weird choice in Zig, they've just decided to do it anyway.

[qezz]

What I meant by "you need an allocator" is "you need to explicitly pass the allocator of your choice to the function" [if you want to attach some data to the error]. In rust you can simply return anything as error, not only an enum variant.

[tialaramex]

But that's back to idiom. In this case specifically in Zig a common idiom is to pass an allocator to might-allocate functions such as the growable array push function, while in Rust it would be usual to weld the allocator choice to the type itself with a constructor function e.g. Vec::with_capacity_in.