Comment by justinhj
1 day ago
I was thinking along similar lines today. An AI assisted audit of the issues that caused segfaults could find and implement safe memory management patterns in Zig. It sounds like the Rust port process essentially has had to do this anyway when it analyzed all of the places unsafe is needed and started mitigating some of them. The project also sounds like it has unique memory management problems in its nature: native code calling js code which calls native code and trying to manage lifetimes amongst that.
Zig has a "Zero AI" policy. Bun has had to maintain an internal fork of Zig with various AI-assisted fixes that have resulted in real performance and stability gains for the runtime. Its, arguably, a decent reason to decouple from Zig.
The challenge is: They already were decoupled. They've forked Zig. If your desire is to make a bet on generated code and reasoning as the entire future of software development, as Jarred and Bun have; why would you chain yourself to the crazy political nightmare that is the Rust project, when you've already got a language & runtime that's treated you well, is forked, your contributors know well, etc? Literally: Why can't these issues be fixed within the context of BunZig? Why don't they want to own the whole stack?
I looked at one thing the bun developers wanted to fix in Zig and the issue with it was a bad idea which would not have been merged even if it had been written by a human.