Rendered at 06:09:15 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
didibus 6 hours 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 6 hours 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 5 hours 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.
atrevbot 5 hours ago [-]
As someone who has almost no familiarity with game engines, it seems the success of this port was largely possible due to a comprehensive test suite written in a runtime agnostic way. What might be the equivalent test suite implementation required to successfully port a game engine to another language?
jamesfinlayson 3 hours ago [-]
Gosh, I don't think any game engines have particularly good test suites at all. GoldSource and Source are the only ones that I have any real experience with and neither seems to have anything (Source may have a handful of things but nothing approaching baseline let alone comprehensive).
I have no idea how game devs handle big refactors other than lots of manual testing.
zamalek 3 hours ago [-]
One option would be to have an input replay alongside captured outputs (audio visual), at some fixed framerate. Capturing intermediates (scene graph etc.) would probably also be valuable, as that could help nail down why something is failing.
Or you could do it [as I recall the project being called] the scientist way. You still have the old code, so you could replay inputs against each and compare. Probably more realistic because uncompressed video would be a ridiculously huge dataset. This would be more resilient in the face of testing hardware and driver drift.
Historically game engines are the worst offenders when it comes to unit testing. I'm not sure if that's still the case - but that's why I erred on the side of integration tests.
gpm 6 hours 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).
leecommamichael 5 hours ago [-]
I see that now, thanks. There's a lot to say here, especially with other approaches to memory management. My overall goal was to give them some context that wasn't their own.
vlovich123 1 hours 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.
> For what it’s worth game devs often use C# or C++ engines which have even worse issues.
Such as? You can't be referring to hot reload alone because you can already do that in both C++ and C#.
kibwen 5 hours 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).
comex 51 minutes ago [-]
The forbidding of circular dependencies is exactly what makes it hard to achieve parallelism! It means you have to draw nice clean module boundaries and split your compilation units there. Clean boundaries sound nice, except… what if the module is getting large? Can you just take half the module, ctrl-x, ctrl-v into a new file, and get faster compilation times without having to do any massive refactors?
In C, usually yes.
In C++, sometimes yes. It depends on how template-heavy the code is, but if you have some discipline you can keep most logic out of headers and thus easily splittable.
In Rust, almost always no, because of circular dependencies. You can try to work around it by adding `dyn Trait` everywhere, but that requires a lot of code changes and comes at big ergonomic costs (and a small runtime cost).
Which is why in practice, Rust compilation units are almost always larger than C++ or C compilation units. Rust can sometimes be competitive with C++ on compilation speed anyway, thanks to a smarter build system and not having to re-parse headers a billion times, but usually it's slower.
FridgeSeal 26 minutes ago [-]
> Can you just take half the module, ctrl-x, ctrl-v into a new file, and get faster compilation times without having to do any massive refactors?…In Rust, almost always no, because of circular dependencies
This feels like a strange, overly-specific complaint.
It reads a bit like “When I write entangled code, it’s hard to untangle”. Like, yeah, the only thing that’ll save you from that is…not writing entangled code? I’m not of the opinion that the argument of “yeah but C lets me do whacky stuff” is a particularly strong line.
FWIW, letting a module grow, and then splitting modules up by cut-and-pasting stuff out along natural domain lines generally _is_ how I write Rust. Largely due to how easy it makes it to construct modules and submodules.
josephg 2 hours 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 3 minutes 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.
m00dy 47 minutes ago [-]
yeap, unfortunately, only few can see this.
frizlab 5 hours 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…
henry_bone 5 hours 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.
kibwen 4 hours 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.
Gigachad 4 hours 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.
rvrb 4 hours 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 3 hours 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 4 hours 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
rvrb 4 hours ago [-]
you're right that that is a weak argument against C++ in that use case (biased by my own dislike of the language); but it is also a niche that Zig fits into quite well. so it's weird for the OP to claim it's ok to drop down to C++ when needed while kind of suggesting they don't get why anyone would use Zig
galangalalgol 3 hours ago [-]
If you are willing to hand code intrinsics it doesn't really matter what language you pick from a performance perspective. Rust consistently shows it has better performance than c++ in code that does not hand code intrinsics. If cpu(not gpu) based performance is all you care about there is no reason to pick anything but rust. Modern c++ devs have no trouble with the borrow checker either they are already doing all the things that keep it from complaining. The reasons someone might not pick rust involve integration with existing code, the complexity of the language, and the depth of it's dependency trees. The complexity argument certainly doesn't lean you towards c++ or probably anything with an llvm back end. The openbsd approach to c is probably as simple as you can get these days short of forth or something equally obscure. Dependency trees are deceptive. We all have deeper trees than we think we do, but the rust front end itself has well over 100 crates in its tree...
All that said, I use rust for everything.
sitzkrieg 4 hours ago [-]
rust is still a non starter in some niche embedded applications (way too big). i still write c and assembly constantly.
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.
3 hours ago [-]
swiftcoder 16 minutes ago [-]
> niche embedded applications
How niche are we talking? Rust is deployed on a bunch of popular microcontrollers at this point
Philpax 8 hours 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%.
simonw 6 hours ago [-]
I don't think it's care to categorize this as "a naive rewrite away from [Zig]" - Jarred has been immersed in this project for five years, got to benefit from everything he learned along the way and spent $165,000 of tokens on the most advanced coding LLM anyone has access to.
I expect if he'd spent $165,000 running Fable against the Zig version he could have got a 5% performance improvement, too.
malisper 5 hours ago [-]
I can confirm a naive rewrite won't make things faster. I've been working on rewriting Postgres in Rust. I rewrote things function by function similar to how Jarred did. Even though the new Rust code mapped closely with the previous C code, it was 8x slower. This was due to myriad of reasons. For example naively converting a C union into a Rust enum can be slower because Rust stores a tag with the enum, while C unions do not.
I've been working on a new rewrite that's focused on beating Postgres on performance. As of this morning I got to 100% of the tests passing and have meaningful performance gains over Postgres.
Bookmarked. I love ambitious projects like this. I'll check in!
einsteinx2 5 hours ago [-]
> and spent $165,000 of tokens on the most advanced coding LLM anyone has access to.
After having used 2 full weeks of 20x Max plan tokens on Fable over the weekend (coding all day Saturday and Sunday on a non-trivial project, tasks across full stack, mix of adding features, reviewing code, and fixing bugs), I’m confident if he’d spent $165,000 in Opus tokens the port would have gone more or less just as well (and probably for less than $165,000). Especially so with the system they set up with all the custom workflows, adversarial reviews, extensive test coverage, etc.
But I get your point is probably more about Jarred’s experience level and the high cost than the specific model used other than it being SOTA. I’m just being pedantic and feeling a bit disappointed with Fable’s real world performance after all the hype.
> I expect if he'd spent $165,000 running Fable against the Zig version he could have got a 5% performance improvement, too.
Totally agree and in fact I’m sure it could be done with significantly less cost even if they stuck with Fable instead of Opus which I’m sure could also do it.
cognitiveinline 2 hours ago [-]
Fable is kind of fantastic on the difficult tasks. if it's something eithe rmodel can do then you can't see the difference. Fable also makes much less mistakes. It's a more relentless, proactive problem solver.
Philpax 6 hours ago [-]
Oh, I have no doubt that they could have extracted those gains from Zig! My point is more that, from a relatively naive line-to-line port, they were able to claim these benefits without much effort.
It's not great for Zig if you have to put in more work to end up at the same place efficiency-wise, especially for a language marketed at people who like to get the most out of their metal.
gwenzek 1 hours ago [-]
That's not what the article says though. The size reduction was from extra linker flag for deduping code, and the speed gains from LTO.
They could have done the same in Zig, even though it probably shows cargo is better at this than build.zig.
bielok 7 hours ago [-]
I would guess that people looking to use Zig understand that those are project concerns and not language concerns.
Zakis1 7 hours ago [-]
The stability gains are a direct language concern as mentioned throughout the article.
throwaway27448 7 hours ago [-]
True, but rewrites often allow for this sort of benefit in themselves. It's possible rewriting it in zig would have yielded some of the same improvements.
pdpi 7 hours ago [-]
A sophisticated rewrite? Sure. This was a naive like-for-like rewrite, though.
2 hours ago [-]
h14h 5 hours ago [-]
While it's easy to look at it that way on the surface, from reading the blog post, it sounds like a big part of it may just be the nature of Bun as a project.
frollogaston 6 hours ago [-]
I pay attention when someone makes a hard decision based on a hard-learned lesson. It's like, most who choose to use an ORM just heard of it or want to avoid learning SQL, everyone who removes an ORM learned firsthand horrors.
lifthrasiir 7 hours ago [-]
The same concern applies to every GC language, so it's not necessarily bad for Zig. Bun can have been grown too large for Zig to be effective, while moderately sized projects may still greatly benefit from Zig.
saghm 6 hours ago [-]
I thought Zig was supposed to be a C replacement (as in, it doesn't actually provide full safety in the way that Rust or a GC language would)?
lifthrasiir 6 hours ago [-]
Oh, yeah that might be confusing. I meant "you can say the same thing for GC language if that's true, which isn't necessarily true, so that must be false".
More precisely speaking: GC languages are said to delay memory problems far beyond the horizon, which is often unreachable throughout the project's history. Zig can be a similar case.
saghm 5 hours ago [-]
Ah, I understand now. That said, I still think there's a pretty strong argument that this is a lot worse for Zig than a GC language, because they also give you safety for that overhead (and potentially ergonomics). When a language is trying to operate in the same niche as C with what seems to be an overt attempt to be less cumbersome than Rust even if it makes it less safe, it's a bit concerning to see that even without the safety it seems to have more overhead rather than less. Put another way: it sounds like it might as well just add a GC if it's not going to be competitive on performance.
geon 7 hours ago [-]
Wouldn't the same improvements have been made in zig if they instructed the agents to improve instead of rewrite?
gpm 6 hours ago [-]
Maybe they'd get the same numeric improvements and bug fixes today (or maybe not, or maybe they'd get even more since the LLM isn't spending time rewriting correct code).
But they wouldn't get a change to the structural issues that created the issues in the first place. They'd end up "ke[eping] fixing these kinds of bugs one-off in perpetuity".
Zakis1 7 hours ago [-]
But how would you verify that the agents have written memory safe code? Rust's borrowchecker is a lot faster and actually verifiably safe compared to asking an LLM to fix the safety issues that the Zig version had.
linzhangrun 5 hours ago [-]
zig has been developing too slowly. it still cannot reach a stable 1.0 (to the point that even vsc autocomplete gets its Hello World wrong), and then it ran headfirst into AI.
rq1 7 hours ago [-]
From a PL Theory perspective, Zig is vibe-coded.
Not sure why people use it.
pyrolistical 7 hours ago [-]
Yeah but they turned it into something unreadable. Call it a skill issue if you wish.
I just haven’t found another language that just makes sense. Zig doesn’t hide anything from you
kgeist 7 hours ago [-]
>they turned it into something unreadable
Did you compare the code before/after? It's a mechanical line-by-line port, and most of the code is identical to the old version, just with Rust syntax. They have an example in the blog post.
kvuj 5 hours ago [-]
But how can it be a mechanical rewrite if the tool used isn't deterministic?
kgeist 4 hours ago [-]
It converges to "almost deterministic" on highly predictable outputs (i.e. code) with the right sampling params (say, you only sample the most probable token without randomness/high temperature) and with self-correction loops
lifthrasiir 7 hours ago [-]
The article explicitly mentions the maintainability as a foremost concern.
silver_silver 6 hours ago [-]
People say a lot of things, especially when they have a vested interest in a positive outcome. Bun has been fully vibe coded into another language. There’s no way in hell it’s maintainable. Go read any analysis of the Claude Code leak for proof.
lifthrasiir 6 hours ago [-]
Claude Code is entirely vibe-coded for a long time. Bun isn't. You go read and compare the actual Bun code; it reads reasonably well [1].
Sure, reasonably well at first glance, but to quote the article:
> I rewrote Bun in Rust using about 50 dynamic workflows in Claude Code run continuously over the course of 11 days.
> Excluding comments, Bun is 535,496 lines of Zig.
> How do you review a PR with +1 million lines added? How do you start to build the confidence needed to responsibly merge large quantities of LLM-authored code? A language-independent test suite with a million assertions, adversarial code review and when something does go wrong, fixing the process that generates the code instead of hand-fixing the code.
That’s vibe coding. This blog post is an ad for Claude, nothing more.
teach 6 hours ago [-]
You're entitled to call things as you wish, of course, but your definition of "vibe-coding" differs quite a bit from mine.
frollogaston 6 hours ago [-]
Doesn't look like vibecoding to me. It does look like a Claude ad, but they do have a vested interest in not screwing up Bun now that they own it.
27183 6 hours ago [-]
What would be the consequence to them if they did screw it up? Screwing up the maintainability of a project, especially a big one, doesn't necessarily have immediate consequences. The fallout could be delayed by a year or more. Also, they have effectively limitless tokens to burn on keeping everything looking OK, and a vested interest in doing so.
I'm not trying to spin up some kind of conspiracy theory here, but I'm not sure to what extent Anthropic does have any vested interest in this project (in fiscal terms at least) because the reputational fallout could be significantly delayed and might just not be big enough to matter.
simonw 4 hours ago [-]
Claude Code is the main reason their revenue (ARR) grew from $9bn to ~$47bn in the first half of this year.
That's a very big reason not to screw this up.
Zetaphor 44 minutes ago [-]
It's far less obvious how choosing Bun results in more revenue for Anthropic. Unlike Claude Code, Bun doesn't require you to pay for tokens to use it
minimaxir 21 minutes ago [-]
Bun powers Claude Code. If the rewrite introduced catastrophic bugs, it would cause catastrophic bugs in Claude Code and therefore without exaggeration could cause $billions of lost revenue.
daishi55 6 hours ago [-]
> There’s no way in hell it’s maintainable
This is not an assertion you are qualified to make
> Go read any analysis of the Claude Code leak for proof
You seem to be implying that Claude code is unmaintainable. Yet they appear to be maintaining it just fine. Did I misunderstand your implication?
fragmede 6 hours ago [-]
Claude code is buggy and they don't appear to be maintaining it just fine.
daishi55 6 hours ago [-]
I use it all day every day and haven’t noticed any bugs.
And the fact is that they are maintaining it and it is one of the most successful software products of all time and is earning them mountains of cash. By any metric it is a successful product. So obviously whatever they are doing is working.
dgan 1 minutes ago [-]
You and the parent are arguing over different, orthogonal things. I believe the parent argues over "efficiency"(=being able to achieve a goal for given amount of ressources) while you are replying over "efficacy" (=being able to achieve a goal). Both could be called 'maintainability' and nobody explicitely tells what definition they use, so all the long pointless discussions could be avoided if people agreed on terms
cozzyd 5 hours ago [-]
Powertop tells me claude-cli creates an inordinate amount of wakeups, halving my laptops battery life if I leave it open. For a tui that should be doing nothing when I'm not interacting with it...
Klonoar 5 hours ago [-]
> There’s no way in hell it’s maintainable.
They rewrote the entire thing with extensive LLM use.
It is abundantly clear that their idea of maintainable and yours probably don't match up.
It's apparently out there, shipped in the real world, with people saying it's good. I think it's a pretty clear win for them.
baby 5 hours ago [-]
I find Rust more readable than zig
m00dy 39 minutes ago [-]
you're not alone.
benced 5 hours ago [-]
The scary thing is the zig project prohibits LLM contributions - the world is going to move faster than them.
AlotOfReading 3 hours ago [-]
I would be pissed if my programming language changed as quickly as Claude code does. Languages need to move slowly and carefully, and zig is on the faster end of language development regardless.
sashank_1509 5 hours 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.
ozgrakkurt 12 minutes ago [-]
It is highly debatable if a 200k cost engineer that is suitable for the job wouldn’t bring in more value.
Also it is debatable they got any value at all from this. Anyone who wrote unsafe rust and also wrote zig would know that unsafe rust is much much more unsafe in comparison
47 minutes ago [-]
jameskraus 5 hours ago [-]
It's funny, I see the opposite and I would only trust a senior engineer with conducting such a wide-reaching change. I would be more likely to hire a senior engineer who might now be able to effect such change.
Gigachad 4 hours ago [-]
I'm not so pessimistic. There is an infinite amount of work that could be done. No one would have entertained the idea of rewriting a project in Rust before this. It hasn't replaced anyone's actual job and they still had to hire a high paid employee to pull it off.
I suspect rather than hire less people we will just produce more code changes.
diarrhea 42 minutes ago [-]
But do the markets care about a Postgres in Rust? Probably not, or at least not right away. It is a long way towards commercial success.
> I suspect rather than hire less people we will just produce more code changes.
Why? Towards what end? Code changes are output, not outcome. It also needs to be connected to someone willing to pay you hard cash. That is the hard part, a race to the bottom, and the reason I also believe there will be downwards pressure on salaries and even employment.
koe123 2 hours ago [-]
I think this problem is especially perfect for an LLM though. Its effectively translating with a great test harness.
As for your other arguments, I’m not certain we won’t just Jevon's Paradox into more work.
solid_fuel 2 hours ago [-]
Ehh, I think this take needs a grain of salt.
There's a few significant facts here:
- They had an existing functional Zig implementation
- They had an existing test suite for the Zip implementation
- They had a separate JavaScript compliance test suite with ~ 1 million tests
- The person overseeing the rewrite was responsible for a huge portion of the existing codebase and was very familiar with the existing architecture and problems
I don't think that middle management at most companies is going to be starting from that same point when it comes to building or updating something. Generally, I don't think there are many projects out there that have such robust existing tests and specifications.
In this case, the engineering behind the tests and specifications need to also be considered part of the process, since without those you wouldn't be able to build a control loop in the same way.
> 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.
All that really proves is that you’d be an astoundingly poor choice to hire. If you’re spending $200k on someone that doesn’t know at least two out of three (context, Rust, or Zig), you’re just burning money.
That’s not to say that experienced engineers familiar with the stack would or wouldn’t be able to do it in a year, but they’d certainly have a better shot at it.
It’s also not that this project sprung into thin air from a quick prompt and LLM magic… it was driven by a dedicated, highly talented, subject matter expert with extensive SWE background and extensive support from the leading experts in the world. You’ll continue to need someone to steer the ship, even in the Wal-Marts and Targets. An LLM is only ever as good as the input it’s given.
pier25 5 hours 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.
alexjurkiewicz 4 hours ago [-]
Paying customers get LTS. Are any paying customers asking for a Zig branch LTS? Or are you expecting open source maintainers to do free work for no particular reason?
pier25 3 hours ago [-]
Java, Node, and .NET have LTS versions all of which are free to use.
> Or are you expecting open source maintainers to do free work for no particular reason?
Free work? Last I heard Anthropic had acquired Bun.
Tadpole9181 42 minutes ago [-]
Are you asking for an LTS Zig version as a member of Anthropic?
atonse 4 hours ago [-]
LTS is more relevant if there was any kind of compatibility that was broken. They still haven’t released 1.4 even though it seems to have gone extremely well by every metric in the wild, with tons of people using Claude code with no regressions in a month. Nothing to me suggests they’re being careless here.
In fact, he had two adversarial reviewer Claude instances on every code change, every line. I don’t know a single human team that does two independent reviews of every line, except maybe the people that wrote space shuttle software.
Also they fixed the memory leak. How does it matter what language it’s written in? At the end of the day, people use it to run their typescript code among other things.
How many bun users care that’s it’s written in zig? I certainly don’t. I’ve been using bun for 2 years and I think I looked up zig once. It’s just not relevant.
Did it get more stable? Yes. Slimmer? Yes. More performant? Yes. Is there any proof that it got LESS secure? No. The code has been out for two months. By now all the nay sayers would’ve found the smoking gun. They haven’t. How much more proof would you like that this was a resounding success?
This is our new reality. The agents are so good that projects like this are in the realm of possible. That’s exciting.
pier25 3 hours ago [-]
> LTS is more relevant if there was any kind of compatibility that was broken
Do we know 100% for certain that this isn't the case? No.
In fact it would be naive to think a rewrite of this magnitude wouldn't introduce new bugs and/or unexpected changes in behavior.
> Nothing to me suggests they’re being careless here.
Plenty of reasons suggest this including the lack of an LTS or any kind of thought put into such a massive transition.
atonse 1 hours ago [-]
Again, the code’s been out for two months. And by many accounts, many people would clearly love to scream loudly about all the things that broke.
There were initial analyses done on the port. And things continue to get refactored. But is there any slam dunk article where someone actually found any regression in functionality or stability? We’re seeing the opposite. Dozens of bugs fixed. We don’t have to theorize. They’ve been running this experiment for 2 months, with all the code out in the open.
It just feels like after two months, people want to cling to the _idea_ that this was reckless, without evidence of any meaningful negative impact.
iknowstuff 3 hours ago [-]
1.4 has no breaking changes from 1.3 so why would there be an LTS and any guarantees for people staying on 1.3? All known regressions have been fixed like any other release as far as I can tell
1 hours ago [-]
dabinat 6 hours 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.
jeremyloy_wt 6 hours ago [-]
They napkin math is fairly easy to do. One human works around 250 days per year, and if we assume Bay Area salaries we could assume ~300k/y conservatively for a fully loaded cost.
$1200 per day.
Your estimation is 50*11 days so $660,000. That’s 4x what Claude cost.
That’s assuming that you actually get those 50 people to work without blockers, stepping on each other, or other coordination issues. The coordination complexity alone is astounding.
I don’t like it necessarily, but Claude wins here, easily. It’s not close.
piskov 6 hours ago [-]
Unless you hire smart people from EU and what have you (especially ex-USSR)
Which takes us to a point of future US dev salaries if this thing with agents gets better more and more
tclancy 2 hours ago [-]
Sure, but can we not work out how to make humans more efficient for less money? There are obvious optimizations there that none of us would like to be part of.
these 3 hours ago [-]
> That’s assuming that you actually get those 50 people to work without blockers, stepping on each other, or other coordination issues. The coordination complexity alone is astounding.
This is a question of exceptional management, which needs to be present both in the Claude and human cases, and is scarce. Not everyone given the Claude tokens would be able to deliver the same result.
slopinthebag 5 hours ago [-]
Why assume the upper level salary here? Using senior level developers making astronomical salaries for what is a mechanical line-by-line port would be a poor financial decision.
What does the math look like with 25 devs making ~100k and doing it in 22 days? I’m sure you could find a reasonable combination which costs less. And if you’re already paying the devs the salary, it’s basically free (minus the opportunity cost of them not working on other things).
Philpax 6 hours ago [-]
I think it'd take you at least eleven days to meaningfully coordinate 50 people!
tekacs 6 hours ago [-]
I feel like a core difference is that the AI implementor can get cheaper/faster (and indeed _uniformly_ better), whereas it would be very difficult for the same humans to do so.
Even if this is not the right answer today, it can at the very least serve as a herald of a possible future, no?
yomismoaqui 4 hours ago [-]
Your example of using 50 people for this reminded me of the classic “Nine women can’t make a baby in one month.”
HINT: those 50 people must be coordinated...
ignoramous 5 hours ago [-]
> I suspect Claude might be faster and therefore cheaper, but maybe not by a lot.
While Jarred used Mythos-class model, some open weights, if they were as capable (certainly, GLM 5.2 looks the part), would have been way, way cheaper than professionals.
Approx costs:
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.
Jenk 6 hours ago [-]
$165k won't get you far on salaried engineers. There's every chance that 1 engineer, assuming Anthropic employs them, is on $500k or more. Assuming average of $336k in that pool of 50 engineers, then for 11 days for 50 engineers you've spent $710k[0].
[0]The maths I used (posting because I'm tired and prone to mistakes):
$336,000 / 260 (working days of the year) = ~$1,292.
$1,292 * 11 * 50 = ~$710,769
bhaak 5 hours ago [-]
You don't need top engineers to port a program from one language to the other. Outsource it to India.
Of course, then you can also ask, could it have been done with a cheaper model. Probably yes. But then you wouldn't get free marketing.
minimaltom 4 hours ago [-]
I agree you probably don't need top-dollar bay-area engineers for this, but hardcore outsourcing to a LCOL probably isnt going to work either due to novelty and generally being setup to do the more rote thing (generalizing a ton here obvi). This feels like something in the middle.
internet2000 3 hours ago [-]
Outsourcing to India would actually be the disaster the naysayers were saying this would be.
simonw 4 hours ago [-]
Have you seen the "rewrite by outsourcing to India" thing work?
duhhhhh1212 3 hours ago [-]
What a weird thing to say. The phrase “outsourcing to India” being used as shorthand for “you don’t need top engineers.” The nationality stereotypes are mean and degrading.
PeterHolzwarth 34 minutes ago [-]
And at a macro level, often found to be accurate due to how the businesses in India operate. Poll the west's engineers: you'll find that engineering from India is not currently viewed very favorably, in general.
There are excellent engineers in India, but the system they operate in unfortunately doesn't allow them to shine.
simonw 2 hours ago [-]
That's fair, I shouldn't have commented that. I don't like the national stereotypes at all - I see "outsource to India" as being more about less expensive engineers than not needing "top engineers".
That said, I don't think "rewrite from one language to another" with inexpensive engineers is a pattern that works. Happy to be proven wrong.
theLiminator 7 hours 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 7 hours 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 6 hours ago [-]
I like using Odin with LLMs for this. it's a simple statically typed language with no GC and very fast compile
gpm 7 hours 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.
theLiminator 7 hours ago [-]
Maybe something like Hylo? But personally I don't see anything displacing rust for the next few years, as I think there's enough rust in the training data for it to be the best "serious" language for agentic systems-level development.
It's really the only systems language in its exact niche.
gpm 6 hours ago [-]
I'm not very familiar with Hylo, but I think it's in the opposite direction from rust than what I'm suggesting.
I'm suggesting a language where there's no difference between Box<u32> and u32. &Vec<u8> and &[u8] are the same thing. I don't need to write Box::new(...) around my closures to pass them to functions that take a function pointer. This comes with overhead, but in exchange we get simpler less verbose code. I.e. a language that isn't systems level, and isn't particularly machine-empathetic. But still has all the lightweight-formal-methods power of rust with lifetimes and mutable vs shared borrows (and thus references to references) and so on.
My impression of Hylo is that it's purpose is to be a similarly low level systems language to rust, just with a less complicated, and as a consequence less expressive, lightweight formal methods system for proving correctness.
I agree I don't expect rust to be displaced anytime soon. It creates a lot of time to create a good compiler, and a lot more to create the ecosystem of code, tools, and community around it.
lifthrasiir 6 hours ago [-]
The project in question needed lots of near-instant human judgements and the iteration loop had to be extremely tight. Maybe Rust should be reconsidered once it gets stabilized enough, but not right now.
losvedir 5 hours 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 5 hours 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…
grandimam 27 minutes 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.
jatins 14 minutes 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
YuechenLi 7 hours 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.
benced 7 hours ago [-]
Not a compiler expert - shouldn't language verbosity and binary size be, at best, very loosely related?
steveklabnik 7 hours ago [-]
I don't think you can draw the conclusion that source length and binary size are correlated. For example, in Rust:
Rust's enums can carry data. You can write the same thing in C, but because it does not have the enum feature, you have to do it yourself. They're sometimes called "tagged unions" for a reason, you use a union + a tag when doing it by hand:
I haven't actually compiled this, but it should compile to almost the exact same, if not literally the exact same, machine code. Yet one is way more verbose than the other.
pavon 6 hours ago [-]
I think you are saying the same thing as benced - just because Zig source code is verbose is no reason to assume the binary should be larger.
steveklabnik 6 hours ago [-]
I read my parent ask asking a question: is there a correlation, or not?
I am saying that I do not believe there is a correlation between source code length and binary length. If that's what benced meant by their question, then yes, I agree :)
esjeon 6 hours ago [-]
I’m quite sure there is a certain amount of correlation unfortunately, mainly because there are micro patterns (e.g. IO, allocator) that can’t be modularized into functions. Lots of manual copy-pasta.
14113 6 hours ago [-]
It required a little bit of messing with optimisation settings and library generation in Rust, but they emit very very similar x86-64 assembly:
Nice, thank you for picking up after my laziness. Surely only a few bytes different in the binary, and much, much smaller of a delta than the source.
aw1621107 5 hours ago [-]
You can further reduce the difference by passing Expr by pointer in the C version. At that point I think the only difference in the assembly is the order in which the cases are handed.
steveklabnik 3 hours ago [-]
Ah yeah, honestly both should probably be passed by pointer anyway. But that makes me wonder about the actual differences here and why... maybe something fun to dig into.
YuechenLi 6 hours ago [-]
Fair point, I phrased that too broadly, and you are right about the loose correlation.
What I was gesturing at, badly, was more that Zig’s low-abstraction / explicit-by-default syntax tends to have you write more boilerplate-y code in general that are more annoying to write and maintain, while not buying you enough over a language with better tooling and ecosystem and compiler optimization like Rust.
surajrmal 6 hours ago [-]
Why? Python is terse but has large binaries because of the runtime overhead. C++ is fairly verbose but can make useful binaries in double digit kib.
giancarlostoro 7 hours ago [-]
> Ironically, Zig is a programming language that's probably best written by LLMs, since they can tolerate actually tolerate the verbosity.
Rust in my opinion feels the same.
pjjpo 6 hours ago [-]
I have found LLMs struggle with Rust's constraints - they are optimized to produce code that passes the tests, not necessarily good code. So instead of working out lifetimes and borrowing, it will be happy to copy a buffer many times without thought. This means I have to still go through line by line to review and often rewrite either by hand or with another LLM iteration.
There may be some prompting that can help with this but I suspect there is a fundamental tension between writing working code vs good code in LLMs. Go is popular for being simple, making it easy to jump in and write something fast and stable - minimizing the gap between working and good code probably helps out the LLMs a lot.
afavour 6 hours ago [-]
I don’t feel the verbosity with Rust. Haven’t written it in a while but now in the LLM era I’m looking forward to saying “sort out the lifetime errors for me”.
i_am_a_peasant 6 hours ago [-]
I trust a lot more Rust code generated by an LLM than anything else ngl.
sroussey 7 hours ago [-]
Agree. But just because it feels the same doesn’t mean it compiles the same.
honeycrispy 7 hours ago [-]
That can often depend on how you write it.
tapirl 6 hours ago [-]
Zig is indeed verbose in some aspects, but not overall. For example, its `try error-union` syntax eliminates a lot of boilerplate code.
The main reason why Zig is verbose in some aspects is the main goal of Zig is program performance. It is a worthy tradeoff.
typ 6 hours ago [-]
Abstraction doesn't necessarily lead to a smaller binary.
Much of the bloat in modern software is indeed due to (bad) abstractions.
reinitctxoffset 6 hours ago [-]
The twenty percent quoted is referring to the size of the compiled artifact (one assumes ELF or Mach-O).
Whether or not a language is verbose or obscure is very much about your coordinate system. Not unlike safety.
I think C is a reasonable zero for both things.
Zig is more succinct and safer than C while still being comparably ergonomic. Rust is (mostly) safer and more succinct than Zig while being dramatically less ergonomic (take it up with Wadler memory chads, no one likes affine types).
I like lean4, which is dramatically safer, more succinct, and more ergonomic than Rust.
But I can see why some would say it's a bit too succinct.
metaltyphoon 2 hours ago [-]
> Rust is (mostly) safer and more succinct than Zig while being dramatically less ergonomic
This is just your opinion.
reinitctxoffset 39 minutes ago [-]
Well, it's my opinion. But it's also the opinion of the broader functional programming community from 1993 to the present day. This notably includes the quite serious Haskellers who designed Rust for the highly specific and demanding requirements of the Servo rendering engine in ~2010. Being as my two parents in web browser layout optimizations were both filed in 2009 I took considerable interest.
It wasn't until 2014 that Orchard formalized the coeffect discharge calculus via indexed monad that makes a binary ownership semantic irretrievably sunsetted as a degenerate case.
It's my opinion. I'm not concerned about how informed that opinion is.
bsder 6 hours ago [-]
Naive was 4-9% on the initial pass.
Also note that the larger percentages were against already smaller binaries. That smells like there was a single large constant number that got saved somewhere rather than general improvements.
> After that initial shrinkage, the team explored more opportunities for binary size reduction using linker optimizations like Identical Code Folding, removing unused data from ICU, and lazily decompressing small parts of libicu with a zstd dictionary on-demand.
I'd be VERY interested in seeing what the individual effects of those parts were.
thevinter 8 hours 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 2 hours 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.
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 4 hours 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.
hansvm 7 hours 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.
smasher164 3 hours 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 2 hours 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 2 hours 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.
bel8 7 hours 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.
Buttons840 6 hours 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.
So does that mean the rewrite made you less skeptical?
Buttons840 6 hours 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.
achristmascarl 6 hours 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.
ianm218 7 hours 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.
anonyonoor 5 hours 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.
minimaxir 8 hours 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.
quux0r 4 hours 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.
rifty 4 hours 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.
surround 5 hours ago [-]
It seems that Deno made the right decision by choosing Rust from the get-go.
WhyNotHugo 4 hours ago [-]
> around $165,000 at API pricing
This is the bit I was really curious about. Definitely not something within reach for us mortals.
duhhhhh1212 7 hours 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 7 hours 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.
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 7 hours 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?
didibus 6 hours 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.
pier25 6 hours ago [-]
> Compiler errors are a better feedback loop than a style guide
So essentially this whole re-write was about making Bun LLM compatible.
suby 5 hours 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.
jsnell 4 hours 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?
> 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.
yomismoaqui 4 hours ago [-]
We need to coin a new term for the paranoic feeling that every text on the internet is written by LLMs.
"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.
incognito124 6 hours 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 5 hours 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 5 hours 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?
pier25 5 hours ago [-]
Who in their right mind would immediately migrate their production apps into a complete re-write of a runtime?
It would be naive to think there aren't new bugs or changes in behavior introduced in 1.4.
dgacmu 5 hours ago [-]
(Well, the answer is "Anthropic, with claude code", but I'm not in possession of material information related to whether they are or are not in their right minds.)
But yes, of course there will be new bugs. But that's why 1.4.x for x > 0 is interesting. If the branch is being used and people are not reporting _more_ bugs, and the bugs you care about it are being fixed (successfully) on it, and it passes your tests, etc., ... I dunno. This is an application domain where you can do some pretty solid testing of it, comparative fuzzing, etc., so it doesn't strike me as entirely mad to jump over after a few minor releases where you can see the bug trajectory.
pier25 3 hours ago [-]
> Well, the answer is "Anthropic, with claude code"
Anthropic is not exactly the hallmark of engineering excellence... quite the contrary.
> But yes, of course there will be new bugs
Obviously, which is why more thought should have been put into the transition.
Not everyone will want to yolo their production projects into such a massive rewrite overnight.
m00dy 47 minutes ago [-]
Rust is the clear winner of LLM era. You can't say otherwise.
tangenter 7 hours 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?
SergeAx 6 hours 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.
leecommamichael 6 hours 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.
ivanjermakov 6 hours 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.
ares623 4 hours ago [-]
What does it say that it took 2 months to write the blog post? (or at least have it published)
tln 2 hours ago [-]
That a human wrote it?
Barrin92 5 hours 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
giancarlostoro 7 hours 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 7 hours 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 7 hours 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.
MindSpunk 4 hours ago [-]
Curious why you'd move from C# to Rust. C# has you covered mostly for memory safety so I would guess performance or lots of shared memory across threads?
benced 6 hours 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.
BearOso 6 hours ago [-]
I think putting it in terms of API pricing is oversimplifying disingenuously. Anthropic still hasn't pulled the rug out from under us, so I'm sure it cost a great deal of money once everything comes together, likely surpassing 1.5M. Summarily, they got the result faster, which a group of engineers couldn't do, but at a greater expense.
benced 5 hours ago [-]
GLM 5.2 (open-weights) is at or near Opus 4.7 level performance already. I think it's unlikely Anthropic will be able to durably charge us much more than the CapEx depreciation cost of GPUs + the OpEx of running them for non-frontier models (which Fable will be in 6 months to a year).
5 hours ago [-]
johnfn 6 hours 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?
5 hours ago [-]
DobarDabar 6 hours ago [-]
[dead]
fernando-ram 7 hours ago [-]
[flagged]
gpm 7 hours ago [-]
1. There's no comparison - it's just showing a snapshot in time (apparently post port). You literally can't!?
2. Of your 8 comments on this site, 7 are spamming links to this site. I at least don't think that's ok.
fernando-ram 7 hours ago [-]
Yeah, thats on me I got a little lazy. Im not trying to spam, It my project because I think its cool to see projects this way and I think it can make software more digestable and less nebulous a concept
fernando-ram 6 hours ago [-]
fixed it
rvz 8 hours 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.
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 8 hours ago [-]
*whoosh* goes the joke.
steveklabnik 7 hours ago [-]
Hacker News does not have a meme-y culture, and this post takes this topic pretty seriously and is technically interesting.
It's not so much that I missed that it was a joke, I just don't think that it really added to the discussion.
What you've edited it to is a much better comment.
rvz 7 hours ago [-]
[flagged]
QuaternionsBhop 7 hours ago [-]
Jokes require mutual context. You failed to create a joke because you did not ensure the prerequisites were met.
rvz 6 hours ago [-]
> Jokes require mutual context.
The article itself is the context. Even the chatbots: ChatGPT, Claude and Gemini 'understand' the joke in the comment.
Go ahead and ask them.
> You failed to create a joke because you did not ensure the prerequisites were met.
The prerequisites was for you to read the article first.
The joke:
"Now Claude, rewrite Claude Code from TypeScript to Rust. Make absolutely zero mistakes."
You: ???
minimaxir 3 hours ago [-]
As steveklabnik noted above, Hacker News does not have a meme-y culture. Just because you made a joke doesn't mean it's inherently immune to criticism, especially when using the lowest-effort, most-overdone meme around agentic development adds nothing to the discussion. Get new material.
rvz 3 hours ago [-]
> As steveklabnik noted above, Hacker News does not have a meme-y culture.
For this one, yes it does. Go search this one up yourself. [0]
Literally everyone in the comments in [0] and even the author of this post acknowledges the joke except for you two.
It. Is. A. Joke. Calm down.
> Just because you made a joke doesn't mean it's inherently immune to criticism
No one is arguing that. It's OK that you won't admit that you didn't get it either.
> especially when using the lowest-effort, most-overdone meme around agentic development adds nothing to the discussion. Get new material.
You're being over-dramatic. Why is that you can't take a simple joke? Surely you've never joked on this site before.
Its not even that, its one of the most overdone jokes as your link suggests.
merb 7 hours ago [-]
1 Developer with a 200k budget for tools.
classicposter 7 hours ago [-]
This slop rewrite introduced new vulnerabilities and regressions.
wilkystyle 7 hours ago [-]
Care to elaborate?
dfabulich 7 hours 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.
Georgelemental 7 hours ago [-]
Pre-release code had bugs that were fixed before the release? Why is that a problem? That's the point of having a testing and release process
pier25 6 hours ago [-]
what about new bugs introduced after the rewrite?
simonw 6 hours ago [-]
> 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.
I mean yeah, that's what this whole post is about. It's about the process of going from that original state to something that's now shipping in production.
benced 7 hours ago [-]
> We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.
God forbid an engineer express uncertainty.
6 hours ago [-]
Atotalnoob 7 hours ago [-]
Uncertainty is one thing, but a high chance means it’s 51% or higher to me.
Based on that, the bun rewrite messaging was fairly misleading.
wccrawford 6 hours ago [-]
That was their estimate at the time, based off the information they had. You can't ask more of someone than that.
Either they estimated poorly, or it ended up the lesser portion of their estimate after all. After all, unless the estimate is 100%, there's always a chance it'll fall into the other portion.
jen20 6 hours ago [-]
To understand your error, consider that in the month leading up to the 2016 US presidential election, the widely-accepted probabilities were between 70% (Five-Thirty-Eight) and 90% (Reuters) in favour of Clinton.
hansvm 6 hours ago [-]
[dead]
7 hours ago [-]
himata4113 6 hours 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 6 hours ago [-]
> 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.
erichocean 6 hours 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 5 hours 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”.
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.
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.
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.
I have no idea how game devs handle big refactors other than lots of manual testing.
Or you could do it [as I recall the project being called] the scientist way. You still have the old code, so you could replay inputs against each and compare. Probably more realistic because uncompressed video would be a ridiculously huge dataset. This would be more resilient in the face of testing hardware and driver drift.
Historically game engines are the worst offenders when it comes to unit testing. I'm not sure if that's still the case - but that's why I erred on the side of integration tests.
[1] https://docs.rs/hot-lib-reloader/latest/hot_lib_reloader/
Such as? You can't be referring to hot reload alone because you can already do that in both C++ and C#.
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).
In C, usually yes.
In C++, sometimes yes. It depends on how template-heavy the code is, but if you have some discipline you can keep most logic out of headers and thus easily splittable.
In Rust, almost always no, because of circular dependencies. You can try to work around it by adding `dyn Trait` everywhere, but that requires a lot of code changes and comes at big ergonomic costs (and a small runtime cost).
Which is why in practice, Rust compilation units are almost always larger than C++ or C compilation units. Rust can sometimes be competitive with C++ on compilation speed anyway, thanks to a smarter build system and not having to re-parse headers a billion times, but usually it's slower.
This feels like a strange, overly-specific complaint. It reads a bit like “When I write entangled code, it’s hard to untangle”. Like, yeah, the only thing that’ll save you from that is…not writing entangled code? I’m not of the opinion that the argument of “yeah but C lets me do whacky stuff” is a particularly strong line.
FWIW, letting a module grow, and then splitting modules up by cut-and-pasting stuff out along natural domain lines generally _is_ how I write Rust. Largely due to how easy it makes it to construct modules and submodules.
Rust is just as fast as C++.
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.
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.
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.
If I'm vibe coding something I'm always just going to do it in Rust.
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.
All that said, I use rust for everything.
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.
How niche are we talking? Rust is deployed on a bunch of popular microcontrollers at this point
I expect if he'd spent $165,000 running Fable against the Zig version he could have got a 5% performance improvement, too.
I've been working on a new rewrite that's focused on beating Postgres on performance. As of this morning I got to 100% of the tests passing and have meaningful performance gains over Postgres.
After having used 2 full weeks of 20x Max plan tokens on Fable over the weekend (coding all day Saturday and Sunday on a non-trivial project, tasks across full stack, mix of adding features, reviewing code, and fixing bugs), I’m confident if he’d spent $165,000 in Opus tokens the port would have gone more or less just as well (and probably for less than $165,000). Especially so with the system they set up with all the custom workflows, adversarial reviews, extensive test coverage, etc.
But I get your point is probably more about Jarred’s experience level and the high cost than the specific model used other than it being SOTA. I’m just being pedantic and feeling a bit disappointed with Fable’s real world performance after all the hype.
> I expect if he'd spent $165,000 running Fable against the Zig version he could have got a 5% performance improvement, too.
Totally agree and in fact I’m sure it could be done with significantly less cost even if they stuck with Fable instead of Opus which I’m sure could also do it.
It's not great for Zig if you have to put in more work to end up at the same place efficiency-wise, especially for a language marketed at people who like to get the most out of their metal.
They could have done the same in Zig, even though it probably shows cargo is better at this than build.zig.
More precisely speaking: GC languages are said to delay memory problems far beyond the horizon, which is often unreachable throughout the project's history. Zig can be a similar case.
But they wouldn't get a change to the structural issues that created the issues in the first place. They'd end up "ke[eping] fixing these kinds of bugs one-off in perpetuity".
Not sure why people use it.
I just haven’t found another language that just makes sense. Zig doesn’t hide anything from you
Did you compare the code before/after? It's a mechanical line-by-line port, and most of the code is identical to the old version, just with Rust syntax. They have an example in the blog post.
[1] For example, as a random sample, https://github.com/oven-sh/bun/blob/bun-v1.3.14/src/css/medi... -> https://github.com/oven-sh/bun/blob/4924862cffbf671792d47c92...
> I rewrote Bun in Rust using about 50 dynamic workflows in Claude Code run continuously over the course of 11 days.
> Excluding comments, Bun is 535,496 lines of Zig.
> How do you review a PR with +1 million lines added? How do you start to build the confidence needed to responsibly merge large quantities of LLM-authored code? A language-independent test suite with a million assertions, adversarial code review and when something does go wrong, fixing the process that generates the code instead of hand-fixing the code.
That’s vibe coding. This blog post is an ad for Claude, nothing more.
I'm not trying to spin up some kind of conspiracy theory here, but I'm not sure to what extent Anthropic does have any vested interest in this project (in fiscal terms at least) because the reputational fallout could be significantly delayed and might just not be big enough to matter.
That's a very big reason not to screw this up.
This is not an assertion you are qualified to make
> Go read any analysis of the Claude Code leak for proof
You seem to be implying that Claude code is unmaintainable. Yet they appear to be maintaining it just fine. Did I misunderstand your implication?
And the fact is that they are maintaining it and it is one of the most successful software products of all time and is earning them mountains of cash. By any metric it is a successful product. So obviously whatever they are doing is working.
They rewrote the entire thing with extensive LLM use.
It is abundantly clear that their idea of maintainable and yours probably don't match up.
It's apparently out there, shipped in the real world, with people saying it's good. I think it's a pretty clear win for them.
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.
Also it is debatable they got any value at all from this. Anyone who wrote unsafe rust and also wrote zig would know that unsafe rust is much much more unsafe in comparison
I suspect rather than hire less people we will just produce more code changes.
> I suspect rather than hire less people we will just produce more code changes.
Why? Towards what end? Code changes are output, not outcome. It also needs to be connected to someone willing to pay you hard cash. That is the hard part, a race to the bottom, and the reason I also believe there will be downwards pressure on salaries and even employment.
As for your other arguments, I’m not certain we won’t just Jevon's Paradox into more work.
There's a few significant facts here:
- They had an existing functional Zig implementation
- They had an existing test suite for the Zip implementation
- They had a separate JavaScript compliance test suite with ~ 1 million tests
- The person overseeing the rewrite was responsible for a huge portion of the existing codebase and was very familiar with the existing architecture and problems
I don't think that middle management at most companies is going to be starting from that same point when it comes to building or updating something. Generally, I don't think there are many projects out there that have such robust existing tests and specifications.
In this case, the engineering behind the tests and specifications need to also be considered part of the process, since without those you wouldn't be able to build a control loop in the same way.
Also I'm pretty sure Walmart directly hires software engineers and doesn't just outsource everything - https://careers.walmart.com/us/en/results?searchQuery=softwa...
All that really proves is that you’d be an astoundingly poor choice to hire. If you’re spending $200k on someone that doesn’t know at least two out of three (context, Rust, or Zig), you’re just burning money.
That’s not to say that experienced engineers familiar with the stack would or wouldn’t be able to do it in a year, but they’d certainly have a better shot at it.
It’s also not that this project sprung into thin air from a quick prompt and LLM magic… it was driven by a dedicated, highly talented, subject matter expert with extensive SWE background and extensive support from the leading experts in the world. You’ll continue to need someone to steer the ship, even in the Wal-Marts and Targets. An LLM is only ever as good as the input it’s given.
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.
> Or are you expecting open source maintainers to do free work for no particular reason?
Free work? Last I heard Anthropic had acquired Bun.
In fact, he had two adversarial reviewer Claude instances on every code change, every line. I don’t know a single human team that does two independent reviews of every line, except maybe the people that wrote space shuttle software.
Also they fixed the memory leak. How does it matter what language it’s written in? At the end of the day, people use it to run their typescript code among other things.
How many bun users care that’s it’s written in zig? I certainly don’t. I’ve been using bun for 2 years and I think I looked up zig once. It’s just not relevant.
Did it get more stable? Yes. Slimmer? Yes. More performant? Yes. Is there any proof that it got LESS secure? No. The code has been out for two months. By now all the nay sayers would’ve found the smoking gun. They haven’t. How much more proof would you like that this was a resounding success?
This is our new reality. The agents are so good that projects like this are in the realm of possible. That’s exciting.
Do we know 100% for certain that this isn't the case? No.
In fact it would be naive to think a rewrite of this magnitude wouldn't introduce new bugs and/or unexpected changes in behavior.
> Nothing to me suggests they’re being careless here.
Plenty of reasons suggest this including the lack of an LTS or any kind of thought put into such a massive transition.
There were initial analyses done on the port. And things continue to get refactored. But is there any slam dunk article where someone actually found any regression in functionality or stability? We’re seeing the opposite. Dozens of bugs fixed. We don’t have to theorize. They’ve been running this experiment for 2 months, with all the code out in the open.
It just feels like after two months, people want to cling to the _idea_ that this was reckless, without evidence of any meaningful negative impact.
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.
$1200 per day.
Your estimation is 50*11 days so $660,000. That’s 4x what Claude cost.
That’s assuming that you actually get those 50 people to work without blockers, stepping on each other, or other coordination issues. The coordination complexity alone is astounding.
I don’t like it necessarily, but Claude wins here, easily. It’s not close.
Which takes us to a point of future US dev salaries if this thing with agents gets better more and more
This is a question of exceptional management, which needs to be present both in the Claude and human cases, and is scarce. Not everyone given the Claude tokens would be able to deliver the same result.
What does the math look like with 25 devs making ~100k and doing it in 22 days? I’m sure you could find a reasonable combination which costs less. And if you’re already paying the devs the salary, it’s basically free (minus the opportunity cost of them not working on other things).
Even if this is not the right answer today, it can at the very least serve as a herald of a possible future, no?
HINT: those 50 people must be coordinated...
While Jarred used Mythos-class model, some open weights, if they were as capable (certainly, GLM 5.2 looks the part), would have been way, way cheaper than professionals.
Approx costs:
Salary info: https://www.levels.fyi/companies/anthropic/salaries/software...
[0]The maths I used (posting because I'm tired and prone to mistakes):
Of course, then you can also ask, could it have been done with a cheaper model. Probably yes. But then you wouldn't get free marketing.
There are excellent engineers in India, but the system they operate in unfortunately doesn't allow them to shine.
That said, I don't think "rewrite from one language to another" with inexpensive engineers is a pattern that works. Happy to be proven wrong.
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.
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.
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.
It's really the only systems language in its exact niche.
I'm suggesting a language where there's no difference between Box<u32> and u32. &Vec<u8> and &[u8] are the same thing. I don't need to write Box::new(...) around my closures to pass them to functions that take a function pointer. This comes with overhead, but in exchange we get simpler less verbose code. I.e. a language that isn't systems level, and isn't particularly machine-empathetic. But still has all the lightweight-formal-methods power of rust with lifetimes and mutable vs shared borrows (and thus references to references) and so on.
My impression of Hylo is that it's purpose is to be a similarly low level systems language to rust, just with a less complicated, and as a consequence less expressive, lightweight formal methods system for proving correctness.
I agree I don't expect rust to be displaced anytime soon. It creates a lot of time to create a good compiler, and a lot more to create the ecosystem of code, tools, and community around it.
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…
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.
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
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.
I am saying that I do not believe there is a correlation between source code length and binary length. If that's what benced meant by their question, then yes, I agree :)
https://godbolt.org/z/89W4srz4d
What I was gesturing at, badly, was more that Zig’s low-abstraction / explicit-by-default syntax tends to have you write more boilerplate-y code in general that are more annoying to write and maintain, while not buying you enough over a language with better tooling and ecosystem and compiler optimization like Rust.
Rust in my opinion feels the same.
There may be some prompting that can help with this but I suspect there is a fundamental tension between writing working code vs good code in LLMs. Go is popular for being simple, making it easy to jump in and write something fast and stable - minimizing the gap between working and good code probably helps out the LLMs a lot.
The main reason why Zig is verbose in some aspects is the main goal of Zig is program performance. It is a worthy tradeoff.
Whether or not a language is verbose or obscure is very much about your coordinate system. Not unlike safety.
I think C is a reasonable zero for both things.
Zig is more succinct and safer than C while still being comparably ergonomic. Rust is (mostly) safer and more succinct than Zig while being dramatically less ergonomic (take it up with Wadler memory chads, no one likes affine types).
I like lean4, which is dramatically safer, more succinct, and more ergonomic than Rust.
But I can see why some would say it's a bit too succinct.
This is just your opinion.
It wasn't until 2014 that Orchard formalized the coeffect discharge calculus via indexed monad that makes a binary ownership semantic irretrievably sunsetted as a degenerate case.
It's my opinion. I'm not concerned about how informed that opinion is.
Also note that the larger percentages were against already smaller binaries. That smells like there was a single large constant number that got saved somewhere rather than general improvements.
> After that initial shrinkage, the team explored more opportunities for binary size reduction using linker optimizations like Identical Code Folding, removing unused data from ICU, and lazily decompressing small parts of libicu with a zstd dictionary on-demand.
I'd be VERY interested in seeing what the individual effects of those parts were.
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.
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...
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.
It seems the reports of Bun's death have been greatly exaggerated.
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
The most significant revelation for me was that Claude Code has been using the rewrite without much fanfare since June 17th.
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.
It's pretty exciting.
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.
This is the bit I was really curious about. Definitely not something within reach for us mortals.
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
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.
So essentially this whole re-write was about making Bun LLM compatible.
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.
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.
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
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.
I'm sorry but that is insane, how was this never fixed before the rewrite?
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.
It would be naive to think there aren't new bugs or changes in behavior introduced in 1.4.
But yes, of course there will be new bugs. But that's why 1.4.x for x > 0 is interesting. If the branch is being used and people are not reporting _more_ bugs, and the bugs you care about it are being fixed (successfully) on it, and it passes your tests, etc., ... I dunno. This is an application domain where you can do some pretty solid testing of it, comparative fuzzing, etc., so it doesn't strike me as entirely mad to jump over after a few minor releases where you can see the bug trajectory.
Anthropic is not exactly the hallmark of engineering excellence... quite the contrary.
> But yes, of course there will be new bugs
Obviously, which is why more thought should have been put into the transition.
Not everyone will want to yolo their production projects into such a massive rewrite overnight.
However, an open-sourced tool like that 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.
I think that when you have a $165,000 hammer, all of your problems begin to look a lot like nails.
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.
2. Of your 8 comments on this site, 7 are spamming links to this site. I at least don't think that's ok.
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
> 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.
It's not so much that I missed that it was a joke, I just don't think that it really added to the discussion.
What you've edited it to is a much better comment.
The article itself is the context. Even the chatbots: ChatGPT, Claude and Gemini 'understand' the joke in the comment.
Go ahead and ask them.
> You failed to create a joke because you did not ensure the prerequisites were met.
The prerequisites was for you to read the article first.
The joke:
"Now Claude, rewrite Claude Code from TypeScript to Rust. Make absolutely zero mistakes."
You: ???
For this one, yes it does. Go search this one up yourself. [0]
Literally everyone in the comments in [0] and even the author of this post acknowledges the joke except for you two.
It. Is. A. Joke. Calm down.
> Just because you made a joke doesn't mean it's inherently immune to criticism
No one is arguing that. It's OK that you won't admit that you didn't get it either.
> especially when using the lowest-effort, most-overdone meme around agentic development adds nothing to the discussion. Get new material.
You're being over-dramatic. Why is that you can't take a simple joke? Surely you've never joked on this site before.
[0] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
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.
I mean yeah, that's what this whole post is about. It's about the process of going from that original state to something that's now shipping in production.
God forbid an engineer express uncertainty.
Based on that, the bun rewrite messaging was fairly misleading.
Either they estimated poorly, or it ended up the lesser portion of their estimate after all. After all, unless the estimate is 100%, there's always a chance it'll fall into the other portion.
I will be a lot more excited when this is possible with <10k of api costs.
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”.