Hacker News Reader

Comment by MrJohz | Hacker News Reader

Interestingly, I just read an article from matklad (who works a lot with Zig) talking about the benefits of splitting up error codes and error diagnostics, and the pattern of using a diagnostic sync to provide human-readable diagnostic information:

https://matklad.github.io/2025/11/06/error-codes-for-control...

Honestly I was quite convinced by that, because it kind of matches my own experiences that, even when using complex `Error` objects in languages with exceptions, it's still often useful to create a separate diagnostics channel to feed information back to the user. Even for application errors for servers and things, that diagnostics channel is often just logging information out when it happens, then returning an error.

View on HN

The separation of error codes and diagnostics is fine, but the language needs a standard mechanism to optionally pass this error diagnostic information. Otherwise, everyone will develop their own different way with ZERO consistency and many will simply not pass error diagnostics at all.

Your and GP's two statements are not mutually exclusive. This paradigm can have significant benefits, and at the same time be too cumbersome for people to want to use consistently.

I agree that building a special diagnostic system is better than just using language's builtin error system. However that takes efforts.

Library developers tend to choose the path of least resistance, which is to not pass diagnostic information.

The most convenient diagonistic system is the good old logging. Logging is easy.

Maybe logging will be the de facto solution of passing error data in Zig ecosystem, due to psychological reasons.

I tend to follow the rest of the ecosystem when developing libraries. If i wanted to make a zig lib id look at what other major libs are doing (or not doing) and copy that.

If i found no consistency id be making a post like OP but from a different perspective.

If they want to keep to the error/diagnostic pattern I think they're gonna have to adopt some kind of standard context object that gets passed around. Passing an allocator, an IO implementation, and a diagnostic object all over your code base is going to get really fucking old.

if it helps: it's pretty typical to attach the allocator to the object directly, so you dont have to pass it everywhere. for library consumers, just build a global allocator and use that. io will just "have to be passed the annoying way" in libraries (but a consumer can also also easily globalize that).

I'm assuming you're talking about the "managed" pattern you'd see in stuff like Hashmaps and ArrayLists. To my knowledge that style is falling out of favor, and I think the managed versions will be removed from the standard library.

I haven't seen anyone use a global allocator in the way you're talking about, and if you did I feel like it goes directly against the Zig ethos. Part of the benefit of allocators being passed around is that all allocation are explicit.

If you're a library writer, then don't make a global allocator. If you aren't, then do whatever you feel like.

Having metadata with the error doesn't exclude having a separate diagnostics system. You don't have to use errors with metadata.

Reply on news.ycombinator.com