Rewriting Bun in Rust

795 points by afturner 53 days ago | 534 comments

didibus 53 days ago |

Article did a decent job of showing discipline and care and human involvement to assert the automated rewrite was done diligently, as best as it can be when using AI for it. I does make me feel a bit more comfortable about it.

As an aside, I don't know why anyone would not want to use a memory-safe (and possibly race-safe) language in 2026. Rust gives you that in a performant package, so if you are turned off by GCs and immutability for performance reasons, you still have the option to use Rust.

I can understand when you need the absolute best performance and you decide to drop to down to C++, and I also relate with just personal preference, but beyond those it seems a no brainer to me.

leecommamichael 53 days ago | |

> As an aside, I don't know why anyone would not want to use a memory-safe (and possibly race-safe) language in 2026.

The rust compiler is very slow. The best way to speed it up appears to be organizing a codebase in many crates. This is not preferable ergonomics to many. Beside that, for many problems, a garbage collector eliminates a large amount of defects (including the ones stated in the article) without any added friction, whereas Rust asks that you think in terms of ownership. This is not preferable ergonomics to many.

I realize what I'm saying above, while true, doesn't give a clear example. Many gamedevs would rather iterate with a language that is lower friction, not only because game code is finnicky (like frontend UI code) but because the build process can be unique. Many gamedevs prefer to iterate with hot-reloading, and asking them to use a slower compiler is asking them to accept greater latency in that cycle.

I do not claim that these reasons apply to everyone.

zamalek 53 days ago | | |

Game engines are typically in two languages, one for the engine itself and one for scripting. That even goes for Unity: in Unity, C# is a significantly more powerful than average scripting language (for lack of a better term), but the engine itself is still C++.

That's not to say that you couldn't write a commercial game engine with something like C# that stands shoulder-to-shoulder with unity and unreal, but it doesn't seem like anyone has attempted to do so. Maybe it's the decompilation fear.

Also, it would continue to make sense to use a scripting language alongside Rust.

kibwen 53 days ago | | |

> The best way to speed it up appears to be organizing a codebase in many crates.

A "crate" in Rust is the unit of compilation. In C, a file is the unit of compilation. Rust just lets you have a compilation unit that's composed of more than one file (without having to resort to C-style textual inclusion). But if you want, you can certainly have one-file-per-crate, just like you would in C. And what's nice about having many crates is that crates forbid circular dependencies, which trivially enables coarse-grained parallelism in the build system. So yes, organizing a large codebase into crates is the best way to achieve parallelism, but that isn't something to be deplored (and strictly controlling circular dependencies is useful for comprehending large codebases in general).

stymaar 53 days ago | | |

> The rust compiler is very slow.

It's not “very slow”, that's a tired meme. It's slower than it could/should, but complaining about rustc being “very slow” is a clear misrepresentation, especially when everybody seems to have been fine with tsc's historical performance for instance. It could be nice if it was faster indeed, but people claiming it's “very slow” are just showing they never worked with it.

> The best way to speed it up appears to be organizing a codebase in many crates. This is not preferable ergonomics to many.

