> I work on Bun and this is my branch
>
> This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.
>
> I’m curious to see what a working version of this looks, what it feels like, how it performs and if/how hard it’d be to get it to pass Bun’s test suite and be maintainable. I’d like to be able to compare a viable Rust version and a Zig version side by side.From your post, though, it sounds like Bun may have been a pretty direct rewrite, without too many hard choices along the way. Is that fair?
That sounds like a perfectly functional project, to me.
how long does it take to compile?
@jarredsumner: It's basically the same as in zig using our faster zig compiler. If we were using the upstream zig compiler, rust port would compile faster.
Basically we are seeing now an "inverse Hofstadter's Law" where doing something with an LLM takes less time thanexpected even when you take into account this law.
I am a Rust developper myself but I really love Zig and Bun. I am just overly curious of all this.
Even LLMs themselves can't accurately estimate this (though this may be out of distribution stuff)
haven't used zig...(only used rust)
but zig doesn't solve those problems?
I am of the opinion that it is horses for courses and not a universal better proposition.
Because my needs don’t fit in with Rust’s decisions very well I will use zig for personal projects when needed. I just need linked lists, graphs etc…
While hopefully someone can provide a more comprehensive explanation here are the two huge wins for my use case.
1) In Zig, accessing an array or slice out of bounds is considered detectable illegal behavior.
2) defer[0] allows you to collocate the the freeing of resources with code.
That at least ‘feels’ safer to me than a bunch of ‘unsafe’ rust that is required for my very specific use case.
I was working on some eBPF code in C and did really miss zig.
For me it fits the Pareto principle but zig is also just a sometimes food for me, so take that for what it is worth.
It gives you a few more tools than C - like a debug allocator, bounds checked array slices and so on. But it’s not a memory safe language like rust.
Zig is still under development and beta. Stability, crashes, and leaks should not be surprising, and even expected. To stick with a beta language, usually companies and developers are philosophically and/or financially aligned with the language. An example is JangaFX and Odin, where they not only have committed to using the language (despite being beta) in their products, but have directly hired GingerBill.
Team Bun appears to have "alignment and relationship issues" with Zig, to the point they have decided to extensively explore their options. Now Bun is rewritten in Rust. They are seeing if Rust solves their requirements. As with any relationship, if one ignores or takes a partner for granted, don't be surprised if they want a divorce or jump to someone else.
Bun: Hold my beer
The AI companies and their associates are beginning to surpass that level of denials and lies.
What would the emerging odds be? My guess is 19/20 in favor of ditching Zig.
I have followed many initial denials on a wide range of topics, not only rewrites, over the years. Like clockwork, most of them were lies.
would the world come to a standstill tomorrow if every Bun instance out there ran on Node.js ?
they know their A.I can't sell without the noise that it's now on the edge of the frontier. this is hype.
zig adopting a strict 'no LLM' policy affects the LLM vendors.
I’ve been thinking about setting up a non trivial project to use as a benchmark for any plugins and/or harness changes I make.
Having a prebuilt verification suite is great. You can use it to asses things like token usage, time, across different harnesses, models, plugins.
> I expect OSS to go the opposite direction: no human contribution allowed. Slop will be a nostalgic relic of 2025 & 2026.
We should have seen this coming after they got acquired by Anthropic, but it's still disappointing. I'm not against large language models as a technology, just thoroughly disgusted how these "AI" companies rose to power, eating the software industry and the rest of society. It's creating a very unhealthy dependency.
Think a few steps ahead and start preparing a slop-free software stack and community. That includes Zig and its ecosystem. Even if we (and future generations) don't manage to live entirely without slop, it's more important than ever to ensure a sustainable computing culture, free as in freedom.
Believe it or not, for some of us it’s not “the whole damn point”.
It’s not that anthropic/google/openai/etc are unavoidable
Seems like that would make open source entirely controlled by open ai, anthropic et al.
That is actually a very plausible scenario!
Your kind of negativity is pathological.
Underestimating how quickly a non-trivial project will come together is an almost unheard of phenomenon. It used to invariably be the other way around, to the point that there are laws about it, like Hofstadter's Law, which says that projects always take longer than anticipated, even when accounting for the law itself. Or Fred Brooks' work, which puts limits on how much the development of software projects can be sped up.
The sane takeaway here is that if what's being reported is true (keeping in mind it's coming from a newly minted Anthropic employee), it implies an astonishing, unheard of improvement in software development speed, at least for certain kinds of tasks, enabled by LLMs.
To somehow twist that into "experts may not be as skilled and knowledgeable as they appear" or "not skilled in the tools they’re using" makes me think of the Charles Babbage quote, "I am not able rightly to apprehend the kind of confusion of ideas that could provoke such [an opinion]."
Bun has had an extremely high amount of crashes/memory bugs due to them using Zig, unlike Deno which is Rust.
Of course, if Bun's Rust port has tons of `unsafe`, it won't magically solve them all, but it'll still get better
You get very few of the Rust guarantees when you litter your code with unsafe to get around the safety checks (which is what they're doing here). I would not recommend running this in production.
Any stats/source? Not that I think it's false
> and the ugly parts look uglier (unsafe) which encourages refactoring.
Looks like Bun owes that to itself to some extent, not solely because of the language
https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3...
119 open, 885 closed
https://github.com/denoland/deno/issues?q=is%3Aissue%20state...
10 open, 46 closed
> why: I am so tired of worrying about & spending lots of time fixing memory leaks and crashes and stability issues. it would be so nice if the language provided more powerful tools for preventing these things.
Not a hard number obviously but a clear indication those issues exist.
With unlimited tokens make it a lint rule or auto formatter.
This just sounds like they are not good at using Zig. I have been daily driving ghostty on linux for a fairly long time now and I have never seen these kinds of issues. I have also used ghostty on macos for a bit and didn't have any problems there either.
Zig is really good for writing stable and reliable code. There is also a database written in Zig that seems to be fairly successful [0].
I also wrote zig for some time and compiler/toolchain was really pleasant to use. I wrote more segfaults in Rust ffi code than all segfaults I had in Zig in total while I was writing Zig.
What caused you to hallucinate such a broad blanket statement? The point is the memory unsafety issues they ran into would be categorically impossible in safe Rust, which is why they're doing this in the first place.
While bounds checking, improved argument passing, typed pointers, proper strings and arrays are an improvement over C, it still suffers from use after free cases.
C++ already prevents many of those scenarios, at least for those folks that don't use it as a plain Better C, and actually make use of the standard library in hardned mode. When not, naturally is as bad as C.
Also to note that the tools that Zig offers to prevent that, are also available in C and C++, but people have to actually use them, e.g. I was using Purify back in 2000's.
Then there is the whole point that Zig is not yet 1.0, and who knows what will still change until then.
Seems like their luck finally ran out. For the longest time, they were getting all kinds of passes, as if a post 1.0 language, that others don't get. 10 years is quite a long time not to hit 1.0 or still be into beta breaking changes. Though I think that (the luck) was significantly aided by their perpetual and odd HN boosting.
> While bounds checking, improved argument passing, typed pointers, proper strings and arrays are an improvement over C, it still suffers from use after free cases.
While Zig was a bit safer and more modern C alternative, safety was arguably not so much their selling point. Plenty of other C alternative languages are equally or more safe. Dlang and Vlang, both now having optional GCs and ownership, are examples.
https://t3x.org/t3x/0/index.html
https://t3x.org/t3x/0/t3xref.html
Beyond these Curses simple games, there's a 6502 assembler and disassembler among a Kim-1 simulator, Micro Common Lisps and whatnot.
KDE also includes many other programs inside it like music player, document reader etc. that I never had any issues with.
This is a classic logic problem - eg “there is an orange cat” doesn’t imply “all cats are orange”.
There’s a lot of leaky crap written in those languages too. One of the core promises of Rust is that the compiler will catch memory issues other languages won’t experience until runtime. If Zig doesn’t offer something similar it’ll make Rust very compelling.
plenty of other companies/entities making high quality software in zig? tigerbeetle, zig itself for example.
Bun's entire history has been a kind of haphazard move as fast as you can story, so...
They're difficult to find, difficult to reason about in big software and you'll always create some. Languages that rule that out are a huge improvement in terms of correctness.
Rust is perfect for writing all of code using LLM. It's strict type system makes is less likely to make very dumb mistakes that other languages might allow.
Also want to note that writing the code using LLM doesn't remove the need to have a vision for the design and tradeoffs you make as you build a project. So Jarred and his team are the right kind of people to be able to leverage LLMs to write huge amounts of code.
I question this. Yes, strong enforcement of invariants at compile time helps the LLM generate functional code since it gets rapid feedback and retraces as opposed to generating buggy code that fails at runtime in edge cases.
On the other hand, Rust is a complex language prone to refactoring avalanches, where a small change in a component forces refactoring distant code. If the initial architecture is bad or lacking, growing the code base incrementally as LLMs typically do will tend towards spaghettification. So I fear a program that compiles and even runs ok, but no longer human readable or maintainable.
This may be so, but LLMs are great at slogging through such tedious repercussions.
I would say if the language prevents sloppy intermediate states, that actually makes it more amenable to AI; if you just half-ass a refactor into a conceptually inconsistent state, it’s possible for bad tests to fail to catch it in Python, say. But if many such incomplete states are just forbidden, then the compiler errors provide a clean objective function that the LLM can keep iterating on.
Are you saying this out of personal experience or just hypothesizing? I am working on a large, complex rust project with Claude Code and do not experience this at all.
- write sleek operator-overloading-based code for simple mathematical operations on your custom pet algebra
- decide that you want to turn it into an autograd library [0]
- realise that you now need either `RefCell` for interior mutability, or arenas to save the computation graph and local gradients
- realise that `RefCell` puts borrow checks on the runtime path and can panic if you get aliasing wrong
- realise that plain arenas cannot use your sleek operator-overloaded expressions, since `a + b` has no access to the arena, so you need to rewrite them as `tape.sum(node_a, node_b)`
- cry
This was my introduction to why you kinda need to know what you will end up building with Rust, or suffer the cascade refactors. In Python, for example, this issue mostly wouldn't happen, since objects are already reference-like, so the tape/graph can stay implicit and you just chug along.
I still prefer Rust, just that these refactor cascades will happen. But they are mechanically doable, because you just need to 'break' one type, and let an LLM correct the fallout errors surfaced by the compiler till you reach a consistent new ownership model, and I suppose this is common enough that LLM saw it being done hundreds of times, haha.
I haven't had any issues with this getting out of hand on >10KLOC vibed rust codebases.
This rewrite is >750k lines of Rust
Example of a Claude Code session after 2 hours of "Crunching" that came out without results https://github.com/mohsen1/tsz/pull/4868 (Edit I force pushed to PR to solve the problem, you can see the initial refuse message in the initial version of PR description)
Funny thing is, the last percent of the test have been so hard to work on that Opus 4.7 routinely bails and says "it's too involved or complicated" so I had to add prompts specifically asking it not to bail.
I've also seen the benefits of Rust for this too. And making the bet that my pg experience will help me make good design choices around many of the things people have been having trouble with in pg for a long time[1]. Excited to see AI make it more possible to improve complex pieces of software than has historically been practical.
[0] https://github.com/malisper/pgrust [1] https://malisper.me/the-four-horsemen-behind-thousands-of-po...
curious about your workflow for running all these accounts. different harnesses in parallel? manually switching in codex? 5.5pro only?
what works for you?
[0] https://malisper.me/pgrust-rebuilding-postgres-in-rust-with-... [1] https://malisper.me/pgrust-update-at-67-postgres-compatibili... [2] https://github.com/loongphy/codex-auth
Left to itself, it often follows human developers who conceive of their goal as "get the program working, the end justifies the means." Which makes sense because there are a lot of systems like that in the training corpus.
Pretty impressive that it is faster than the Go version already.
It's much faster in single file benchmarks (3 to 5x)
https://tsz.dev/benchmarks/micro
I have optimizations planned for large projects that I'm still flushing out.
Rust is a terrible language for using LLMs to write code if Rust's low latency isn't needed, because of its extreme compile times. LLMs code faster than humans so a far bigger fraction of the time is spent waiting for the compiler, and a reasonably sized project will take literally 10x longer to compile in Rust than in e.g. Zig or Go.
https://blog.katanaquant.com/p/your-llm-doesnt-write-correct...
Claude code C compiler passed 100% of gcc tests and couldn't even run a hello world...
If you've heard this problem described as a fundamental limitation of the compiler, and not the kind of packaging glitch that's routine to find in pre-alpha software of all descriptions, whoever described it to you that way is not serving their readers well.
I'm not saying CCC was production-ready, or close -- the total lack of an optimizer would be a killer in any real use, and I assume that there were problems with the diagnostics at least as bad as problems with performance and the include files, for similar reasons -- the LLMs hadn't been asked to optimize for that stuff yet, just test suite correctness. But it did achieve that, and the amount of cope I've seen on social media claiming otherwise is more than a bit disturbing.
If it doesn't work, it doesn't. You can find all these excuses. But at the end of the day, there is a difference between an end user being able to get something out of your code or not.
The main problem I think that it was extremely slow.
if you give just the logical tests, it wont consider the speed at all. if you included tests that measure the speed and ask the llm to match the performance, itll do that too.
its the same class of error as everything else with llms. it has no common sense context for things people consider important. if you dont enforce the boundaries, it will ignore them
How important is well specified opt function? No one knows. We will find out
LLMs work best when the user defines their acceptance criteria first - https://news.ycombinator.com/item?id=47283337 - March 2026 (422 comments)
OK, they've got a working prototype, congrats! Now it needs to be put into shape so that all the unsafe blocks are eliminated (maybe with a few tiny exceptions), and the code is turned into maintainable, readable, reasonably idiomatic Rust.
I wonder how long is it going to take.
Not sure that rule is even applicable anymore, but I don't have a better heuristic to make guesses by either.
All the unsafe seems to be FFI?
https://github.com/search?q=repo%3Aoven-sh%2Fbun+unsafe+lang...
> and the code is turned into maintainable, readable, reasonably idiomatic Rust. I wonder how long is it going to take.
This isn't a c2rust rewrite?
The rewrite's in https://github.com/oven-sh/bun/tree/claude/phase-a-port. By running the following command on it, I count about 14,000 unsafe blocks:
rg --stats -g '*.rs' 'unsafe \{|unsafe impl|#!?\[unsafe\('I am very curious what the numbers are once the test suite passes and after a few passes of reducing the amount of unsafe.
The answer is... more than any of us could likely afford.
I wonder how much of this is original size vs rust requiring verbosity vs the LLM being verbose in general.
Not a criticism, I do believe language translation it's the one field that AI is mature enough to near one shot projects.
But the timescale still gives me pause… just because AI lets us convert a codebase in 6 days doesn’t mean it’s wise. There are surely a lot of downstream implications! It’s always felt a little like Bun is making up a plan as it goes along (and maybe that’s unfair), this seems to underline the point.
In addition, a core Zig developer has explained why the PR was rejected, because it would introduce non-deterministic bugs into the compiler, just to achieve a speedup Zig is already gaining thanks to recent work on the self-hosted backend and incremental compilation, which are far more general as well.
As expected, Modula-2 / Objective Pascal like safety was great during the last century, before automatic resource management, and improved type system became common in this century.
Naturally also have to note, wasn't this supposed to be only an experiment, nothing serious?
The LLMs are quite good at re-writes and even better when provided an 'oracle' like a well rounded test suite or existing implementation to work against.
Its part of the reason we keep seeing "I rewrote <library> in <language>" posts on hackernews and when you look at the repo its more like I prompted claude to rewrite this repo in rust or whatever.
Bun powers Claude.
And on the seventh day Claude ended His work which He had done, and He rested on the seventh day from all His work which He had done
More interestingly: will we need to care about the code at all, at that point?