5 ms·

“wasted memory”... this stuff exists on the stack, right? And we’re talking on the order of like 64 bytes or less in common, practical scenarios? I believe the

“wasted memory”... this stuff exists on the stack, right? And we’re talking on the order of like 64 bytes or less in common, practical scenarios? I believe the solution has been clearly presented to those who are listening, and the downsides are so much smaller than the status quo. If people on the language team are unwilling to provide developers with the tools to make more robust software because of something like 64 bytes of stack memory... I find that pretty shocking. And yes, I mean that it is extremely difficult to diagnose and fix issues in production software when you only get back a static error value that lacks the dynamic error context that a payload would provide. I’ve been there, done that. Do not want that again. Such a strong viewpoint (avoiding such error payloads) could at least focus more on the technical aspects of how best to implement the elision of unused error payloads instead of just broadly opposing the concept, since it should be obvious how beneficial those payloads are, and the only question is how to remove them for developers who literally cannot spare dozens of bytes of stack memory. (Which I find hard to believe outside of AVR or PIC microcontrollers, which is probably not the best use case to be optimizing for in a new language.) Elision is an optimization that can be added later. It’s not obvious that it can’t be done, and there’s no clear reason that it has to be solved first... I just don’t think anyone would actually care enough to implement it once they see how nonexistent the negative impacts are, but it would be a cool optimization. But, maybe everyone who upvoted the apparently most upvoted GitHub issue on the Zig repo (including myself) is just completely wrong and this obvious solution is actually secretly terrible. It’s entirely possible. Your comment has not really done anything to help me believe that I’m wrong, though, unfortunately. But, as I’m basically “no one” in this context, my opinion probably doesn’t really matter.

dnautics 6y ago
It's not that the "obvious solution" is so terrible, it's that the workaround (not needed in 99% of cases) is really easy and arguably good architectural practice. You can emit an error/ok union and have the error return the structured information. Note that this isn't like go's "if err = nil" monstrosity, either.
- coder543 6y ago
  > You can emit an error/ok union and have the error return the structured information. I already addressed how you’re apparently giving up all of the benefits of Zig’s error handling system to do this. That level of convention breaking isn’t a good sign for anything. The current convention really is that bad, from my point of view. The obvious solution’s extremely tiny overhead could “easily” be avoided in the almost non-existent cases where it matters. I want robust software by default, not software where I have to use side channel hacks to get the information I need by default... but maybe that’s just me. (And everyone else who upvoted that GitHub issue) Of course Zig programmers would be unlikely to see the issue here — naturally the people left are the ones who don’t see the problem. People like myself who know from past experience how problematic not having error context is are likely to just avoid Zig until it meets our minimum requirements. That’s not a problem for existing Zig users — it works for them — but it is annoying to people like me who think Zig otherwise has a number of interesting aspects.
  - dnautics 6y ago
    You're missing the point. Let me give a direct analogy: In erlang there is a fantastic error system, but sometimes you want to emit an ok/error tuple instead. There is a generally sane heuristic of when you do and don't want to use the error pathways, it's a part of making good engineering choices. Generally speaking it's the case where when you want structured errors you use the tuple. It's possible that erlang developers are merely internalizing sone pain, but it's also a robust system that people have been developing highly reliable and broadly used (e.g. rabbitMQ) systems architectures in, so the choice can't be all that bad.

dnautics 6y ago

It's not that the "obvious solution" is so terrible, it's that the workaround (not needed in 99% of cases) is really easy and arguably good architectural practice. You can emit an error/ok union and have the error return the structured information. Note that this isn't like go's "if err = nil" monstrosity, either.

coder543 6y ago
> You can emit an error/ok union and have the error return the structured information. I already addressed how you’re apparently giving up all of the benefits of Zig’s error handling system to do this. That level of convention breaking isn’t a good sign for anything. The current convention really is that bad, from my point of view. The obvious solution’s extremely tiny overhead could “easily” be avoided in the almost non-existent cases where it matters. I want robust software by default, not software where I have to use side channel hacks to get the information I need by default... but maybe that’s just me. (And everyone else who upvoted that GitHub issue) Of course Zig programmers would be unlikely to see the issue here — naturally the people left are the ones who don’t see the problem. People like myself who know from past experience how problematic not having error context is are likely to just avoid Zig until it meets our minimum requirements. That’s not a problem for existing Zig users — it works for them — but it is annoying to people like me who think Zig otherwise has a number of interesting aspects.
- dnautics 6y ago
  You're missing the point. Let me give a direct analogy: In erlang there is a fantastic error system, but sometimes you want to emit an ok/error tuple instead. There is a generally sane heuristic of when you do and don't want to use the error pathways, it's a part of making good engineering choices. Generally speaking it's the case where when you want structured errors you use the tuple. It's possible that erlang developers are merely internalizing sone pain, but it's also a robust system that people have been developing highly reliable and broadly used (e.g. rabbitMQ) systems architectures in, so the choice can't be all that bad.