In this context (where you don't plan on publishing you stuff on crates.io) a “crate” are just a directory at the root of your repo, the ergonomic impact is literally zero.

gpm 53 days ago | | |

The comment you're replying to wasn't arguing rust > GCed languages (e.g. C# or whatever game dev language you are thinking of). It was arguing rust > non-GC non-safe languages (e.g. zig).

IshKebab 53 days ago | | |

> The rust compiler is very slow.

It was very slow. It's gotten a lot faster over time (over 2x faster). It's still not exactly fast, but it's definitely faster than C++. Although C++'s slow compile times are often complained about they were never really enough to stop most people using it, including for games.

> a garbage collector eliminates a large amount of defects (including the ones stated in the article) without any added friction

I'd be careful about that "without any added friction". Rust's lifetime/borrowing system tends to lead to less buggy code because it encourages structuring code in a less spaghetti way. GC does eliminate memory errors but you also lose that non-spaghetti code structure.

vlovich123 53 days ago | | |

For what it’s worth game devs often use C# or C++ engines which have even worse issues. Rust also has the early beginnings of hot reload which bevy adopted if I recall correctly [1]. I still think a higher level language is good for “business” logic to orchestrate how efficient low-level pieces connect, but Rust is holding its own even against those use cases IMHO.

[1] https://docs.rs/hot-lib-reloader/latest/hot_lib_reloader/

thayne 53 days ago | | |

> Beside that, for many problems, a garbage collector eliminates a large amount of defects (including the ones stated in the article)

Languages with garbage collection are generally considered "memory safe". GP was talking about choosing a language that requires manual memory management, but doesn't have something like rust's lifetimes to catch things like use-after-free.

psychoslave 53 days ago | | |

Hey thanks for teaching me a word today, and to be finicky myself, the convention seems to be to use a single n it. :)

Gigachad 53 days ago | |

I've observed that dumber models are able to vibecode in safe languages a lot easier since the compiler errors can self correct the models hallucinations, while they end up marking a task as complete in dynamic languages despite it not actually working.

If I'm vibe coding something I'm always just going to do it in Rust.

sneak 53 days ago | | |

Agree 100%. Almost everything I have written with AI is in Go, and strong typing is really really nice (as is go vet and golangci-lint to keep the generated code in line).

I imagine writing plain js or python with it would be much much riskier.

flohofwoe 53 days ago | |

> and you decide to drop to down to C++

Going from Rust to C++ seems a strange choice, since you get most of the same problems just without memory safety. Zig, Odin, C3 or even plain old C though? At least those languages have things to offer that neither Rust nor C++ provide (and if it's just compilation speed).

pjmlp 52 days ago | | |

Market share, IDE and graphics tooling, and industry standards.

LLVM is not going to take PRs written in Rust to fix the Rust compiler backend, for example.

Neither are OpenJDK, .NET, V8, JSCore going to take such PRs.

By the way, LLVM and GCC would also not take PRs written in C.

henry_bone 53 days ago | |

I'll bite. The first language I could "just write" in was C. I had internalised the language and its standard lib and didn't need the internet to work with it.

Rust is pushed by many as the replacement to C, because of the memory safety guarantees. I'm sympathetic. I worked with Haskell for a time, so I get it. But Rust seems quite complex. There are so many language features that there's memes about it. There's also the friction and learning curve.

So, for fun, I choose zig because, like C, I can hold most of the language in my head and "just write." I choose zig because it does a great deal to help me write correct and highly performant code. I can use arena allocators and defer and cure my code of many memory issues. Then there's the various language rules around pointers (optionals, slices, etc) that help me write correct code. There's the built in testing and the test allocator. I love that comptime and the build system are not special cases, but rather are just garden variety zig. I love the simplicity and elegance of it all.

I also choose zig because I prefer the liberty it affords me. I am responsible for each and every allocation. It appeals to my libertarian sensiblities.

baq 53 days ago | | |

> The first language I could "just write" in was C. I had internalised the language and its standard lib and didn't need the internet to work with it.

I bet $4.20 you didn’t write C. You wrote something C-like which the compiler didn’t reject because the C standard has a gigantic surface of ‘undefined behavior’ which means once your program does one thing out of spec it isn’t C anymore silently.

kibwen 53 days ago | | |

> There are so many language features that there's memes about it.

Like many memes, these are misleading. Rust is a solidly medium-sized language; smaller than Python, certainly, though with a perilously steeper learning curve than Python.

pdimitar 52 days ago | | |

Of all the things I expected to read today on HN, "I chose a programming language that appeals to my political leanings" was certainly not one of them.

josephg 53 days ago | |

> I can understand when you need the absolute best performance and you decide to drop to down to C++

Rust is just as fast as C++.

lionkor 53 days ago | | |

It depends just how fast you need it. C++ is much easier to get to zero abstraction code.

In Rust you are constantly fighting the stdlib and other libraries, and you have to litter your hot code with unsafe blocks to get it to stop adding a branch to nearly every object access, be it for bounds checks or over/underflow checks.

C++ does a much better job at giving you a zero abstraction API, and you can always drop down to raw pointers if you want, without(!!!!) unsafe blocks and weird tricks. Of course it's unsafe in C++ but the friction to writing a branchless hot loop is muuuuch smaller.

When profiling and optimizing Rust code, I very often find myself poring over the generated code, making small changes, reading api docs, and trying again, much more than in C++. Lots of unsafe Rust APIs are not even nearly good enough, even with most checks turned off you will find branches that just branch to panic!(), which is, you guessed it, still more code and a branch than the code would suggest.

I get why people think that most systems languages are the same "speed", but they really are not if you are hitting limits of the hardware in your hot loops.

yukIttEft 53 days ago | | |

Is it though.

There are so many situations where something is guaranteed to be safe but there is no way to express that in the Rust typesystem, so the only thing you can do is to wrap everything in Arcs and Mutexes, which introduces allocations, pointerchasing and locks

m00dy 53 days ago | | |

yeap, unfortunately, only few can see this.

frizlab 53 days ago | |

My personal memory and concurrent-safe option is Swift. And I agree, choosing a non-memory safe language for a new project is close to irresponsible today…

pjmlp 52 days ago | | |

Sometimes we have no option, given the industry standards that expect C or C++.

Khronos, Open Group, NVidia, Microsoft, Sony, Nintendo... aren't going to change their APIs and SDKs, just because of social media discussions on the merits of C, C++ vs other safer alternatives.

I agree we should minimise their use, however not everyone accepts a dual language approach, nor there are alternatives in such domains, even if they technically exist, you still need to overcome the human and political factors.

Hence why it is so relevant to fix C and C++ security flaws to some extent as well.

rootlocus 53 days ago | |

Im constantly surprised by the disk size required by rust builds. It takes over 50G to compile zed IIRC.

egorfine 53 days ago | |

> and human involvement

Isn't ironic for a project that successfully killed all past and future human involvement?

testdelacc1 53 days ago | |

> I can understand when you need the absolute best performance and you decide to drop to down to C++

Could you help me understand with an example or two? My understanding is that well written Rust and C++ are often identical in performance thanks to relying on the same compiler backend (both clang and rustc use LLVM).

aldanor 53 days ago | | |

Even, possibly, the other way around in some cases. A seemingly identical program may (and it does occur) compile to a faster machine code in rust than in C++ due to extra markers (eg alignment) that rust compiler is able to provide to llvm.

andrepd 52 days ago | |

This comment makes no sense. For one, "you need the absolute best performance and you decide to drop to down to C++", no, C++ and Rust are virtually equivalent in that they pretty much expose the underlying machine fully; if anything Rust makes it easier to write idiomatic performant code.

For two, there are plenty of reasons to use C++ unfortunately: compatibility with existing code based and availability of developers to name two.

pjmlp 53 days ago | |

The main reason to use C++, and Rust compiler also falls into it, is existing infrastructure, SDKs and industry standards.

I would love that Java and .NET would provide all layers like several managed languages in the 90's,

However it has taken a quarter century to get back features we already had in Modula-3, Mesa, Oberon and co.

canbus 53 days ago | |

People get attached to things they've been using for decades. Also most of the world is still written in c/c++ so any critical mass has quite a lot to go up against.

Rust isn't perfect but it solves a lot of the pitfalls of C++ (not just UB, package management, horrible cmake files, linker errors etc.)

randypewick 52 days ago | |

Rust is C++ like language, with more safety. It makes no sense to say that to get performance one can drop down to C++. As far as I am aware, you can get as fast as C with Rust. Of course, that might mean to compromise on something, some bound checks, some code ergonomics, or something else. You can write ASM in Rust, so it really gets as low level as it gets. And what I find amazing is that, similarity to C++, you can get both low level and high level code in the same language. And this is intrinsic in the language complexity: if you take a simpler language with a less powerful type system (C-class languages), you lose this ability.

xiaoyu2006 52 days ago | |

Ownership is a very limiting coding constraint, and bypassing methods, when ultimately needed (e.g. cell), cannot be engineered to be ergonomical.

fulafel 53 days ago | |

Fortunately there are also many other memory safe languages to choose from.

sitzkrieg 53 days ago | |

rust is still a non starter in some niche embedded applications (way too big). i still write c and assembly constantly.

steveklabnik 53 days ago | | |

> way too big

https://github.com/tormol/tiny-rust-executable

This produces a 137 byte binary. Obviously AMD64 isn't used in embedded, but I've seen ARM ones that are in the ~256 range.

It's all in how you use it. Of course, if you don't care about binary sizes, they can get large, but that's very different than actually paying attention to what you're doing.

swiftcoder 53 days ago | | |

> niche embedded applications

How niche are we talking? Rust is deployed on a bunch of popular microcontrollers at this point

OtomotO 53 days ago | |

> I can understand when you need the absolute best performance and you decide to drop to down to C++

What? Rust generally doesn't have worse performance to C++, so this argument makes no sense at all to me.

> and I also relate with just personal preference, but beyond those it seems a no brainer to me.

That's another argument altogether.

It's totally fine to have preferences and decide to go with them of course.

ryukoposting 52 days ago | |

tl;dr: my job requires me to do things where Rust's memory model can't save me.

https://news.ycombinator.com/item?id=48833867

rvrb 53 days ago | |

that you understand and think dropping down to C++ is what you need to do when you "need the best performance" is quite enough of a tell to invalidate the rest of your opinion here. if you "need the best performance", you need to ditch OOP and RAII, and you're probably reaching for C. Zig wants to be the better choice there. that's a perfectly reasonable niche for a language to exist in.

if you read the article carefully, jarred is pretty clear about how their specific requirements with Bun cause friction when bridging the manual memory management of Zig with a garbage collected JS runtime. at face value, that makes quite a lot of sense to me, and it's a pretty specific scenario that is not the full on condemnation of memory unsafe languages that your comment is.

gmadsen 53 days ago | | |

It is widely accepted that you can get better performance with c++ far easier than C. Outside of custom rolling assembly , a large aspect of performance tuning is compile time optimization, which is extremely non trivial in C, while being supported in language with C++. All the things people associate with C performance can be done in C++, the converse is not true

remexre 53 days ago | | |

the point of c++ when you need max perf is to be able to maintain the compile-time abstractions you need w/ templates instead of macros and undocumented optimizer behavior, not oop or raii

sashank_1509 53 days ago |

I think the important thing is this is much cheaper than hiring a software engineering team. They could have hired me for 200k and I could not do this in a year. I do not have the context, and I do not know Zig or Rust, perhaps I could pick it up in a month, but I would be extremely slow.

Forgetting all the predictions about singularity etc, at the very least AI as it is now, is going to make it very hard to justify hiring a SWE for 200k. I will say, at the very top for a software heavy company like Google or Anthropic, they will still hire excellent engineers to create new software that AI is not very good at.

But for companies where software is simply a cost center. Like Walmart, or Target, companies that were already outsourcing software development, or using cheap H1bs, now they have the alternative of AI which is much better than even hiring an average software engineer for 200k. This is a sea change in the job market, it’s going to have a pretty big effect as it is right now. US has around 1.6 Million software developers, this number is going to get cut drastically, the very top, say an L6 quality in FAANG will be fine, the average in a no name Bank, or the guy building the website for McDonalds is out, he needs to learn something else or he’ll end up without a job soon.

I would not have predicted this a year ago, now it seems clear that this will happen. Just shows how much of a sea change we have witnessed just like that.

Philpax 53 days ago |

Without commenting on Bun itself as a project, or the nature of the rewrite, it can't be good for Zig that a naive rewrite away from it fixed memory leaks, improved stability, shrunk binary size by 20%, and improved performance by 5%.

dabinat 53 days ago |

> This Rust rewrite would've taken a team of engineers with full-context on the codebase a year of work. With 1 engineer using Fable & closely monitoring Claude Code, we went from start to 100% of the test suite passing on all platforms in 11 days.

This is impressive from a technological standpoint, but it does gloss over the fact that it would have cost $165k in tokens were Bun not part of Anthropic.

The comparison here isn’t completely fair - it would take a small team a year to port it if they spent $0 extra on it.

I’d be interested to see a comparison between spending $165k in 11 days on Claude vs splitting that between 50 people over 11 days for a line-by-line rewrite of the Zig code. I suspect Claude might be faster and therefore cheaper, but maybe not by a lot.

padjo 52 days ago |

It's very odd how quickly people fall back on emotional claims to attack this. Like we're engineers, if you can point at concrete problems with this rewrite I'd love to hear them. Obviously Jared is going to give the positive case, saying that he's doing that doesn't prove the rewrite is a bad idea. You need to point at objective problems, not your vague sense of unease. As it stands, by all available measures, this appears to have been a massive success, which is absolutely remarkable.

matklad 52 days ago |

To add more context around lifetime errors and TigerBeetle's particular style guide:

>Many projects opt to answer these kinds of questions through a style guide. TigerBeetle's TigerStyle is an example in Zig and Google's 31,000 word C++ style guide is another. The challenge with style guides is enforcement.

TigerStyle[1] is a bit more than just a style guide. The key rule for this discussion, uplifted straight from of NASA[2], is *static memory allocation*: all memory is allocated in the startup phase, and there's absolutely zero `alloc`s afterwrads . This plus crash only[3] design means that we never call `free`.

This rule is self-enforcing and compositional, in Zig. There's no global memory allocator, so the code after startup simply hasn't the API to allocate. You can't circumvent this by accident. Of course, if the programmer is byzantine, they can stuff allocator in the global, or just directly `mmap` and `unmap` pages of memory, but, at our scale, we don't have problems with that. This is a similar in kind (not degree) to Rust, where untrusted code generally can circumvent safety guarantees, even without literally spelling `unsafe`.

And, naturally, never `free`ing goes a long way towards solving many memory errors by construction. Empirically, they just haven't been a problem for TigerBeetle. It's hard to untangle contribution of static allocation in particular from everything else we are doing, but it would make sense for it to play a leading role.

(As a footnote, we aren't actually do static allocation to avoid memory errors, we use it as a linter to check that every quantity has a known _logical_ static limit, the main property we care about)

[1]: https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/TI...

[2]: https://spinroot.com/gerard/pdf/P10.pdf

[3]: https://www.usenix.org/legacy/events/hotos03/tech/full_paper...

pier25 53 days ago |

Personally I don't care that they used AI to rewrite Bun to Rust. Even if 1.4 is not good enough it will probably get better over time.

What has pushed me back to Node is seeing how amateurish the transition has been handled.

- No LTS support for the Zig version regarding CVEs etc.

- Huge bugs like the 3MB memory leak mentioned in the blog post abandoned in the Zig version to basically force people into the Rust version to fix their apps in production.

- Zero involvement with the Bun community about such a major decision. One day it was "stop the drama I'm just playing with this" and a couple of days later "yolo merged to main".

Jarred basically keeps operating as if he was a lone hacker working on his personal project.

theLiminator 53 days ago |

That's the power of a strong test suite. LLMs excel when you have verifiable rewards. I imagine we'll get a lot more rewritten in rust projects in the future. Rust is also an ideal target for such rewrites as it offers a lot of verification (via its type system) and is low overhead with zero-gc. There's less and less reason to use GC'd languages in the agentic coding era.

I think Rust is a locally optimal target for LLM coding, we might see a better language in the future, but I think Rust will dominate for quite some time.

lifthrasiir 53 days ago | |

> There's less and less reason to use GC'd languages in the agentic coding era.

Faster iteration, maybe? Rust's safety guarantee isn't exactly free (while still being very excellent) and does affect iteration time. I have a private project (>300K LoC) that has been translated from Python to TypeScript and the reason we couldn't use Rust was definitely the iteration time.

talloaktrees 53 days ago | | |

I like using Odin with LLMs for this. it's a simple statically typed language with no GC and very fast compile

gpm 53 days ago | | |

Eh... rust's safety isn't free, but not having it and wasting time on "oh I forgot to change this call site" also isn't free. On the whole I'd say the safety assists in iteration time.

What costs rust in iteration time in my opinion is the low level (by default) nature of it. There's a faster-to-iterate language that has yet to be created which is rust but we sacrifice performance (and memory fiddling ergonomics for the odd person who does that) so we don't have to worry about things like whether a variable is stack or heap allocated. Which is in the direction of a GCed language but retains the mutable-xor-aliasable semantics.

Between rust and current GCed languages though... I guess I agree with "maybe" in both directions.

dwdz 52 days ago |

"The blog post is expertly written. It's almost like the marketing department of a trillion dollar company has a lot of money riding on this article."

-- Andrew Kelley

https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...

jjice 52 days ago | |

Without accusing anyone of anything, I do think that this coming from the head of Zig, who gets a lot of negative publicity from the Bun rewrite (unjustifiably, it's a wonderful language) makes it harder for me to take this without wondering if there's some animosity that's really the main complaint.

> Two, I actually don't have any personal criticisms of Jarred

The author says two things that really popped out to me that you could say are "professional" and not "personal" criticisms, but I think they're still rude and contrast this statement.

> Jarred was already writing slop well before he had access to LLMs

> The grapevine was large and healthy and full of juicy grapes, and all those grapes contained the juice of the same message: Jarred was a stinky manager. Poor communication, unrealistic expectations, low empathy, no experience

Now, both of these may be true. I don't have any evidence though, so I don't know how to take it.

All this to say, I'll take both of these posts without a ton of salt when it comes to the non-technical parts.

losvedir 53 days ago |

In what ways does Anthropic use Bun? I know it's used as the "runtime" for Claude Code, but rather than porting a million lines of Zig to Rust, why not just port Claude Code to rust and not need to bundle a JS runtime at all? Does Anthropic use Bun otherwise? Maybe for JS execution tool calls in Claude responses?

atonse 53 days ago | |

I’ve wondered the same. Especially because codex is written in rust.

Why not just port Claude code over.

But my guess is that maybe it doesn’t have as robust a test suite?

This might embolden them to do it…

rane 53 days ago | | |

It's extremely difficult to have a robust test suite for a TUI app like Claude Code. Hence regressions keep showing up in every update.

KronisLV 53 days ago | | |

> But my guess is that maybe it doesn’t have as robust a test suite?

Not sure about what's going on over there, but over the last year Claude Code has gotten way better, I sure hope that they're working on a good enough test suite to avoid a crapload of regressions (and pave way for more refactoring, should they need it).

hansvm 53 days ago |

Every time I've rewritten a major project I've made it smaller and faster while fixing all the major bugs and most of the minor ones. My current team has had similar experiences. I'd be curious to see what a Zig -> Zig rewrite of the same magnitude would have done for quality.

nzoschke 53 days ago |

> Historically, rewrites are a terrible idea.

This changed for me over the last 5 years.

The first scenario was joining a company where a software product barely worked. We did the traditional incremental refactoring / rewriting, but eventually learned how rotten the core was that rewriting from first principles was the best path forward.

The lesson learned here is that the conventional wisdom probably only applies to rewriting complex but working systems.

Then multiple scenarios in the agentic coding age. Between day jobs and hobbies I've reproduced major chunks of complicated software like Salesforce, Gmail, Pioneer Rekordbox with very lean teams.

Much like the blog post, the trick is to get an excellent verification loop with a compiler, linter, and test harness / test suite around the core behaviors.

It's feeling more and more that designing and implementing comprehensive test harnesses is the real work, once you have that let the LLM cook.

yomismoaqui 53 days ago | |

I think the same, it's possible our job will morph into "coding agent herders". In this case I guess the test harnesses, linters, workflows, etc will be our herding dogs.

Buttons840 53 days ago |

I've always felt [0] the people who created Bun had, as their first and foremost goal, a desire to use Zig--and that's great, I like Zig, I like when people build things their own way.

However, I've been skeptical of using Bun, because I want a project whose first and foremost goal is to build good tools that achieve the objectives of the project.

It reminds me of asking game developers: Do you want to build a game, or do you want to build a game engine? Building a game engine is fine, but if you're goal is to make a game, then building an engine is a poor way of achieving your goals.

Likewise, I've wondered if the creators of Bun wanted to build better JavaScript tools, or if they wanted to use Zig.

[0]: https://news.ycombinator.com/item?id=35970044

ameliaquining 53 days ago | |

So does that mean the rewrite made you less skeptical?

Buttons840 53 days ago | | |

Yeah, I guess. Now it appears to be a project run by Anthropic and I'm sure the real focus is on making money--which is still slightly different than having the focus be on making the best tool.

MrCheeze 52 days ago | | |

I mean, surely the main motivation for "use an LLM to rewrite a huge project in a new language" was excitement about the shiny new tech that made it possible.

thevinter 53 days ago |

One thing that I found interesting is that most of the discourse surrounding the topic happened with the assumption that the rewrite was happening with an Opus-like model, and not with Fable. Those assumptions, at least partially, were used as arguments against the fact that the rewrite was feasible and/or a good idea.

Clearly the model itself doesn't completely change the narrative, but at least as a note to myself, I would like to be more careful with assuming the capabilities of the models used internally by Anthropic and affiliated orgs.

cube00 53 days ago | |

> the assumption that the rewrite was happening with an Opus-like model, and not with Fable

I thought the same thing. Looking back, I was probably mislead in May when Jarred was explaining the pattern to "Rewrite every .zig file to .rs" as if it was something I could have done in May following his pattern. What he wasn't telling us was he was using pre-release Fable. [1]

A possible signal for next time is when we see an Anthropic owned company disabling the Claude Co-Authored-By trailer. [2] In an IPO year they have to take every chance to promote Claude unless it was something (Fable) that we weren't supposed to know about back in May.

[1]: https://xcancel.com/jarredsumner/status/2060050586024743376#...

[2]: https://github.com/oven-sh/bun/commit/23427dbc12fdcff30c23a9...

guardiang 52 days ago | |

Silly assumption, Mythos was available at the time. Benefit of the doubt should've gone to Jarred.

YuechenLi 53 days ago |

>Combined with the Rust rewrite, ICU changes, and identical code folding, Bun's binary size shrinks by ~20% on Linux & Windows.

People who are surprised by this probably has not seen what Zig code actually looks like. Zig's explicitness and lack of abstraction have a real cost that it is basically one of the most verbose programming languages I've ever seen, it's somehow even more verbose than Go. Basic features of modern languages like pattern matching and generics, and as you can see, having to manually clean up everything means that if you forget once, it's a memory leak. Having SOME abstraction is actually good if it prevents you from making mistakes.

Ironically, Zig is a programming language that's probably best written by LLMs, since they can actually tolerate the verbosity.

bel8 53 days ago |

> Claude Code v2.1.181 (released June 17th) and later use the Rust port of Bun.

It seems the reports of Bun's death have been greatly exaggerated.

waysa 52 days ago |

I tried Bun for a weekend around Christmas 2024. I quickly hit a bug that would freeze the runtime (issue #13237) when piping a stream into a file. I found that this had been open since August 2024, scrapped the experiment and moved on. The issue is open to this day. If the GitHub comments can be trusted, this behavior even carries over to the Rust port.

QuadmasterXLII 52 days ago |

Putting on my machine learning PhD student hat, the way to do this was to leave 10% of the tests out as a ‘test’ set and then once the port was done, bring them back in and find out how good the port is. The port may genuinely be good but because they spent 100k of compute hill climbing the whole test suite, “the test suite passes” now provides far less evidence that the port is good. Its weird that at Anthropic, a very ML phd company, no one pointed this out.

StriverGuy 52 days ago | |

Huh? This approach makes sense for non-deterministic problems. Not engineering problems that have deterministic end results.

QuadmasterXLII 52 days ago | | |

I’d want to estimate P(a random test passes) where the existing suite of tests is taken to be sampled from a distribution.

geraneum 52 days ago | | |

> non-deterministic problems

I'm guessing you mean probabilistic? Nevertheless, you have an indeterministic variable here which is what the LLM generates.

achristmascarl 53 days ago |

I was fairly skeptical about the rewrite when news about it first started going around, and I still don't plan on switching anything to use the Bun rewrite anytime soon, but I appreciate how detailed and well-written the blog post is; it also seems to be primarily human-authored, in my opinion, which is refreshing.

The most significant revelation for me was that Claude Code has been using the rewrite without much fanfare since June 17th.

smasher164 53 days ago |

It's still shocking to me that the approach taken wasn't to have Claude write a tool that translates Zig to Rust. I imagine it would've been cheaper, deterministic, and each iteration would produce a better tool.

PierceJoy 53 days ago | |

This seems like a much much harder problem than having a model translate between the two languages. I think people in general are way overvaluing determinism. In most cases, it doesn’t matter if the output from two runs is different as long as it accomplishes the desired goal.

shimman 53 days ago | | |

Never thought of cross language code mods to be a thing but surely there are libraries out there that deal with the interop of different ASTs across languages? Seems like an interesting area of research.

erichocean 52 days ago | |

That's the approach I've taken with a bunch of legacy OpenCL code I've mechnically translated to Metal, worked great.

pron 52 days ago |

Sounds to me like his choice of Zig was made in haste, as was his choice of Rust. If you find yourself changing a project's primary language more than once a decade (more like 15 years, but let's say a decade), the problem isn't the language but your technical decision process, and that's what you should look into first.

Some of the world's more important software - from browsers to the JVM - mix high-level languages with a GC and low-level languages, and it works not because of a style guide (even though one may exist). As someone working on the HotSpot JVM, I can say that it's done with a lot of thinking about constructing the right primitives that make this work well. Zig doesn't lack the features to construct the mechanisms required for getting good results in that domain, and Rust doesn't have features that could save you the thinking about such mechanisms.

pron 52 days ago | |

I should add that in the 30 years I've been a professional software developer, I've worked on and advised many projects. They all ran into serious challenges at one point or another. Not of those projects that was held in high technical regard changed their language (except for things like JS -> TS or when the project planned to change languages, starting with one suitable for prototyping and expecting to switch if and when their workload grew).

All the ones that opted to switch language after less than a decade were those with serious shortcomings in their technical decision process, and those problems, unsurprisingly, persisted after the language change. After all, the very decision to switch so soon is an admittance that they'd made a very serious misjudgment, but these projects never properly debrief why they'd made such a big mistake and how they can avoid making one again.

kanwisher 51 days ago | | |

likely you never were on a project that had tens of millions of users, you hit different classes of problems and you have to scale to new runtime or language often

elktown 52 days ago |

It's depressing seeing so little critical thinking despite clear and obvious incentives (Bun now being part of Anthropic) behind the reckless decisions that's been made here. Judging by this thread a well-formed article is all that's required for lots of people to just take everything at face value since it confirms the biases of what's currently fashionable.

perching_aix 52 days ago | |

I'm similarly distraught by comments like this. They are a staple, and they always fail their own standards. Critical thinking would lead me to believe that your judgement is heavily clouded, and that it is way more likely you're the one who's biased; either to find other people to be generally below you, or to find people being receptive to this effort any positively to be simply wrong. I'm even wondering if this is a stock comment of sorts.

Strong subjective judgements about an inexact but large sounding fraction of people, without any actual details, is a red flag the size of a skyscraper. And to top it all off, your conclusion is extremely convenient too: you're right, people are wrong, despite the blatant facts otherwise. Not exactly the hallmark of a particularly robust position, not for me anyways.

pohl 52 days ago | |

What specific critical thought(s) do you wish were voiced?

elktown 52 days ago | | |

That this is a technological decision rather than rationalizations (e.g. fixing self-inflicted problems are now marketed as a rewrite win) that Rust is a better fit for an Anthropic-owned project.

awson 52 days ago |

I just glanced at it, but in "Rust supports cross-language link-time optimization between C/C++ and Rust" it's not Rust but LLVM.

Any languages with LLVM backends get cross-language LTO for free.

Have they ever tried Zig Bun with LTO?

quux0r 53 days ago |

Something that seems to have flown under the radar is that bun was originally a rewrite of Evan Wallace’s work (for those that don’t know, he’s a co founder of figma). What I’d love to know is if Evan’s implementation is largely independent and, if so, says a lot about his skill (even more so than the rest of his impressive catalog) to have a reference-able implementation for what it turned into. Super cool to learn the original implementation motivation for Jarred though.

WhyNotHugo 53 days ago |

> around $165,000 at API pricing

This is the bit I was really curious about. Definitely not something within reach for us mortals.

zamadatix 52 days ago | |

On the bright side, that price would continue to drop rapidly even if the models themselves never improved anymore. I'd be very surprised if we didn't actually end up with ~100x cost reduction of this task in the next 10 years between hardware improvements, model perf/$ improvements, and commoditization/conpetition.

For now though it is a bit disappointing trying something like this is relegated to project proposals at work rather than my personal hacking.

ianm218 53 days ago |

Inspired by this project I ported most of Valkey to Rust here valdr.dev .

The coolest outcome was being able to run a redis comparible store on an a cloudflare durable object so you do I.e. rate limiting for free with little infra.

surround 53 days ago |

It seems that Deno made the right decision by choosing Rust from the get-go.

erk__ 52 days ago | |

Deno started in Go, but was rewritten in Rust before 0.1

SergeAx 53 days ago |

I still think that generating a Zig-Rust transpiler would be a better approach, given all the LLM quirks, including the ability to just /goal the model with binary-identical LLVM bytecode.

However, an open-sourced tool like that would've greatly harmed the Zig ecosystem and community.

ivanjermakov 53 days ago | |

> would've greatly harmed the Zig ecosystem and community

People looking to abandon the ship first chance are unlikely to contribute much to the ecosystem and community.

leecommamichael 53 days ago | |

Go famously used machine translation to remove dependency from C. It's a nice way to retain structural familiarity with the target language. I imagine they could've saved a large portion of that $165,000 using this route. Hard to say for certain, though. You wouldn't want to scope that transpiler at "being able to transpile all programs generally," and so scoping the project does become a serious task.

rockmeamedee 52 days ago |

For Bun to not have torched its reputation among its users, it would have had to publish this blog post _before_ pressing merge on that PR.

That's what underlies most of the vitriolic reaction to the events, it was done really in a really rash way.

All they had to do was a)not gaslight people about your intentions when they found the branch b)publicly post the intent to do this, and then c)publish a doc like this one right before merging, ideally leaving the branch open for like a week in case anyone in the "community" finds things to fix.

Then those UB/Miri issues others found would have been "yay collaboration" boosts instead of negative issues that prove that the approach was risky/unthoughtful.

If you're going to cross a rubicon, maybe tell people a)that you actually want to do it, b)why you want to do it and c)what it looks like after you've done the rewrite.

minimaxir 53 days ago |

Adding bespoke animations via Claude Code to the blog post is definitely thematic. It's unclear if they're useful data visualizations as they take a bit of time to parse, but they're neat.

rifty 53 days ago |

Super interesting!

I feel like people will make the wrong comparison with the cost to complete. $165000 should be compared to not the cost of a programmer going line by line by hand but someone designing a transpiler from zig to rust. The time to complete is impressive though, if you could spend $165000 and a year of time to find out the rewrite project worked, or instead spend that in a month, you'd probably take that month now that this proof of concept exists out there.

low_tech_punk 52 days ago |

(1) The original zig code was probably heavily AI coded with lower quality, hence the bag. There is a chance that a full rewrite in zig might do as well but we will never find out.

(2) The rewrite itself is a massively successful marketing move. It shows what Claude code can do and how little it costs compared to human engineering. But the question remains whether someone else, not knowing zig, rust, and TypeScript can pull this off.

didibus 53 days ago |

> to exhaustively come up with reasons why the changes create bugs or do not work

My biggest issue currently, is I can't seem to get a code review that's about the simplicity of the code, and no /simplify ain't it. Removing certain bugs and generally working seems to be doing alright, especially if it's following either an example code (like in the Bun rewrite case) or a well defined "spec" of how to proceed.

dfabulich 53 days ago |

This blog post further undermines my trust in Jarred.

He makes it sound like Claude did a fantastic Rust rewrite, and "the work continues."

But when the Rust port merged to main, the state of the code was very, very bad. There were 13,000 instances of `unsafe`, no Miri tests at all, and, sure enough, it exposed UB in safe Rust. https://github.com/oven-sh/bun/issues/30719

Observers could see this coming from a mile away, objected strongly to using AI to RIIR before the code merged. Rather than incorporate feedback and get the code ready for production, Jarred gaslit us all, right here on HN. https://news.ycombinator.com/item?id=48019226

Just 9 days before he merged the Rust rewrite to the main branch, Jarred wrote:

> 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.

It's plausible that Bun's Rust rewrite is now in much better shape than it was in May. But a blog post like this would have been a place to apologize, to accept that it was a very bumpy rollout, to acknowledge that public messaging was extremely poor, and to earn back our trust.

As it stands, I guess I'll have to run my own tests to try to evaluate whether Bun 1.4 is ready for prime time, because I just can't trust Jarred to give us a straight answer.

vrtcn 52 days ago |

I am a bit suspicious about the choice of startup time as the metric to evaluate performance in Claude Code. With a rewrite from a language like Zig to Rust, my biggest performance concern would be allocation. Where a Zig app might use a fast linear or buddy allocator, a Rust app is more likely to use malloc. During startup, both versions are likely to make tons of allocations. In fact, the Zig version is likely to make larger allocations during startup to reserve memory for its custom allocators. So I would expect both versions to be roughly on par, or Zig slightly worse there. However, during normal execution, I would expect the Zig version to be potentially faster, because it has paid the cost of malloc at startup and now an allocation might be as fast as incrementing an integer. This is speculation, but I would like to see performance numbers for the rest of the app lifecycle.

anentropic 52 days ago | |

Those were in the article https://bun.com/blog/bun-in-rust#2-5-faster

tomkarho 53 days ago |

The way this trend is going we might need "rewritten in Rust" catalog similar to Google's graveyard.

egorfine 52 days ago |

Any chance for 1.3.15 with top bugfixes for those of us who once trusted Bun and are stuck on it in production? I have migrated almost everything out of Bun by this point but I have one single project that builds into executables with Bun and relies heavily on Bun's SQLite.

frollogaston 53 days ago |

"I used a pre-release version of Claude Fable 5 for much of the Rust rewrite."

It'd be interesting if Anthropic became a general software company just because they have access to models that aren't yet released, possibly export-banned.

grandimam 53 days ago |

The rewrite itself is amazing, but I don't think folks realise the actual conditions that made it possible. It's not as simple as a company spending ~$160K on tokens.

This was done by someone who has essentially already rewritten Node once. Bun itself is a reimplementation of Node, so the author was walking in knowing exactly what the correct behavior is. And an exhaustive amount of test suite to verifiy the changes?. On top of that, there is a reference from Node and V8 to validate more throughly. So the $160K is simply the price of translating knowledge that already lived in one engineer's head in a newer syntax.

hresvelgr 52 days ago | |

The condition that made this possible is that this task is well within frontier LLM capability and he had tokens to burn. Domain knowledge is separate to language semantics.

duhhhhh1212 53 days ago |

Where is the cost breakdown? I feel like this would be the easiest number to determine and write in this post. It's hard to believe that there have been no problems/downsides since the port.

gpm 53 days ago | |

> Where is the cost breakdown?

From the article

> Pre-merge, this took 5.9 billion uncached input tokens, 690 million output tokens, and 72 billion cached input token reads — around $165,000 at API pricing

> It's hard to believe that there have been no problems/downsides since the port.

A significant portion of the article was dedicated to the 19 regressions they've found. Starting here: https://bun.com/blog/bun-in-rust#porting-mistakes

BearOso 53 days ago | | |

I posted on an older article that I thought it probably cost half a million in API pricing. 165k USD is a lot lower. I wonder what the actual compute cost was. When this first hit the news, Opus 4.7 was brand new and required 6x the compute power per user token vs 4.6. The article says they were using Fable, which is way more expensive.

duhhhhh1212 53 days ago | | |

Thanks!! Those are solid numbers but confusing. He reported input, output, and cached input token reads but not cache writes/cached creation input tokens? Maybe cache writes aren't a thing internally?

egorfine 52 days ago |

To me this whole saga stands on a very thin overlapping region between "it has merit" and "I hate it". Like, the blog post clearly explains the merits and they are strong. At the same time, I absolutely hate how the author handled the whole rewrite, including throwing the whole community out the window along with all their contributions and human love.

DennisL123 53 days ago |

In a world without AI/LLMs/agents the rewrite would have been major news how much better software gets when ported to Rust.

pier25 53 days ago |

> Compiler errors are a better feedback loop than a style guide

So essentially this whole re-write was about making Bun LLM compatible.

dirkc 52 days ago |

I got curious and had a look at some of the code (>1m .rs). I was surprised to see code for a S3 client in there?

I clearly don't get the value proposition of bun? And even if I accept that you want to bundle your run time, package manager, test runner and bundler, why do you want to include things like a custom S3 client?

emilfihlman 52 days ago |

Until this bug is fixed, there's no trusting Bun

This is also not a memory issue but an actual logic issue, so Rust doesn't help there.

https://github.com/oven-sh/bun/issues/14144

voidUpdate 53 days ago |

I wonder how much the authors now understand their project? Like, if they were given a bug, would they be able to intuit a possible location in their files that might be causing it? Or are they now essentially locked in to using LLMs to write/rewrite their code?

egorfine 52 days ago | |

> how much the authors now understand their project

I don't think this is a value anymore for them.

tipiirai 52 days ago |

This post was clearly an important marketing effort from Anthropic and Jarred. Those interactive demos alone would take serious effort from a seasoned frontend engineer, AI-assisted or not. Pretty sure multiple devs were working on this post.

ares623 53 days ago |

What does it say that it took 2 months to write the blog post? (or at least have it published)

cube00 53 days ago | |

He's been teasing this blog post everywhere (in commit messages, multiple times on X, here on NH [1]) so I wonder how much of it was building hype compared with it legitimately taking two months to write.

I wonder if the delay of Fable has also been a factor and maybe they didn't want to release this blog post while they couldn't allow customers to use Fable and waste the advertising opportunity.

[1]: https://news.ycombinator.com/item?id=48133519

tln 53 days ago | |

That a human wrote it?

AbuAssar 52 days ago |

It took TypeScript team 1 year to port the code to Go, but if Claude Fable was available back then, would they better use it to port the code in 1 week instead?

mghackerlady 52 days ago |

This makes me sad :( I've always really liked Zig, and Bun was pretty much the only big thing I could point at and say "that was done in Zig"

yoav 51 days ago | |

Electrobun is still zig and doubling down on it

erichocean 52 days ago | |

TigerBeetle has you covered then.

jmcqk6 52 days ago | |

ghostty is a zig project too!

khurs 53 days ago |

> Bun was acquired by Anthropic in December 2025

Great for the Bun creators, but now we will have major runtimes that are optimised to work with one companies models...

incognito124 53 days ago |

> In Bun v1.3.14, every build leaks about 3 MB, forever

I'm sorry but that is insane, how was this never fixed before the rewrite?

pier25 53 days ago | |

I've been impacted by a couple of bugs in Bun.SQL and lo and behold these were only fixed for 1.4. Presumably Claude could have fixed those in the Zig version but the Bun team decided to not do that.

Furthermore, there's no mention of an LTS plan for the Zig version. It seems that if a CVE is discovered in the future, Bun users will no have no option than to update to the Rust port.

This is not how you run a project that others depend on and enough for me to not touch Bun ever again.

dgacmu 53 days ago | | |

I'm a little puzzled: Why should you care? The language in which Bun is written isn't part of its API, if you will. You care that you have something that does various javascripty things according to a particular spec of what it's supposed to do. If a bug is fixed in 1.4.x it's fixed, why should it matter, really, if that's in Zig or Rust?

dzonga 52 days ago |

use Node or Deno.

if you want superior developer experience - Deno.

if you want stability over everything - Node.

xyzsparetimexyz 52 days ago |

> I asked Claude to loop the workflow on all 1,448 .zig files, and about 2 minutes in, one Claude ran git stash before committing. Another ran git stash pop. And then git reset HEAD --hard. They were stepping on each other!

I hate how easy git makes it for llms to catastrophically fuck up repos

> And if I put each Claude into a separate worktree, I would run out of disk space because Bun's git repository is too big and eventually the changes will need to be compiled and seen together.

This seems like a stupidly easy problem to fix.

> So, I asked Claude to edit the workflow to instruct Claude to never run git stash or git reset or any git command that doesn't commit a specific file at once. No cargo either. No slow commands at all.

What's the right way to fix this? I have a Pi extension that blocks any use of the word 'git' with 'stash/checkout/reset/restore' in commands which is a very large hammer approach. Is there a way I can allow a subset of git use in a nicer way without the less nice commands?

anonyonoor 53 days ago |

I think we're finally getting to see a glimpse of the future. People and LLMs, working together. (And doing it really well.)

It's pretty exciting.

suby 53 days ago |

I'm so jaded at this point. The AI translation from Bun to Rust doesn't bother me, I think it's interesting, but that this blog was so clearly written by LLM's is offputting for some reason. I think after having to interact with LLM's for much of the day, it's exhausting to read LLM speak in so many things I see online. It feels almost disrespectful to the reader. It's written from a first person perspective, but Jarred did not write these words.

I was looking forward to this blog post too, but in retrospect I don't know why. I could have had an LLM generate a hypothetical of what this blog post might have looked like and it would have probably been able to get close.

I feel like we've replaced unique voices on the internet with the same style / author, which might be more tolerable if the breathless LLM writing style wasn't so jarring. Contrary to the amount of times "But honestly" or "genuinely" is mentioned, nothing about having your LLM speak for you feels honest or genuine.

I know it's not cool to leave responses like this, but I'm really tired of all of this at this point. The ironic thing too is that it might actually be better to have LLM written text be so distinct so that you can still pick out when a human has actually authored something. Again, this is a blog post from Anthropic about having an AI translate 500k+ lines of code in 11 days, so I guess my disappointment is my fault for expecting otherwise.

yomismoaqui 53 days ago | |

We need to coin a new term for the paranoic feeling that every text on the internet is written by LLMs.

I propose GPTSD (GPT + PTSD)

EDIT: Another one, AIdar (like gaydar but for AI text). EDIT2: GPTSD has prior art (literally) https://ryanthompson.name/project-gptsd.html

jsnell 53 days ago | |

> that this blog was so clearly written by LLM's is offputting for some reason

It doesn't read at all AI-generated to me. What section do you think is?

(Pangram is very good at distinguishing between AI-generated and human text, and assigns a very low score to the article: https://www.salahadawi.com/hacker-news-ai-detector/rewriting...)

> Contrary to the amount of times "But honestly" or "genuinely" is mentioned, nothing about having your LLM speak for you feels honest or genuine.

"Honestly" is used once in that post, in a way that's pretty much the core, self-deprecating human use for it ("It would have been possible to do X, but honestly I didn't want to"), rather than the filler word use-case.

"Genuinely" is not used at all.

> I know it's not cool to leave responses like this, but I'm really tired of all of this at this point.

I think it is cool to flag AI-generated slop and either leave a comment or upvote an existing comment about it being slop. But only if you are sure it's AI-generated. And sorry to say, you don't seem very well calibrated on this. If you can't actually tell the difference and back up your opinion but are just guessing, then it indeed isn't cool.

akanet 52 days ago | | |

The article is very clearly human written. The author discussed on twitter that he used Claude for visualization and feedback. You can simply say you don't like the writing style, but it is not a very useful comment to have written in any case.

egorfine 52 days ago | | |

> Pangram is very good at distinguishing between AI-generated and human text

It's not.

zamadatix 52 days ago |

An extremely interesting blog post for me on a few fronts:

I'm very glad to see a holidtic approach to the memory errors and segfaults. I was tinkering on a static webpage just this this weekend, using Bun as the transpiler+bundler since it's so turnkey, and I ran into a few segfaults. E.g. when Bun saw I used an empty data uri for the favicon (avoids the browser trying to ask for one) it'd just crash. It reminded me of my own tinkering with Zig in its current pre-release state where it's usually a good mix of my poor memory management and working around bugs in Zig itself.

This post is also the best ad for AI I've seen yet. Not just comments saying they have 10xed themselves, a small personal project or thing which can (and likely will) be abandoned next month, or a one off dump of unusable code for the world's buggiest C compiler (come on Anthropic?). Instead this is a well thought out way of leveraging LLMs to do something which would otherwise probably not be deemed a reasonable enough effort.

I'm glad they included the rough cost as well. Crazy high, more than I can afford to be throwing at the wall to see what sticks, but still low enough to make sense over trying to hire developers for (even ignoring the timeline).

But it also highlights 2 really key things about current LLMs: the scaffolding can be just as valuable as the model & they still need someone able to figure out the right way to instruct and orchestrate them. Without the scaffolding the current models could never get close to handling something of this scale & quality. With the scaffolding you could probably get this to work okay enough even with a weaker model. On the orchestration side, Claude could help answer what good porting practices would be but it doesn't just get there itself, it requires hours of someone who understands the context of the project from bottom up and a clear understanding of what will/won't work to get the right scaffolding to do the job well.

Finally, it was an interesting dichotomy on presenting the port. On one hand it has been a bit opaque up until now. People saw the repo and there were some comments about testing the waters but then it suddenly shipped into production. On one hand that's awesome and I'm sure the reception here would be very different if there wasn't the "it's already been boringly shipped in Claude Code" shining result. On the other... I think I'll stick to using Bun as a personal tinkering tool for now. The velocity is so high I'm just not sure it'll land in a place I can rely on it st the speed of my org. Of course, that velocity is what has made Bun's success story and they should probably continue with it - I'm just looking forward to an LTS release :).

giancarlostoro 53 days ago |

So I kept hearing that the author did this purely because Anthropic wanted a PR story, but reading this entire very well written post, with meticulous detail, what say you now? I never thought it made any sense for him to do this just because Anthropic asked him to. Sometimes you find yourself fighting the stack you're currently using, and another stack (or programming language) looks like it would alleviate a lot. LLM was just another tool in his toolbelt. I had already ported projects that were old and abandoned before using Claude Code, so I knew it was possible.

nozzlegear 53 days ago | |

> what say you now?

I think that when you have a $165,000 hammer, all of your problems begin to look a lot like nails.

giancarlostoro 53 days ago | | |

I've done rewrites like this, maybe it wasn't Zig to Rust, but I have been able to rewrite sizable projects, from C# to Rust before. I incorporated a similar strategy, have Claude Opus review the codebase, write a spec, then have Claude implement it, while reviewing the spec, and using the codebase as fallback and gospel over the spec. That said, it's not the entire story here as I said, there was a lot of thought put into it, it it had not been done with Claude, I have a feeling he might have started an "experimental" version of Bun in Rust instead, as many developers have done in the past before LLMs.

benced 53 days ago | | |

I would guess the cost to do this with humans would be _at least_ $1.5M in compensation alone (I'm thinking three 500k/year Bay Area engineers) so this is already an order of magnitude cheaper.

Is it worth $165K? I'm less sure of that but it's honestly a moot point - this will get to 5 then 4 digits of cost pretty fast.

johnfn 53 days ago | |

So much of the discourse around this on HN is nonsensical, and I fully agree with you. It's patently absurd that Anthropic would demand him to rewrite Bun into Rust; it's equally absurd that they would demand any sort of stunt at all when Anthropic already pulled off the biggest stunt with Bun: running Claude Code on it. And why on earth would you cannibalize the runtime of your golden goose?

tangenter 53 days ago |

Should we brace for another front page Zig donation announcement? A fast follow with a “Why Zig?” penance piece, replete with anecdotes about how it is the only true way to express oneself?

classicposter 53 days ago |

This slop rewrite introduced new vulnerabilities and regressions.

wilkystyle 53 days ago | |

Care to elaborate?

lionkor 53 days ago |

> C++ instead of Zig would be a reasonable choice for Bun. We would get constructors & destructors. We could delete lots of extern "C" wrapper code.

> But, we would still be reliant on style guides enforced through code review, and even with ASAN, memory corruption and memory leaks would still happen.

Tell me you didn't even look at C++ without telling me you didn't even look at C++. I don't understand this at all, what's missing? There's clang-format, clang-tidy, cppcheck and so many others, what is missing exactly? Memory safety? Then why bring up C++ and style guides(?) at all?

kubb 53 days ago | |

Not replying directly to OP, just to people who never coded in C++.

Clang-format doesn’t save you from all C++ footguns, e.g. using exceptions, macros or templates in the wrong way where „wrong“ is defined by a fuzzy set of rules that requires a lot of experience and vigilance to enforce.

m00dy 53 days ago |

Rust is the clear winner of LLM era. You can't say otherwise.

insanitybit 52 days ago |

This is just a hit piece and it's embarrassing to post it on your project's website. Could've been a tweet.

jatins 53 days ago |

Extremely thorough and well written.

I was hoping it’d end in a “so how much did this cost?” so that others team looking at similar migrations have an estimate on what they can expect

hdjrudni 53 days ago | |

> I was hoping it’d end in a “so how much did this cost?” so that others team looking at similar migrations have an estimate on what they can expect

It was in the middle. $165k.

marcianx 53 days ago | |

It's right there under "Stats":

> 11 days (May 3 → merged May 14) · 6,778 commits

> Pre-merge, this took 5.9 billion uncached input tokens, 690 million output tokens, and 72 billion cached input token reads — around $165,000 at API pricing. By hand, I think this would've taken 3 engineers with full context on the codebase about a year, during which time we wouldn't be able to improve Node.js compatibility, fix bugs, fix security issues or implement new features. We never would've done that. The realistic alternative was to do nothing and keep fixing the bugs at the top of this post forever.

Barrin92 53 days ago |

the thing I don't understand about this, given that the goal was a line-by-line transpilation, and the author had already transpiled it once from Go to Zig, why not write an actual transpiler? A problem is as complex as the smallest program required to solve it, and having an LLM, which doesn't produce deterministic output churn through almost 200 grand when you only need to write a deterministic program maybe 5% of that size seems like not a great way to go about this

crote 53 days ago | |

Because the author isn't employed by a transpiler company.

The entire point is to get people to spend money on LLMs. Writing a transpiler - even a LLM-coded one - pretty much defeats the purpose.

pohl 52 days ago | |

This is a frequently mentioned criticism. Is there a good argument about why that approach could have been done in the same amount of time? Seems like larger scope and more uncertainty to me.

Barrin92 52 days ago | | |

>Is there a good argument about why that approach could have been done in the same amount of time?

as I said because it's a much smaller codebase. This is a million lines of code project. A literal Zig to Rust translation that is mostly syntactic is not going to be more than 10-20k LOC for a transpiler. That's two orders of magnitude less work.

jordand 53 days ago |

The thing you have to remember with that $165k spend on tokens is that token prices are going to keep rising, and models may not get much better. I wouldn't be surprised if doing this same migration in 6 months time would end up costing $250k+

Havoc 53 days ago | |

For sota perhaps but not convinced token price will shoot up if capability is held steady

capiki 53 days ago | |

do you think price per task completed will rise as well?

hdjrudni 53 days ago | | |

Isn't that equivalent? The task here was port Bun from Zig to Rust. He's saying that task will cost more.

rvz 53 days ago |

As expected [0] [1], this was a clear advertisement / marketing opportunity of Anthropic's Fable model on rewriting Bun (which powers Claude Code) from Zig into Rust.

Something that would have taken hundreds of developers now took 1 developer with Fable.

Now Claude, rewrite Claude Code from TypeScript to Rust. Make absolutely zero mistakes.

[0] https://news.ycombinator.com/item?id=48073893

[1] https://news.ycombinator.com/item?id=48240829

steveklabnik 53 days ago | |

EDIT: the parent has effectively deleted their original comment

> There are a lot of ways to do a terrible job of this. For example, prompting Claude "Rewrite Bun in Rust. Don't make any mistakes." and then praying it would work is not what I did.

rvz 52 days ago | | |

> EDIT: the parent has effectively deleted their original comment

Not really and we both know that is not true.

The last line of the comment was the joke. [0] It is clear that you didn't get it and many others did. That is OK.

Heavens forbid anyone here is allowed to make any jokes on this site.

[0] https://news.ycombinator.com/item?id=48839063

merb 53 days ago | |

1 Developer with a 200k budget for tools.

himata4113 53 days ago |

They didn't mention the cost of this. Assuming mythos was somewhat involved I'd extrapolate this as: 128 x20 max accounts needed which comes at $25.6k or over 75k in api costs. For 75k you can hire a team of engineers that would produce a better result with sematic conversion and other tricks used in porting from language A to language B at the cost of maybe taking 1 month instead of 10 days.

I will be a lot more excited when this is possible with <10k of api costs.

fps-hero 53 days ago | |

erichocean 53 days ago | | |

Even at $165K, it's worth it to have a better base to build on top of—especially since it didn't take a year's worth of time for three programmers.

JavierFlores09 53 days ago | |

I don't think the realistic alternative here was “hire a team for a month and get a better semantic conversion”

For a rewrite of this size, the expensive part is deep understanding of the underlying system in order to preserve behavior while keeping performance, and above all that not freezing product work while doing it. Adding more engineers would just end up in managerial burden and review bottlenecks, to say the least.

So even assuming the API cost estimate is high, I don't buy the “just hire engineers for a month” take. A team unfamiliar with the codebase would probably spend a large chunk of that month just building context and deciding how not to break everything. A team familiar with the codebase is even more valuable doing product work, bug fixes, and review of the existing codebase.

So, in short, I do agree with the simple fact that this is still too expensive for most projects, but not with the idea that “a small team would trivially do better in a month”.

incognito124 53 days ago | |

It states $165k in the article

DeepSeek v4 Pro & Mimo v2.5 Pro $3,426 ($2,567 / $600 / $259) Tencent HY3 $3,892 ($1,180 / $552 / $2,160) GLM 5.2 $30,016 ($8,260 / $3,036 / $18,720) Qwen 3.7 Max $37,925 ($14,750 / $5,175 / $18,000) Claude Opus 4.8 & GPT 5.5 xhigh $82,750 ($29,500 / $17,250 / $36,000) 5.9 billion uncached input tokens, 690 million output tokens, 72 billion cached input token reads.

#[derive(Copy, Clone)] enum Expr { Int(i32), Add(i32, i32), Neg(i32), } fn eval(expr: Expr) -> i32 { match expr { Expr::Int(x) => x, Expr::Add(a, b) => a + b, Expr::Neg(x) => -x, } }

#include <stdint.h> typedef enum { EXPR_INT, EXPR_ADD, EXPR_NEG, } ExprTag; typedef struct { ExprTag tag; union { struct { int32_t value; } Int; struct { int32_t left; int32_t right; } Add; struct { int32_t value; } Neg; }; } Expr; int32_t eval(Expr expr) { switch (expr.tag) { case EXPR_INT: return expr.Int.value; case EXPR_ADD: return expr.Add.left + expr.Add.right; case EXPR_NEG: return -expr.Neg.value; } __builtin_unreachable(); }