Try saying English “hell” but dragging out the “l” (“helllllllll”); very nasal. Compare audio here: https://en.wiktionary.org/wiki/hell#German

RE: Claude Code, no I haven't used it, but I did do the Anthropic interview problem, beating all of Anthropic's reported Claude scores even with custom harnesses etc.

It's not a dunk that agents can't produce "as fast as can be" code; their code is usually still reasonably fast; it's just often 2-10x slower than can be.

Would you endorse the pattern I described in my article if the calling code could have other uses for the diagnostic info than just logging?

In my project I decided that the CLI main should be the place with a reporting mechanism. All the internal code is agnostic to how errors are handled. Many errors could be retried, even if they are currently not, and in some cases you also need extra diagnostic data in order to retry. For example if 1/4 plugins fails to load, I would need to know which one failed to ask the user interactively where to find it or whether to skip it before retrying. There's a few different errors like this, and layers between the handling code and the error source code, which is how I ended up with the union(enum) diagnostic keyed by error code pattern.

It seems that "error codes aren't a reporting mechanism", practically speaking, means that internal application code should just log its own error and return a generic error code that bubbles up unhandled out of main. You decided that this wasn't ok for allocation failures and encourage retrying those, which I find to be inspiring, but apparently most types of application errors are fine to essentially log and ignore. So that is confusing.

I love Zig, and look up to you a lot, so thanks for all your efforts over the years!

But also, I'm sure this method has flaws and can be greatly improved, so hopefully we can come to the right solution.

If I really needed a large error payload, too big to fit on the stack, I'd probably want to do something like this:

  const errbuf = try alloc.alloc(u8, 1024*1024*1024);
  module.setErrorBuf(&errbuf)
  defer {
    module.setErrorBuf(null);
    alloc.free(errbuf);
  }

  var func_diag = diagnostics.OfFunction(module.func){};
  module.func(foo, bar, &func_diag) catch |err| switch (err) {
    error.BigPayload => {
      const payload = func_diag.get(error.BigPayload);

      // The payload can reference the 1MiB of data safely here,
      // and it's cleaned up automatically.
    }
  }

  % rg Diagnostics zig/lib/std | wc -l
  165

To me, this post is proof zig doesn't need "proper support". You can already have extremely ergonomic error payloads with existing language features.

Earlier version of this post had some language feature ideas, but then I realized Zig already had all the capabilities, so I just removed that section.

For example, I used to think it'd be nice for functions to be a namespace, so I didn't have `myFunc` and `MyFuncDiagnostics`. But then I realized that the Diagnostics type doesn't need its own name; you can just put the type in the function signature, and use a function like `diagnostics.OfFunction(fn)` to extract the type from the function definition, so you can just write this:

  var diag: diagnostics.OfFunction(myFunc) = .{};
  const res = myFunc(foo, bar, &diag) catch |err| ...;

Do you want automatic inference of the error payload type? So zig creates a special tagged union error payloads type for you automatically? It seems complicated and maybe not a good idea. Do you really want your function to return an invisible 20 elements union on error? Do you want to call a someone else's function which returns an invisible 20 elements union on error? You know, maybe it's not a good idea.

  // sqlite.zig
  pub const ErrorPayload = struct {
      message: [256]u8,
  
      pub fn init(db: *c.sqlite3) @This() {
          var self = std.mem.zeroes(@This());
          var fw = std.Io.Writer.fixed(self.message[0..]);
          _ = fw.writeAll(std.mem.span(c.sqlite3_errmsg(db))) catch |err| switch (err) {
              error.WriteFailed => return self, // full
          };
          return self;
      }
  };

Comments URL: https://news.ycombinator.com/item?id=47028705

Points: 93

# Comments: 37

(The green threads coro stack stuff makes this more important.)

[1]: https://github.com/ziglang/zig/issues/23475#issuecomment-279...