Zig tracking issue

[matklad]

Our wish list for the upstream Zig project!

Overall, we are happy with Zig, and nothing blocks us. Zig's great, we need more Zig!

Some specific pain points, from highest priority to lowest priority:

• Zig upgrades can introduce bugs during the latest upgrade to 0.11 in particular, we got a couple of scary bugs, where the behavior of the code changed silently(https://github.com/tigerbeetle/tigerbeetle/pull/1121). The type of BoundedArray.Len changed, and that caused an overflow. The result type of @min() with a comptime known argument changed, and that also caused overflow (https://github.com/tigerbeetle/tigerbeetle/pull/1129).

  We don't mind churn per se during upgrades, but we do mind churn that hides subtle behavior changes. Not sure what's the fix here. Perhaps, smaller, more frequent releases could help?

• Arithmetics can overflow it's notable that both bugs above culminate in an overflow. We have a lot of comptime limits in Zig, so we use weird types like u7 fairly often, and they are easy to accidental overflow in the current semantics. More robust overflow semantics would help a lot.

• Compilation speed. We care about Debug and ReleaseSafe --- our test suite is based around doing random things, many time a second, so we need ReleaseSafe to make local dev workflows efficient.

• Stdlib performance. std.HashMap and std.sort are our main perf bottlenecks at the moment, improving their performance directly improves our transactions-per-second and p100.

• Language features around pinned structs, result location semantics aliasing and implicit pass by reference. We currently avoid pass by value syntax altogether, and always use *const T or *T.

• https://github.com/ziglang/zig/issues/1006 --- we have a lot of callbacks and sometimes accidentally get indirect recursion. We also sometimes accidental copy large structs through the stack. Having precise stack size requirements for each functions would be awesome.

Things which are not a priority for us:

• async/await --- we use callbacks, we are mostly happy with callbacks
• package manager --- we follow zero dependency policy
• LLVM independence --- given that we need ReleaseSafe for dev workflows, its unlikely that we'll be able to remove our dependence on LLVM for a significant fraction of workflows

[matklad]

Backtraces without debuginfo: https://github.com/ziglang/zig/issues/18520

[matklad]

Triage: I think the list is more-or-less up to date still!