Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • So I can't tell if the linked commit is an actual attempt or just an experiment but it did always strike me as odd to make a JS runtime in Zig when my impression was there were a lot of work-stopping compiler bugs at the time.
    by inkysigma
  • Considering no public announcement this is just an experiment, possibly leaked.
    by ivanjermakov
  • Picking a pre 1.0 language to build your product always seemed like a bad choice to me. Purely on that basis and ignoring the recent drama this seems like a reasonable idea for tech debt pay down to me. Assuming automated conversion can work without making things worse, which is not exactly a given.
    by padjo
  • Partially, the team would have never expected the project to be acquire before Bun touches v1.0.
    by esjeon
  • > Picking a pre 1.0 language to build your product always seemed like a bad choice to me.

    Such as React Native? :D

    by xigoi
  • Why? Are there particular reasons that the maintainers of Bun feel the need to attempt to migrate from Zig to Rust?
    by yladiz
  • If the computer can do it for them, then why not?
    by tom_
  • Probably an experiment due to Bun's PRs to Zig being rejected (Zig does not allow AI use). If Rust works well enough, and the alternative is maintaining a fork of Zig, I'd guess they'd go with Rust.
    by reissbaker
  • Zig is a moving target that has breaking changes in every release (which is fine as they are sub-1.0). But that means that AI tools have been trained on outdated syntax/etc. Zig isn't that common, so there is even less training data to begin with.

    Rust on the other hand is pretty established by now and has less breaking changes. It also has more compile-time safety-guarantees that makes vibe-coding a bit more confident.

    In top of that, Zig has rejected their upstream contributions. So they'd have to maintain their own compiler in the long run, which is probably just technical debt to maintain.

    by nikeee
  • Possibly related to https://simonwillison.net/2026/Apr/30/zig-anti-ai/ where the Bun team wanted to upstream work to Zig that was rejected by a blanket anti-LLM contribution policy.
    by _--__--__
  • Why not rewrite claude-code in Rust?

    So, Anthropic acquires Bun team because claude-code uses Bun. They port Bun from Zig to Rust presumably because Rust "is better" (imagine big air quotes here). Again presumably, they want to make claude-code "better". Why make it so complicated? With all the power of LLMs they have, surely they can make claude-code the best possible by writting it in Rust directly.

    by selectnull
  • "You are absolutely right! Would you like me to delete Bun and rewrite Claude Code in Rust instead?"
    by mirekrusin
  • Because afaik claude code is react rendered as TUI. They must really want react. I guess that happens to ones brain on too much ai
    by Perz1val
  • Presumably they aren't falling for their (extremely obvious) "grassroots" marketing, and know, like any good engineer, that LLMs are not the right tool for this.

    It's easy to just see Bun as a marketing stunt, as well.

    by lionkor
  • I want zig to succeed but given that zig is not yet 1.x I'd imagine a large code base like bun would have difficulties addressing major breaking changes. Also given the fact that bun is using a fork of zig https://x.com/bunjavascript/status/2048427636414923250?s=20
    by jr-14
  • Given the recent gripe that Bun/Anthropic indicated regarding compile times with Zig (i.e. that their vibe-coded 4x compilation speedup PR wasn't accepted), it appears to me as an "interesting" move to switch to a language that probably delivers 4x longer compilations than even vanilla Zig.
    by carpenecopinum
  • I am very sceptical zig actually compiles faster than rust.

    I had similar code written in zig and c++ and cold compilation was many times faster in c++ and incremental compilation was instant in c++.

    I think the reason most rust projects compile slow is because of excessive usage of dependencies and also the excessive use of metaprogramming in code.

    Zig doesn’t have multiple compilation units so it doesn’t parallelize compilation

    by ozgrakkurt
  • I'll be very interested in how this AI port turns out. I am involved in a number of active projects that are being held back by the language / framework is holding back the project, but where a rewrite would be too big of a project to undertake by using only human power.

    I've had more success vibe coding Rust than I have in more dynamic languages. I suspect the strictness of the Rust compiler forces the AI agent to produce better code. Not sure. It could be just that I am less familiar with Rust so it feels like it's doing a better job.

    by Humphrey
  • Yes it generates trash Rust code.

    > Not sure. It could be just that I am less familiar with Rust so it feels like it's doing a better job.

    Ya think?

    by rustybaritone
  • > It could be just that I am less familiar with Rust so it feels like it's doing a better job.

    Dunning Kruger effect. At least you admit it.

    by moomoo11
  • I've been targeting Go instead of Rust for a few things. But same deal, I'm not really a Go programmer and it seems to work well enough. I do have a few decades of engineering all sorts of code bases; so I'm not coming at this completely naively.

    My way of compensating for my own inability to do detailed code reviews is making sure the tests, integration tests, end to end tests, cover everything I care about. Without that, you can't be sure it is not skipping detail work. I've also made it do some bench marking and stress testing and then analyze the code base for potential bottlenecks. After it found and fixed a few issues, it got better. Finally, prompting it to do critical reviews, look for refactoring opportunities, etc. can give you a nice list of stuff to fix next. Having it run memory leak checkers and static code analysis tools also is a good strategy. Once you start running low on issues you find this way, the code is probably not horrible. Or at least you hit some sort of local optimum.

    The lack of code reviews sounds pretty horrible. But it is now quickly becoming the biggest bottleneck in AI assisted coding. Eliminating that bottleneck is scary but it enables a few step changes in volume of code that becomes possible. Using strict compilers and strict memory management helps eliminate a few categories of bugs and issues.

    I was previously doing this with languages I do understand. Once you start routinely dealing with larger and larger commits, reviews become a problem.

    I expect working with larger code bases like this will get a lot easier and better over time. I noticed that the main headaches I face with this type of engineering are the tendency of models to keep deliberately cutting corners, only doing happy path testing, or deferring essential work for later. I suspect a lot of the models are simply biased to conserving token usage. Pretty annoying but also easy to compensate for with follow up prompts and testing. And probably something that becomes less of an issue as the models get tuned to behave better without additional prompting.

    by jillesvangurp
  • Rust is a good choice to let LLMs run without a ton of supervision. In my experience you need to monitor the progress heavily and take ownership of the design of the thing you're building or porting. Test harness is a must. Each iteration should run the test and ensure it doesn't break things in other places.

    I am in the middle of porting TypeScript to Rust and learned a ton doing this. You can check out the work in progress here https://github.com/mohsen1/tsz/

    Happy to share my learnings on this

    by mohsen1
  • I wonder if a successful, albeit slower, approach would be to walk the git commit history in lockstep, applying the behavioral intent behind each commit. If they did this, I would be interested in knowing if they were able to skip certain bug fix commits because the Rust implementation sidestepped the problem.
    by tacitusarc
  • Interesting idea
    by lll-o-lll
  • Many segfaults in Bun issue tracker. I bet it would sidestep many.
    by nicce
  • this is an interesting idea and i might try it with something smaller. there are more than 15,000 commits to bun, so you’d have to have some sort of way to operate on groups of commits in one prompt to get that done without thousands and thousands of api requests
    by efficax
  • Linked commit is probably not the most convincing for this tagline. Here's a branch[0] of Claude mass rewriting Zig code into Rust which is currently at 773,950 additions and 151 deletions:

    [0]: https://github.com/oven-sh/bun/compare/claude/phase-a-port

    by archargelod
  • I was curious how much work this would be. Here are the top five from cloc:

        -------------------------------------------------
    Language      files    blank    comment      code
    -------------------------------------------------
    Zig            1298    79693      60320    571814
    TypeScript     2600    67434     115281    471122
    JavaScript     4344    36947      37653    290873
    C++             583    27129      19117    215531
    C               111    21577      83914    199576
    by dsissitka
  • Yikes. When Jarred left Stripe for the first time, he left behind multiple 10k+ line PRs rewriting code in the dashboard (this is before LLMs). It took months to work through those. A three quarter million line diff is essentially unreviewable.
    by bastawhiz
  • Interesting how times have changed. Back in 2015, the entire Go runtime (already a mature codebase) was rewritten from C to Go semi-automatically: one of the maintainers wrote a C-to-Go conversion tool (for a subset of C they used) so that it compiled and produced identical output, and then the resulting code was manually refactored to make the Go code more idiomatic and optimized. And now you can just ask a language model.

    The slides: https://go.dev/talks/2015/gogo.slide#3

    An interesting similarity:

    >We had our own C compiler just to compile the runtime.

    The Bun team maintain their own fork of Zig too

    by kgeist