Comment by cyanydeez
2 days ago
So this question was never answered: If Zig had so may problems that they felt compelled to rewrite it all in Rust, does that suggest the great Mythos was unable to fix the Zig version?
Isn't this suppose to be the most advanced model ever and you're telling me they can't just schedule a cron job that detects and repairs the zig version?
Really? Did they just completely admit that the great AI future can't secure a significant project repository?
AI is extremely good at rewriting existing code, and rewriting code is a classic engineering productivity trap. That's a tale as old as time; "we need to rewrite the api in Go" said every new midlevel engineering hire ever. Of course, 9 times out of 10 we don't do it, because the unpredictable costs always outweigh the benefit, and in Jarred's case we're starting to see these costs surface. They aren't technical, they're political; broad swaths of the community have lost faith in him and the Bun project.
Write in C, snapshot to memory safe production Rust that had been verified and differential tested to within an inch of its life. This is a hard reality. Ports will become cheap. Disposable. The vuln finding capabilities are changing everything and not a lot of solutions are out there yet. We can automate the ports and get them efficient.
https://duckduckgo.com/?ia=web&q=bun+fork+of+zig+compiler
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.