Zig tracking issue

[Jarred-Sumner]

Zig is obviously great and we love it.

Specific painpoints

Safety checks for undefined are not good enough. That undefined is a user-visible number in debug builds and not in release builds has contributed to bugs. When the expected type is a large-ish number, it's very difficult to tell in debug builds whether a number is undefined or just a large number. A Zig developer has to use Valgrind to find out. This has contributed to bugs in bun install, in node:dns, the JS parser, and more. Especially in bun install - we often use an index into a buffer instead of a pointer, which means undefined is a consistent value instead of anything. EXC_BAD_ACCESS won't happen for a number.

IMO:

• Branching on undefined needs to panic in debug builds
• Assigning undefined without the undefined literal needs to panic in debug builds

Example code which would should panic in debug builds but does not

assigning undefined without the undefined literal:

var foo = try allocator.create(Foo);
var baz = try allocator.create(Baz);
foo.* = .{
  .baz = baz,
};

Branching on undefined

var foo = try allocator.create(usize);
// ... sometime later ...
if (foo.* > 0) {
  // ... do stuff
}

More painpoints

• std.os' use of unreachable is unsafe. std.os hiding errno into a zig-specific error leads us to provide lower quality errors to users (Unexpected) and is hard to debug (errno is very google-able). std.fs on Windows leads to lots of panics. We are gradually moving away from using std.os
• Debug builds of Bun takes 1 - 2 minutes (mostly zig)
• [*c] is extremely confusing. There have been bugs due to being unsure whether to pass a pointer to a null-terminated array or a null ptr to a C library
• Reusing small amounts of code inside functions in Zig is painful. We sometimes just copy-paste. C++ lambdas are really nice compared to what we get in Zig. I'm hoping that Proposal: Stack-Capturing Macro ziglang/zig#6965 helps here
• A linter would be really nice. Example: CI should fail if undefined literal is used without a comment explaining why it is okay to do that
• Zig's builtin error does not have a way to provide metadata. Relying on error is often the cause of issues where the error message is unhelpful, because it's not easy to give the user context to help debug the error.
• Zig's strict shadowing rules lead to many variables with _ at the end. IMO, argument names should not conflict with function names. The compiler cannot stop people from doing that. People will just work around it and which makes the code harder to read

Things which are not a priority for us:

• async/await: we use callbacks, this is fine
• package manager: we won't use it in it's current form
• zig cc: we won't use it in it's current form. It's too opinionated about flags.
• Zig's ELF & macho linker: we don't use it. We need a lot of control over flags and smallest-possible linked output size
• LLVM independence: We use C++ alongside Zig.