This Bun rewrite feels like a potential Mythos marketing stunt.
[dead]
Bun Rust rewrite: "codebase fails basic miri checks, allows for UB in safe rust"
91–100 of 366 posts
Re: Bun Rust rewrite: "codebase fails basic miri checks, allows for UB in safe rust"
#92So Bun saga has been "Zig, let me Ai you" "no" *Ai's Zig fork, suffers from memory bugs* "Well I'm moving!" *Ai's code into Rust, suffers from memory bugs*
Sure. I'm completely unaffiliated and think Zig's AI stance is ridiculous & politically-motivated and a port is absolutely justified if they will not budge. Apparently I am deeply in the minority.
The no-AI policy of the Zig compiler project is for the compiler, other projects can do whatever they want.
Bun's fork of Zig was just an unsound hack that at best would have produced a strictly inferior speedup compared to our current work with incremental compilation, which is already plenty usable:
- June 2025 core team starts using it with the zig compiler itself https://ziglang.org/devlog/2025/#2025-06-14
- April 2026 https://ziglang.org/devlog/2026/#2026-04-08
> Zig's AI stance is ridiculous & politically-motivated
It's literally an issue with our business model to mess with our contributor pipeline, can't get more concrete than this.
Re: Bun Rust rewrite: "codebase fails basic miri checks, allows for UB in safe rust"
#93What I don't understand is if they were going to translate Zig to unsafe Rust, why not just build a translation tool for it? You could do a one-to-one mapping of language constructs, hardcoding patterns in your codebase, and as one friend put it "Tbh they could've just hooked up zig translate-c to c2rust". They would get deterministic translation, would probably have not been a heavy investment to build, and the outp…
> why not just build a translation tool for it?
They did ;) a highly dynamic one...
Re: Bun Rust rewrite: "codebase fails basic miri checks, allows for UB in safe rust"
#94This doesn't seem surprising, given the straight translation that they prompted. Couldn't a case be made that it's better to get Bun to the to the language with the stronger type system first and, once there, use that stronger type system as leverage for these kinds of improvements as a follow-on effort? It seems preferable to requiring perfection on the very first step.
They'll just need to update the prompt with "make sure there's no UB", and it should be good.
Re: Bun Rust rewrite: "codebase fails basic miri checks, allows for UB in safe rust"
#95Earlier quoted context omitted.
Yes, and seems pretty clear you can now backpressure the rewrite with tools like miri to have Claude Code automatically improve it.
[flagged]
This is, ironically, a pretty good idea. ...Minus the fact that you're presumably talking about having AI generate it all instead.
Re: Bun Rust rewrite: "codebase fails basic miri checks, allows for UB in safe rust"
#96What I don't understand is if they were going to translate Zig to unsafe Rust, why not just build a translation tool for it? You could do a one-to-one mapping of language constructs, hardcoding patterns in your codebase, and as one friend put it "Tbh they could've just hooked up zig translate-c to c2rust". They would get deterministic translation, would probably have not been a heavy investment to build, and the outp…
[deleted]
Re: Bun Rust rewrite: "codebase fails basic miri checks, allows for UB in safe rust"
#97I think the only way to interpret a one million line LLM-generated diff with no proper reviews as an employee of Anthropic is that my company no longer has an interest in understanding, or even looking at, its own code.
I'd be concerned that by jumping onboard with this sort of development process I'd lose touch with how to engineer software in a detail-oriented or remotely rigorous way.
It also makes me question what sort of value the entire Bun project ever had if a drop-in replacement can just be thrown in here like it's nothing. Why do we need all these JS runtimes again?
The AI bubble is so large that we've also forgotten how useless and dumb a lot of software engineering labor was even before LLMs came along. We were already in a bubble.
All that is to say, I think it's useful to reframe some conversations about AI as, "if AI can accomplish this task, was it ever actually valuable?" I think for some specific things, the answer will be yes, but the tech industry has been huffing its own farts for so long I really don't think anyone has sight anymore of what's economically valuable in a ground truth sense. Much like LLMs themselves, this confusion pollutes the entire well of discourse about their economic utility.
Re: Bun Rust rewrite: "codebase fails basic miri checks, allows for UB in safe rust"
#98Step 1: Vibe-code a buggy, poorly-performing, 500k+ LoC desktop-installed monstrosity in TypeScript to implement a trivial TUI. Proudly note that you’re meeting a 16ms frame budget … for a trivial chat UI.
Step 2: Purchase an entire company for a product that, if you squint, might help paper over the entirely predictable problems that arise from using the wrong tools to implement the wrong architecture, because surely the solution isn’t reevaluating your original engineering choices.
Step 3: Perform a buggy, vibe-code rewrite of the tool you just bought. A tool you only need because — for whatever internal political reasons — sunk cost means you can only keep digging.
Step 4: ???
Re: Bun Rust rewrite: "codebase fails basic miri checks, allows for UB in safe rust"
#99It is really sad and unfortunate that coding has started falling under the omnicause. Low-denominator discourse is invading every space I find interesting and it is difficult to avoid.
I agree. I'm as skeptical as many commenters but I also think the degree of polarization in HN around this technology and the degree to which people are calling those with different views shills or naysayers is pretty sad.
Re: Bun Rust rewrite: "codebase fails basic miri checks, allows for UB in safe rust"
#100So Bun saga has been "Zig, let me Ai you" "no" *Ai's Zig fork, suffers from memory bugs* "Well I'm moving!" *Ai's code into Rust, suffers from memory bugs*
Sure. I'm completely unaffiliated and think Zig's AI stance is ridiculous & politically-motivated and a port is absolutely justified if they will not budge. Apparently I am deeply in the minority.
https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
> An example of this is the changes to type resolution which happened in the 0.16.0 release cycle—these didn’t affect users too much, but had big implications for the compiler implementation. Before those changes, the compiler’s behavior was often highly dependent on the order in which types and declarations were semantically analyzed by the compiler. Some orders might result in successful compilation, while others give compile errors. Single-threaded semantic analysis prevented these bugs from causing user-facing non-determinism. The rewritten type resolution semantics were designed to avoid these issues, but Bun’s Zig fork does not incorporate the changes (and has not otherwise solved the design problems), which means their parallelized semantic analysis implementation will exhibit non-deterministic behavior. That’s pretty much a non-starter for most serious developers: you don’t want your compilation to randomly fail with a nonsense error 30% of the time.
There is a reason why, zig is upholding the quality and they hate it.