No, Zig's error handling is decent - you either return an error or a value and you have some syntactic sugar to handle it. It's pretty cool, especially given the language's low-level domain.
Meanwhile Go's is just multiple value-returns with no checks whatsoever and you can return both a valid value and an error.
But sometimes it is useful to return both a value and a non-nil error. There might be partial results that you can still do things with despite hitting an error. Or the result value might be information that is useful with or without an error (like how Go's ubiquitous io.Writer interface returns the number of bytes written along with any error encountered).
I appreciate that Go tends to avoid making limiting assumptions about what I might want to do with it (such as assuming I don't want to return a value whenever I return a non-nil error). I like that Go has simple, flexible primitives that I can assemble how I want.
Then just return a value representing what you want, instead of breaking a convention and hacking something and hoping that at use site someone else has read the comment.
Also, just let the use site pass in (out variable, pointer, mutable object, whatever your language has) something to store partial results.
But in most cases you probably want something disjoint like Rust's `Result<T,E>`. In case of "it might be success with partial failure", you could go with unnamed tuples `(Option<T>,E)` or another approach.
