Tracking Issue: Priorities of Real World Zig Users

andrewrk · September 13, 2023, 6:26pm

I created this issue and pinned it for visibility:

Tracking Issue: Priorities of Real World Zig Users

opened 06:15PM - 13 Sep 23 UTC

use case

This issue is a reminder to go look at [Third Party Tracking Issues (what is imp…ortant to other people?)](https://github.com/ziglang/zig/wiki/Third-Party-Tracking-Issues-(what-is-important-to-other-people%3F)) and browse through third party tracking issues to learn what things are affecting real world users of Zig. That link is on the Zig wiki and is freely editable. Please feel free to add your projects to the list there and share your troubles. ---- Additionally, I will list some *actionable* issues that are already in the Zig issue tracker: * [ ] #16711 * [x] #16672

Please feel free to follow the link to that wiki page and add your projects to the list. If you do this, it will help me and other Zig contributors understand what issues specifically are the most important to you.

There are a lot of issues open in Zig right now, and I have a long-term plan to address them all. But, let’s be strategic about it and help unblock everyone we can in the short-term too.

matklad · September 15, 2023, 9:02am

Added the one for TigerBeetle:

github.com/tigerbeetle/tigerbeetle

Zig tracking issue

opened 08:58AM - 15 Sep 23 UTC

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

andrewrk · September 15, 2023, 5:38pm

Thanks! It’s helpful when feeling overwhelmed by the sheer number of issues open, to focus on these issues and be rewarded by seeing real world users benefit immediately.

By the way, I’m happy to see compilation speed in there. That’s what I feel the most driven to focus on at the moment, and I’m making swift progress towards the “Incremental Compilation” column in the Performance Project. Meanwhile, @kubkon just landed enough of the x86/ELF linker from the “Ditch LLVM” column to fully unblock the next card in that list which is x86 backend. I know y’all need ReleaseSafe during development, but, if Debug gets 6x faster bypassing LLVM, that’s also a win for you, right?

kubkon · September 15, 2023, 6:02pm

More ELF features resume on Thursday next week - I plan to have zld/ELF fully upstreamed to Zig in the next couple of weeks including revamped linker tests. This will unblock x86_64 backend to work with shared objects and system libcs on various Linux hosts, and hopefully will be a prelude to enabling bootstrapping of Zig using our own self-hosted backend on x86_64-linux host.

matklad · September 15, 2023, 6:18pm

Certainly!