They recently tried to upstream an improvement to zig, but were prevented from doing so because zig has a hard and fast "no AI code" rule. Whether you think this response is trying to put pressure on zig or whether they're just moving for practical reasons is up to you.

It's probably a bit of both.

> what looks like a massive undertaking for vibe coding

fwiw, I suspect it's less of an undertaking than you may think. I've been playing with AI to rewrite Postgres in Rust[0] over the past couple of weeks and I found the AI to be exceptional at doing rewrites. Having an existing codebase you can reference prevents a lot of the problems you have with vibecoding. You have an existing architecture that works well and have a test suite that you can test against

Over the course of a month I've gone from nothing to passing over 95% of the Postgres test suite. Given Jarred built Bun, I bet he'll be able to go much faster

[0] https://github.com/malisper/pgrust

I do not know if there's any overlap between these teams, but it seems like Anthropic itself is fairly invested in the Rust ecosystem.

They recently proposed some of their internal tools to be the official Rust implementation[0] of Connect RPC[1]. As a protobuf based library set, this includes a new Rust-based protobuf compiler, Buffa[2].

[0]: https://github.com/orgs/connectrpc/discussions/7#discussionc...

[1]: https://connectrpc.com/

[2]: https://github.com/anthropics/buffa

I imagine claude is better at Rust than Zig?

The industry does not shape bases on HN top posts, nor media buzz. Remember youtube birth. Necessity, available tech, fresh talent.

I believe now we have all but we fail at choosing.

But why should they? This just seems like the groundwork for an initial refactor and moving from one language to another. They haven't actually committed to switching from Zig to Rust yet. I mean, I get if you are an investor and you want to see if they are using their time effectively, but why would it matter to anyone else?

Honestly, this kind of thing seems to work quite well with vibe coding. If I remember correctly, the Ladybird JS engine was "vibe-ported" to Rust as well, and it passed 100% of the original test suite, in addition to new Rust tests.

> what looks like a massive undertaking for vibe coding

It doesn’t look like that at all. Do you think that all use of AI is vibe coding?

Porting from one typed language to another seems like a perfect use for LLMs. I can see the appeal of both languages and why to consider such an action (e.g., rust is a mainstream PL vs zig's cult status (no slight intended)).

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

This prompt defines the translation as a file for file, line for line port. Seems like historical knowledge will be fine.

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

Interesting idea

... and that bug was spotted in the canary release, reported and fixed.

Sounds like responsible open source software development to me. That's what pre-releases are for.

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?

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.

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.

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.

If the computer can do it for them, then why not?

the rust port (at least currently) heavily uses unsafe as well

https://github.com/oven-sh/bun/compare/claude/phase-a-port#d...

that isn't particularly surprising, but the point is I would expect getting things more stable than the zig version would take a bit.

I think it reflects more on Bun. [1].

[1] https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...

Yes, it's quite ok to not "retract" a goofy image from months ago. It's harmless fun.

Watch your mouth.

Exactly, this is a direct response to Zig refusing to accept pull requests from Bun (and Anthropic). That situation forced Bun to maintain a fork of Zig, and it makes sense in the long term that they'd rather port their entire project to Rust.

I've really enjoyed Bun the past year or so, but the acquisition by Anthropic, Bun's codebase and documentation increasingly becoming AI slop, and this impulsive complete rewrite - all of it has ruined it for me and I'm actively moving off of Bun. I don't feel comfortable relying on it any longer.

Ghostty is mainly Zig aside from the UI parts.

That TigerBeetle database I think.

It's not really shunned - it's the standard solution for async in Rust - but it's not the right solution for every project, especially if you have specific requirements for how your project's computation should be scheduled. I would guess that Bun is one of those projects, especially as it needs to be able to schedule JS async work itself.

The answer is in the next sentence: "Bun owns its event loop and syscalls." They clearly want to manage their use of threads explicitly, which is not _unusual_ for systems programming but probably less common. Note that `rayon` is different from most of these in that it has nothing to do with async Rust - it's a tool for spreading computation over a thread pool, very popular in non-async projects, but it would also go against their goals here.

tokio is great and it's pretty performant, but you pay an allocation for every future unless you do some complex organization of your futures.

Source: I worked on Deno, competed directly with Bun on HTTP performance (and won on some metrics).

Edit: and of course I typed future instead of task (aka "spawned future"). Thanks, child commenters below. Much of Deno was built on spawning futures that mapped to promises and doing it as fast as possible. I spent ages writing a future arena to optimize this stuff..

It's an async runtime. The whole async-await flow removes a little bit of scheduling control and adds some forced memory management in order to give you some nicer code in an application case, but if you're trying to build a runtime yourself I think you'd much rather retain control in this case. It's just hard to reason about.

You much rather have this runtime you're building manage task scheduling and allocation and all that. It's the most natural design choice to make.

In pretty much every bit of code I've written both professionally and leisurely I have always used tokio.

However, there are reasons why you might not want to use it:

- You don't need async at all

- You want to own the async execution polling completely

- You want some alternative futures executor like io uring (even though tokio-uring is a thing)

Tokio is a general purpose async runtime. Much the same could probably be said for async-std (except IIRC they do have a barebones reactor for you to build your own on). In general, a general-purpose async runtime will do worse for highly specific tasks than a purpose-built one (especially e.g. NUMA).

I think avoiding async entirely might be a mistake, and I'm not entirely convinced anything better than a general-purpose async runtime might exist for a JS runtime (it itself is general purpose after all).

Avoiding std::fs is fucking bizarre to me: it's completely sync and is a really lightweight abstraction over syscalls.

You shouldn't have to pull in big complex dependencies to do what should be primitive things. Zig is putting a strong and thought-out effort into getting async & parallelism "right" inside the stdlib. I'm honestly not up to speed with where rust is at with it at the moment, but last time I checked it was a bit of a mess.

You try to use it you'll get it. Otherwise it's just words. Like these: rust failed at async.

Async is much harder to work with than sync+threading is. And while threads have more overhead in theory, in practice almost nobody is writing applications at such a scale where that overhead actually matters. So I don't blame them for eschewing async, there's likely no benefit for the project in it.

Async is an anti-pattern but sometimes inexperienced developers don't realize that and will infect your codebase with it.

I don't think problem ever is Rust, Rust is by far the best systems programming language.

Problem is fanboys like YOU.