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.
> 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.
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.
> 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.
Not a very popular game engine (never got the attention that the likes of Godot did), but it's nice to work with! It’s up there with Stride in regards to the “indie” game engines I like, maybe alongside jMonkeyEngine (since you typically don’t see that many Java game engines either).
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?
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.
> Gosh, I don't think any game engines have particularly good test suites at all.
What? I do understand that a CRUD app with little to no logic do not focus on test.
But any kind of engine.. i can not understand that it's not a priority? In general I'm not a big fan of unit test on simple websites, they do not give any real value compared to effort
But I remember working on a complex codename. It was extremely important to have close to 100% unit test in the core part. Saved me a lot.
Mostly, because a lot of game engines are ancient relics, tracing their lineage all the way back to Quake 1.
The development practices are not exactly up to date, and game development is in no hurry to change. It doesn't help that software development wages there are not at all competitive - game development selects for passion, not skill. People who want to build robust modern codebases and people who want to build AAA games are different people. So there aren't many game devs who want to push for better test coverage.
But it's also because game engines are dealing with many, many things that are hard to test for.
You know how messy it is to test a website for "does this layout look right" or "can you navigate from A to B"? Now multiply that by complex 3D geometry. A lot of what game engines do is dealing with complex 3D geometry, where the primary verification is "does it look right" and "does this interaction feel right". Which is why game development traditionally has wide human QA, and slim unit testing.
Only now do we have software that can sort of, semi-reliably, automate testing for "does it look right".
A game engine has a vast space of possible outputs, all of which will be considered good enough.
Its primary output is pixels and sound. Those are hard to test in a reasonable way. Screenshot testing is useless in a codebase where most of the changes are about making the pixels prettier.
> In general I'm not a big fan of unit test on simple websites, they do not give any real value compared to effort
And then your site gets more traction, features are added, things are refactored.
And now you're looking at what used to be a simple site, still with no tests.
It's a habit, that pays off long term. You don't do it for yourself, you do it for who changes the code next. Might be you, or not. Even when you do it yourself, you can't hold all the requirements in you brain, you write those up in tests
I agree - maybe some modern game engines have unit tests for stuff like their physics engine and their "standard library" code (optimised data structures, maths utilities, string utilities etc) but as others have said, testing sound and vision is hard, and something that hasn't been mentioned is all the different flags in a game engine - testing even a sensible subset of all the different sound and rendering variables would be a huge undertaking.
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.
Box3D just showcased some stuff including deterministic replays. If you wanted to port that, you could probably import the replay and make sure it plays back the same way in your new language. I think it captures the inputs and forces applied, not the pixels.
I suppose rendering is a component of a game engine too though, not just physics. I don't know how to do that reliably. Even if you captured pixels, it'd be annoying. If you've ever tried doing screenshot based diffing on web you will know that slight changes in aliasing in Chrome bugger everything up. Things that should be equivalent randomly aren't but not in a way that any human would care.
UE 5 doesn’t come with a scripting language even though there is blueprints which a node editor easy enough to be used by non dev. Studios like embark (The Finals, ARC Raiders) have been successful integrated AngelScript in UE 5 and use it in these games. UE 6 will see the appearance of Verse: the scripting language used for Fortnite (and the end of blueprint at some point). At first I was sad to see yet another language but it is worth looking at the doc to see why and how it makes a lot of sense.
> 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).
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.
> 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.
I may have been a little overly specific, since there are other issues besides cycles that also block splitting crates apart, but from what I’ve seen it’s very common for modules within a crate to have cyclic dependencies and therefore not be easily factorable into separate crates.
The industry accepted way of handling circular dependencies is to not have them and heavily lint against them in languages which permit them in compilation or runtime.
You’re thinking at the wrong scale. Rust allows circular dependencies just fine, within modules in a crate. And it’s extremely common for modules within a crate to have at least some circular dependencies - type X has some method (trait impl of inherent impl) that mentions type Y, and type Y has some method that mentions type X. In fact, I would be surprised if you could name me a single medium-size-or-larger popular crate that doesn’t have at least one cyclic reference between modules! Though, sometimes those cycles are not essential and could be avoided by splitting up modules. But sometimes they are. Either way, in C or C++ those modules would probably be their own compilation units.
That said, you also run into related parallelism blockers without cycles. For example, the orphan rules force most trait impls for a type to be in the same crate as the type definition. Also, a module which has no source-level cycles will often have cycles after monomorphization. In this case, Rust doesn’t prevent you from splitting the code into crates like it does with source-level cycles, but you do lose most of the actual codegen parallelization unless you can switch from generics to trait objects.
It's not “very slow”, that's a tired meme. It's slower than it could/should, but complaining about rustc being “very slow” is a clear misrepresentation, especially when everybody seems to have been fine with tsc's historical performance for instance. It could be nice if it was faster indeed, but people claiming it's “very slow” are just showing they never worked with it.
> The best way to speed it up appears to be organizing a codebase in many crates. This is not preferable ergonomics to many.
In this context (where you don't plan on publishing you stuff on crates.io) a “crate” are just a directory at the root of your repo, the ergonomic impact is literally zero.
I am using Rust since 2016 productively... before I dabbled with it.
Rust is not compiling any slower than a comparable C++ codebase for me.
It is compiling much slower than a managed language like Kotlin, C# etc. though. Which is an unfair comparison anyway.
The problem with e.g. gamedev is the iteration cycles. It's very creative work and not so much your average engineering job (apart form game engine dev).
But again, that's an unfair comparison, because even in Unity and many if not most other game engines, there is a scripting language that is used for most of the game logic, that doesn't need hyper performance...
Still, when compared to such languages, Rust indeed does compile slowly AND one has to say: Rust is selling itself not only as a safe, blazingly fast systems programming language these days, but it also is used for its type system etc. and then, when you come from a managed language, compile times really suck.
(Although debug builds are better, they are not an option for game dev for example, because the binary is just too slow then... 200fps vs. 20 :X)
Why do you think it is not slow? As far as I know the only language that compiles slower is C++, and even then the compilation speeds between c++ and rust seem to be comparable. I believe c, Fortran, zig, C#, Java and golang are all faster compiling languages. That makes rust pretty slow in my book. I get that it doesn’t bother everyone, but that doesn’t change the facts.
The average cargo check for the projects I've worked on, usually finish in less than 1 second, with `cargo build` completing in a single digit second (often below 2s), it's not slow by any means.
> I believe c, Fortran, zig, C#, Java and golang are all faster compiling languages.
Sure, but the difference between type checking is 10ms and type checking in 500ms is barely noticeable for a human being anyway, despite the x50 difference.
> That makes rust pretty slow in my book.
“Slow” is a perceptual thing. It doesn't matter if it's slower in absolute benchmark performance. If it doesn't slow you down in your work it's not “slow”.
> As far as I know the only language that compiles slower is C++
Typescript's compiler is much slower than Rust's, but it's plenty fast enough for most people and you almost never see complains about it because it mostly doesn't matter outside of pissing contests.
Typescript's compiler is much slower than Rust's, but it's plenty fast enough for most people and you almost never see complains about it because it mostly doesn't matter
But you have to compile Rust code to run it. You can run TypeScript code without type-checking it. That’s a massive difference in the development workflow.
The new TSC, supposedly 10x faster, will be very pleasant to have but not as much of a game-changer as you might expect. A 10x faster Rust compiler would be incredible.
> But you have to compile Rust code to run it. You can run TypeScript code without type-checking it. That’s a massive difference in the development workflow.
And yet I'm waiting for TSC every day while almost never thinking about rustc…
> The new TSC, supposedly 10x faster, will be very pleasant to have but not as much of a game-changer as you might expect.
It will be very nice, but I don't expect it to be a game changer, tsc isn't fast but it's fast enough to get the work done, the annoyance is there but it's objectively minimal. Anything else is pointless internet language war.
> A 10x faster Rust compiler would be incredible.
For development? Not really, not for me at least. Against the endless rants about rustc's performance on HN, absolutely.
"Compiling" is vague here; for TS I think you need to distinguish bundling from type-checking.
If you're talking about bundling the entire app, 120 seconds down to 10 seconds is a great saving, but other bundlers can do it much faster already. Most people don't bother using TSC to bundle their code. I can understand why Microsoft might insist on using it, but it's not typical.
For type-checking the entire app, I would see that as akin to running all the unit tests. 120 -> 10 seconds is excellent, but not something that should be a constant bottleneck in your development workflow.
I can definitely see that 10x improvement being crucial on large teams (and/or LLM swarms) where the speed of the CI queue becomes a bottleneck.
Exactly: tsc was “slow enough to be painful” in the context of the 2.5Mloc codebase of VScode.
But it's not too slow for most people.
Likewise, Rust may be slow enough to be painful for some big projects that need to often rebuild from-scratch in release mode, but that niche is definitely much smaller than the size of the “rust compiles too slowly” crowd on HN.
I gave Rust classes in university a few years back, and literally none of my students complained about slow build times. At this point it's much more of an internet meme than an actual pain point for most devs.
Most people complaining about Rust being slow have never worked on anything close to a production app written in Rust.
By the way, for most apps, rhe difference from an app we'd write in class is not as nearly as big as you'd expect: most of the code lies within dependencies anyway, and you need roughly the same amount of them in both cases.
Of course there are exceptions, apps that are tens of millions of LoCs exist, but it's not the majority.
(And they tend to be naturally split in multiple crates, which is the default workaround if a rust project takes too much time to compile).
Speaking as someone who has also given courses at university teaching a programming language (Swift,) the students also do not know how fast computers are and that when their brand new super-computer lags and hitches for full seconds while coding it's pretty much "working as expected" to them. I haven't written Rust in a few years, but I remember it being remarkably similar to Swift both in API design ergonomics and compiler quality. I am open to this having changed, and I can appreciate @stymaar's frustration if it has done so drastically.
Compiling my C code with gcc happens in a single eye blink.
Changing the format to .cpp and compiling with g++ takes 5 eye blinks.
I've never used rust and I can't imagine blinking more than 6 times while waiting for my code to compile.
Most people use esbuild or swc or oxc instead of the typescript compiler directly specifically because of how slow tsc is.
In fact tsc was slow enough that it was rewritten into a different language for version 7, with the performance of the compiled output as the primary motivation.
Actually it is possible to make C++ compile faster than Rust, because the ecosystem is more friendly towards binary libraries, then besides incremental compilation, you can also get incremental linking.
Additionally there are ways to have interactive code reloading, e.g. Visual Studio and Live++.
Or even a proper REPL, ROOT, CINT, Xeus.
Naturally all things that Rust could also have, only it hasn't been the focus and there are several decades to catch up.
It depends on what you're comparing it to. It is indeed very slow when compared to a C compiler, or a zig compiler, or even a Java compiler. C++ can be comparable, or slower, or faster, depending on the C++ features used.
Sure, maybe rustc's performance compares favorably to how tsc used to be, but that's not the benchmark most Rust developers (such as myself, for more than 10 years now) care about.
> a “crate” are just a directory at the root of your repo, the ergonomic impact is literally zero.
Nonsense. That's another Cargo.toml to maintain, and another place you might need to add/remove dependencies, and you have to manage the dependency tree among your sub-crates. The ergonomic impact is absolutely not literally zero, and I'd even say it's enough to be annoying.
> In this context (where you don't plan on publishing you stuff on crates.io) a “crate” are just a directory at the root of your repo, the ergonomic impact is literally zero.
Is not true, you can't have circular out of crate dependencies. This often means you now need a third crate that's a trait crate, but then you can't implement external traits on external types, so you need bridge crates, and so on.
Rust's limitation of performance requiring lots of crates indeed has real impacts on projects beyond simple hello worlds or trivial cli apps.
Considering it to be a zero impact issue is rather reductive, even in the context of the language's design principles itself.
Rust for all it's good sides has had a lack of interest from core team and energy to drive real valuable changes beyond the nightly blockers into stable, or maybe they are working real hard and the boulders are so hard to move that we can't see any change looking outside in.
Is it justified after the gargantuan effort that was merging Async and GATs? Yes.
But acknowledging the problem doesn't help us solve it.
This is to say, Rust is an amazing labour of love project that seems rather stuck in time due to lack of investment/time/effort or all of the above, I am not sure, but it's moving slower than I would like, at solving the problems Rust developers face everyday.
And yes Rust compiler is slow (very slow is arguable, compared to modern C++ it isn't that bad, but compared to say Go without cgo, its horrid), Cargo is just bad, without proper hermetic builds and stuff, even when I setup sccache for our team and our cache hit rate remained below 20% and most of it was just C++ deps hitting the cache.
Just to be clear Zig builds are quite slow too, especially on windows where debug builds also use llvm.
TBH Zig debug builds on Linux also don't really feel that fast, C still compiles faster for me by a considerable margin.
Either way as someone doing Rust everyday for last 8+ years, 5+ in small/large teams, I have lots of complaints and I am sad, it has been over years of me complaining without nearly enough progress, they have a survey declare ambitions, and then well... things just don't move much.. not nearly as much as I would have expected.
Honestly given I have been a rust dev for over half a decade now, I should instead of commenting here probably be figuring out if I can contribute to Rust to help things along (faster?).
But most meetings and discussions happen at very EU/US centric times, and number of non US/European core contributors in Rust is also rather small(I don't know of one but I hope there are a few) so as someone not in those circles, I don't have the energy to figure out my way in, with my day job.
Tldr; Is Rust the language for the job here, likely. But the question should be why couldn't have been the language Bun was written from the very start. Why does Zig or C++ or C seem so much more productive.
Sorry for ranting about this but this felt a little relevant since you claimed people complaining, are likely people who have never worked with Rust.
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).
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.
It was very slow. It's gotten a lot faster over time (over 2x faster). It's still not exactly fast, but it's definitely faster than C++. Although C++'s slow compile times are often complained about they were never really enough to stop most people using it, including for games.
> a garbage collector eliminates a large amount of defects (including the ones stated in the article) without any added friction
I'd be careful about that "without any added friction". Rust's lifetime/borrowing system tends to lead to less buggy code because it encourages structuring code in a less spaghetti way. GC does eliminate memory errors but you also lose that non-spaghetti code structure.
> You are seldom compiling the world from scratch.
True in Rust too though - you're normally doing incremental compiles. And even though you're compiling the world, it's still on par with C++. For example I just tried compiling a hello world Bevy project, which has 462 crate dependencies - pretty big. It took 2m20. Totally reasonable to build an entire game engine and all it's dependencies.
I wish they had reported the compile time of Bun before/after the Rust port - that would have been very interesting.
Ryzen 9 3950X (16 core). I think it was top of the line 5 or 6 years ago but it only cost me about £300 second hand for the whole PC (with 128 GB RAM - before the RAMpocalypse!) Definitely not a crazy machine.
> I started using C++ on MS-DOS, on a 20 MHz 386SX PC with 2MB RAM and 20 MB HDD
Yeah, I mean early C++ was quite a lot simpler than modern C++23! Of course it's going to compile way faster. You're not compiling UE 5 on that machine! Compilers didn't have so many slow optimisations back then either.
Yes, but no one needs to use C++23 to the full extent to stress test the compiler in -O3, or go crazy with compile time execution.
While I could comfortably still develop C++ in a Asus 1215B netbook with 8 GB and SSD, thanks to all the native libraries I could install, and make use via pkgconfig, the same could not be said to play around with Rust on the same netbook.
This matters, because not everyone can afford top of the line desktops, especially in 2nd and 3rd level countries, which then plays a role in language adoption.
Some even make do with what they can run on tablets.
I don't think I really agree with that. You can make do with less powerful machines in Rust too. Until this year I was using a 12 year old quad core machine that was only a bit faster than a RPi 5.
I think the biggest issue is actually disk space. C++ isn't exactly efficient with disk space but Rust is on another level. You're going to run out of disk space on that netbook it you have any more than like 2 Rust projects built.
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.
Well for c++ memory safety and sharp abstractions and even worse compile times than Rust. I’m not aware of hot reload really being done in c++ at any scale but I’m not a game dev so I’m open to learning.
C# AFAIK holds a minor place in gamedev and also has slow compile times maybe? I assume it has better support for hot reload times. But generally the performance profile isn’t there for the most demanding games even if the DX is.
Visual Studio limitations around hot reload are quite unrealistic for any serious codebase and only work on Windows with Visual Studio when you started it under a debugger.
Rust’s hot reload is cross platform if I recall correctly and is always available until you disable it from the build (eg debug on, release off). It also has a better story for working around the limitations that Visual Studio just throws up on.
C++ hot reload is not a common experience in the ecosystem.
Really shouldn't be a dealbreaker when 95% of your users will be using Windows (to play games), so your most tested platform should be Windows.
> when you started it under a debugger
Hot reload isn't a replacement for scripting IMO. It will never be as good. Even hot reload in Rust would have more limitations than an actual scripting language.
Sure, that doesn't take away from the experience of Rust being better than C++ even if you probably still want a scripting language too.
In total Microsoft only holds ~12% of the total video game market share across PC and console in terms of owning the platform (i.e. Xbox + Windows). I think you're overestimating how many game developers get to use reverse debugging for gaming. In practice given the limitations for Visual Studio's implementation, I highly suspect that number is very rarely used anyway.
> Beside that, for many problems, a garbage collector eliminates a large amount of defects (including the ones stated in the article)
Languages with garbage collection are generally considered "memory safe". GP was talking about choosing a language that requires manual memory management, but doesn't have something like rust's lifetimes to catch things like use-after-free.
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.
Agree 100%. Almost everything I have written with AI is in Go, and strong typing is really really nice (as is go vet and golangci-lint to keep the generated code in line).
I imagine writing plain js or python with it would be much much riskier.
Going from Rust to C++ seems a strange choice, since you get most of the same problems just without memory safety. Zig, Odin, C3 or even plain old C though? At least those languages have things to offer that neither Rust nor C++ provide (and if it's just compilation speed).
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.
> The first language I could "just write" in was C. I had internalised the language and its standard lib and didn't need the internet to work with it.
I bet $4.20 you didn’t write C. You wrote something C-like which the compiler didn’t reject because the C standard has a gigantic surface of ‘undefined behavior’ which means once your program does one thing out of spec it isn’t C anymore silently.
> 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.
Rust-the-language may be medium-sized. Rust-the-stdlib though?
The Rust stdlib has a lot of essential low-level types needed for adding a 'semantic layer' on top of the language so that the language user can exactly 'express intent' (types that arguably should be language features instead). Just look at all those detailed methods needed to make RefCell work, and what does 'into_inner' or 'undo_leak' even mean?
E.g. what's a single concept in C (e.g. "the pointer") easily has a dozen specialized equivalents in Rust, just because Rust needs the additional information to do its memory safety magic correctly.
The entirety of Rust and its stdlib has a huge 'semantic surface' compared to most other languages (even C++), and I think this difference in the semantic surface size to other languages is exactly the one thing that either attracts or repels people to/from Rust ;)
> what's a single concept in C (e.g. "the pointer") easily has a dozen specialized equivalents in Rust
That "the pointer" is a single concept in C is the root cause of absurd numbers of bugs over the history of C.
The questions of how long the memory a pointer points to lives, what threads it is safe to access from, and how it is allocated and destroyed all still exist in C. Those answers are just implicit rather than explicit like they are in Rust. It's not like Python/etc where you don't have to worry about these things.
In general I agree, but this topic is IMHO exactly what separates the Rust lovers from the Rust haters ;) E.g. how strong is too strong when it comes to type systems. Rust afficionados generally seem to tend towards 'the stronger the better', and accepting the downside of a fairly rigid code base.
I prefer a middle ground between strong and weak typing (but yeah, C is arguably too weakly typed, but the exact sweet spot is different for every programmer).
A reasonably smart C compiler that has visibility on all code in a project could theoretically infer a lot of the same semantic details that must be manually provided in Rust by looking at how the pointer is used in the wider codebase (basically what static analyzers are doing by reconstructing control flows). Of course such an extensive analysis would result in even worse compile times than Rust ;)
Of all the things I expected to read today on HN, "I chose a programming language that appeals to my political leanings" was certainly not one of them.
With the use of quotes there, you've put those words in my mouth. I didn't say that.
What I am trying to express with the statement you refer to is that zig appeals to me on an aesthetic level. It suits my tastes.
I mentioned liberty because I appreciate that zig allows me to have complete control of memory allocations, and gives me quite a deal of control over the metal. I like this and I like that I don't have to appease a borrow checker. Zig's compiler and type system is strict enough to guide me to correctness, but the experience, broadly, is not so onerous that programming becomes tedious and frustrating.
These qualities, I suspect, resonate with my individualistic tendencies.
With respect, it's difficult to interpret "libertarian sensiblities" as something else than "political leanings". Now "liberal" is a much more general -- I wouldn't necessarily call that political -- but what you said had a strong political connotation, hence my comment.
Your explanation lands otherwise. I can't relate to "I don't have to appease a borrow checker" though. That reads like a deliberately uncharitable read of what Rust's compiler is doing. That being said, it's definitely not for everyone.
I tried Zig. Loved it. But then after a few weekends I said to myself: "Wait a bit. I've been down this path before with C and C++. I know exactly where it ends." -- and bailed.
To me these days low-level programming is basically: either go all the way, or don't go at all. Sadly Rust is not like, going really all the way, but it's IMO the closest we got. And before somebody starts enumerating obscure languages that barely have a community: I include multi-axial evaluation here i.e. PL features, stdlib, ecosystem, richness of education (Rust has _a lot_ of good books and courses), and others I am surely forgetting at the moment.
Zig is great. But I'll not take marginal improvements anymore. Not in my personal life and not in my work. I'll get big ones, or not get them.
Since we are explaining philosophies, now without political undertones: that's mine.
It depends just how fast you need it. C++ is much easier to get to zero abstraction code.
In Rust you are constantly fighting the stdlib and other libraries, and you have to litter your hot code with unsafe blocks to get it to stop adding a branch to nearly every object access, be it for bounds checks or over/underflow checks.
C++ does a much better job at giving you a zero abstraction API, and you can always drop down to raw pointers if you want, without(!!!!) unsafe blocks and weird tricks. Of course it's unsafe in C++ but the friction to writing a branchless hot loop is muuuuch smaller.
When profiling and optimizing Rust code, I very often find myself poring over the generated code, making small changes, reading api docs, and trying again, much more than in C++. Lots of unsafe Rust APIs are not even nearly good enough, even with most checks turned off you will find branches that just branch to panic!(), which is, you guessed it, still more code and a branch than the code would suggest.
I get why people think that most systems languages are the same "speed", but they really are not if you are hitting limits of the hardware in your hot loops.
> How is not having to mark your unsafe code as unsafe a good thing?
The problem with unsafe code in Rust is that IIRC nobody actually figured out yet the "rules" of unsafe i.e. which invariants you can stretch and which can cause UB. My (not super up to date) understanding is that this is an active area of research and progress is being made and also that in practice there are many well understood usages.
In short unsafe rust is somewhat worse than C++ as the boundaries of UB are less well understood/defined
I don’t know what you’re referring to. Unsafe seems pretty well defined for 99% of use cases. Unsafe blocks allow you to dereference raw pointers and call unsafe functions. Thats about it. Remarkably, even in codebases which need a lot of unsafe (eg the kernel), almost all code is safe code.
If you have a hot loop where it matters, you can put an assert outside the loop which lets llvm remove the bounds checks. Or use unsafe { get_unchecked() } to remove the bounds check entirely.
Exactly, yes. I know it's possible, of course it's possible, its just not trivial like it is in C++.
Most developers I have met don't know how to use a profiler, so not sure any of this discussion matters at all anyway, but I feel like it's important to note when the default in Rust is safe, whereas the default in C++ is fast (and more or less unsafe)
There are so many situations where something is guaranteed to be safe but there is no way to express that in the Rust typesystem, so the only thing you can do is to wrap everything in Arcs and Mutexes, which introduces allocations, pointerchasing and locks
It depends a lot on the coding style. The sort of Rust code that's heavy on Rc, Arc, Box, RefCell etc... (e.g. the typical band-aids to work around borrow checker restrictions) will be slower than typical C++ code (it's also possible to kill performance in C++ of course, just use std::shared_ptr for everything). E.g. I'd wager that performant Rust code is trickier to write than performant C++ code because you'll have to design your entire Rust codebase around borrow checker restrictions, while C++ lets you 'cheat' without having to fall back to helper types that incur runtime overhead.
It's not though. It's fast enough for many applications but if you need to write a hypervisor then suddenly bounds checks and atomic pointers become significant. Not to mention that rust dramatically reduces your ability to control where memory is allocated.
I write in rust and c++, rust isn't as fast. Rust is easier to work with and, compared to the Java crap it's replacing at my work, it's a lot better but it's certainly not zero cost abstractions the way c++ can be, nor is it great for data oriented design because you're hoping the compiler will do the right thing, consistently.
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…
Sometimes we have no option, given the industry standards that expect C or C++.
Khronos, Open Group, NVidia, Microsoft, Sony, Nintendo... aren't going to change their APIs and SDKs, just because of social media discussions on the merits of C, C++ vs other safer alternatives.
I agree we should minimise their use, however not everyone accepts a dual language approach, nor there are alternatives in such domains, even if they technically exist, you still need to overcome the human and political factors.
Hence why it is so relevant to fix C and C++ security flaws to some extent as well.
Obviously my comment of irresponsibility was “given that there is a choice.”
Though that’s one nice thing about Swift: it has a very good interop’ with C now, and a “starting to get pretty good” interop’ with C++. So that can help, sometimes. (Obviously, I reiterate, I understand there are situations where the choice is just not possible, and enhancing C and C++ is indeed a good thing.)
The nice thing about Swift, or Java/Kotlin on Android, is the platform owner attitude, either adopt it, or go elsewhere, that is the only way safety improvements are pushed into mainstream.
> I can understand when you need the absolute best performance and you decide to drop to down to C++
Could you help me understand with an example or two? My understanding is that well written Rust and C++ are often identical in performance thanks to relying on the same compiler backend (both clang and rustc use LLVM).
Even, possibly, the other way around in some cases. A seemingly identical program may (and it does occur) compile to a faster machine code in rust than in C++ due to extra markers (eg alignment) that rust compiler is able to provide to llvm.
This comment makes no sense. For one, "you need the absolute best performance and you decide to drop to down to C++", no, C++ and Rust are virtually equivalent in that they pretty much expose the underlying machine fully; if anything Rust makes it easier to write idiomatic performant code.
For two, there are plenty of reasons to use C++ unfortunately: compatibility with existing code based and availability of developers to name two.
People get attached to things they've been using for decades. Also most of the world is still written in c/c++ so any critical mass has quite a lot to go up against.
Rust isn't perfect but it solves a lot of the pitfalls of C++ (not just UB, package management, horrible cmake files, linker errors etc.)
Rust is C++ like language, with more safety. It makes no sense to say that to get performance one can drop down to C++. As far as I am aware, you can get as fast as C with Rust. Of course, that might mean to compromise on something, some bound checks, some code ergonomics, or something else. You can write ASM in Rust, so it really gets as low level as it gets. And what I find amazing is that, similarity to C++, you can get both low level and high level code in the same language. And this is intrinsic in the language complexity: if you take a simpler language with a less powerful type system (C-class languages), you lose this ability.
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.
I tried to use Rust for a tiny microcontroller (GD32VF103, 128KB flash).
First of all, I was amazed by how much I could do with Rust (safe Rust, even), and how well it was interfacing with my handwritten RISC-V assembly. I will definitely use Rust again for the next such project.
But, every time my functions would get over a certain size, suddenly some optimizations stopped working, and Rust was trying to put the whole panic/fmt machinery into the thing, going above my linker's flash size limit. It was insanely frustrating, since there was no rhyme or reason to it. Simply adding another branch to a match made it do that. Or another if statement that was exactly the same as the 4 before it.
I don't disagree that I think that the Rust project could do more to make this kind of development easier, and it is true that it doesn't come for free. That doesn't change the point that if you want to, you can do it, it is not a fundamental language limitation.
It is a fundamental language limitation, unless you want to claim that the core library (or rather what's left when using no_std) is not part of the language.
The problem comes from a combination of three things:
1. Rust's standard library (including core) likes to panic a lot, e.g. for code that is genuinely unreachable (and this is fine)
2. Rust/LLVM cannot always optimize unreachable code away (and this is also fine)
3. The presence of at least one panic causes Rust to also include the error string format machinery, which is HUGE (and this is completely unavoidable)
Because of #2, there is no way to prevent this for larger code. I can define my own panic handler, but I can't prevent panic!() calls from inside core from constructing the format message using core::fmt before they call my panic handler.
And so any non-trivial code sometimes just randomly becomes 3x larger, and I can no longer fit it on my MCU, despite never actually printing or caring about any panic messages.
I think we just disagree about what "fundamental" means. If you don't use panics, you don't get the machinery. This means it's not fundamental.
What you're talking about is the ease of which you can not include the panic machinery. I agree that it is not always easy to keep out, and that I would like if it were to be made easier.
But people are doing real, commercial projects on MCUs your size and smaller.
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.
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
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
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
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...
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.
"In economics, the Jevons paradox is said to occur when technological improvements that increase the efficiency of a resource's use lead to a rise, rather than a fall, in total consumption of that resource. Greater efficiency reduces the amount of the resource needed per application, lowering its effective cost; if demand is sufficiently price elastic, this induces demand, frequently resulting in a net increase of total resource consumption."
jevon's paradox just says people will consume more software as software gets cheaper, which is likely true, not that there will be more high paid jobs for programmers.
as programmers are not the resource, the program is the resource, programmers were the means of production of said resource.
stated differently: in a world where you dont need programmers to make programs, there is infinity of programs, and no jobs for programmers.
You are assuming an infinite productivity boost, i.e. that no programmers at all are needed to make programs.
A more realistic scenario is that programmers are still needed in the foreseeable future (for some definition a what a programmer is, even if it's "understands software enough to be able to write good prompts and judge the results"). So the question is how the productivity boost compares to the increase in the amount of software being made.
yes, I assume we will have the 'replicator' from Star Trek, and programs will just appear as you want them.
experiencing the gpt3->4o->sonnet4->opus4.6->fable trajectory I am fairly confident what we call programmer today will not exist, in the same time regular people will finally be able to tell computers what to do and this will unlock the next stage of complexity in manufacturing/material science/medicine and so on.
of course I am likely wrong, people say: its never as good or as bad as you think.
While there are a lot of resources being poured into improving and integrating tooling and use cases and increasing model sizes, the leap between the models you notes are not as much as you think it is. It's the same tech that's scalable to a certain limit of diminishing return. It's a recurrent pattern in technology.
> yes, I assume we will have the 'replicator' from Star Trek, and programs will just appear as you want them.
Yes, perhaps one day. Probably no other "job" as they are today will have the same shape and form. Cancer will be cured and fission will be solved. We may even crack teleporting. Let's hope these all happen and the outcome is not detrimental the livelihood of humans.
Sorry, but I don't think you understand how many different skills are involved in building software that large companies can actually rely on.
Writing code is only one part of the job. I use Claude Code every day and I love it. It has made me much more productive. But I still have to guide it carefully, review every change, and fix the bugs and poor design decisions it introduces.
Personally, I'm looking forward to retirement. I expect there will be no shortage of consulting work helping companies clean up the AI-generated mess generated by inexperienced developers and overconfident middle manager with zero software development experience :)
It is possible because they hired the original author of Bun to do this.
It won't be possible to HIRE anyone doing this job confidently, they won't even know if they f*ked up.
I am not too worried anyway, one person with no context, with or without AI, can't do this job. Just like with all the AIs you have, giving you 10 millions, you still can't build a AAA game, it is that simple.
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
It's only 4% unsafe and most of it is single-line pointers that came from C++
> At the time of writing, about 4% of Bun's Rust code sits inside an unsafe block (~13,000 unsafe keywords across ~27,000 lines / ~780,000 lines), and 78% of those blocks are a single line — a pointer that came from C++, or one call into a C library.
I don't know much about Rust but I imagine this is safer than 100% 'unsafe' code in Zig or C++.
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.
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.
> No one would have entertained the idea of rewriting a project in Rust before this.
I largely agree with your comment, but is this sentence typo'd or something? "Rewrite it in Rust" happens so often that it's become a meme (and that was so before the rise of agentic coding).
Maybe you meant to say that nobody would have entertained the idea of rewriting this project in Rust?
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.
Exactly. AI opens up a massive development frontier of projects that were simply impossible before. It does differentiate though. In the old world most "software engineering" work had nothing to do with software engineering so being highly skilled, educated, and experienced in software engineering made very little difference in compensation, position, promotion, etc. "software engineer" isn't a real thing anyway. coding is a secretarial job. you have to move beyond the mindset that coding is doing something useful. it's not. it is a means to an end and now better means exist. if you want to be an engineer you have to think in terms of systems engineering and building systems that deliver defined externally testable capabilities. in a few more years the idea of reading and writing source code will seem as absurd as reading and writing asm seems today.
> 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.
Ha. You'll be surprised when you find out how much new problems were created in the code base precisely because the author's (not sure if it's still the right word here, they barely involved) lack of knowledge of Rust.
And no, since they don't know they don't know about it, there are no signs of fixes around these real issues. They had posted something about the unsafe usage, but lol most of the UBs are casually swept away (not even treated as unsoundness), if you actually look at the code and the summary.
Measurably yes. They claim that 128 problems from the zig version was fixed, so I grepped for two known categories of UBs and unsoundness unique to unsafe Rust and found 237.
Can't assume good faith in you at this point but I'll explain it.
- They've written two articles, one by claude doing the migration another by the human behind it, neither acknowledge these problems. Nor does the incorrect SAFETY comments in code.
- I only spent ten minutes and found two code patterns that are wrong with little exceptions. Also randomly checked a few samples and there was no exception. This basically means that failure patterns not explicitly picked and disallowed will repeat themselves over and over. Try imagine the more subtle ones hiding in this huge codebase.
- Trivial to find != Trivial to fix. 107 of the problems (one of the categories) are borrow issue and requires large refactoring (rearrange and rethink whole modules of code) to be removed completely.
So yes, huge regression by my standards. And I'm not questioning Rust the language. I'm questioning Claude, Jarred the person, their dev & marketing practice and the Bun project.
Btw these categories are separate from the (still unfixed) category of problems I mentioned 54 days ago in the comments before.
Our standards are different. I don't see any of that as a regression. You're pointing out potential problems that can be resolved, and specifically can be resolved because rust makes those problems grep'able.
That's not the correct understanding. These are specifically the ones that were not bugs in Zig. They are forbidden in Rust because of reference invariants that don't even exist in Zig, so correct code are made incorrect during the port. That's what I meant by new problems were created and unique to unsafe Rust in my previous comments, if that wasn't clear enough.
Again I'm not sure if you are intentionally ignoring the context. Please clarify that.
> They are forbidden in Rust because of reference invariants that don't even exist in Zig, so correct code are made incorrect during the port.
I'm not sure that this is true - who says that the same invariants weren't broken on the Zig side? (Aliased pointers are UB either way, for example). Also, "unsafe invariant broken" does not strictly mean that there's a reachable bug. It should be cleaned up though, obviously. But in theory, callers may never actually trigger a bad invariant in an unsafe block.
Regardless, even assuming that these are genuinely new bugs, it doesn't change my point. Going from ~X known bugs to ~2X potential, grep'able bugs, is a win to me. Sounds like it isn't to you. Great.
> Again I'm not sure if you are intentionally ignoring the context. Please clarify that.
I'm obviously not intentionally ignoring anything, if you think I am then you can stop responding.
There wasn't a reply button on your latest reply so I'm posting here instead. Also because I now have more time to clarify what's exactly wrong about the claims.
> who says that the same invariants weren't broken on the Zig side
There are no such invariants in Zig.
> "unsafe invariant broken" does not strictly mean that there's a reachable bug.
Broken invariant literally means you are reaching it. The word you are looking for is "unsoundness".
> callers may never actually trigger a bad invariant in an unsafe block.
There's a neat class of UBs called "immediate UB"s. They can ruin the code just by being compiled, instead of reached at runtime. And guess what? They have a lot of these.
> potential, grep'able bugs
We are indeed going in circles but I have to ask: you still don't understand that? Grep works for violated lints, unsafe blocks and all things explicitly exist in the code. Not for unsoundness in safe functions that can be called incorrectly and ruin everything, can't be reasoned about by any existing tools. They also have thousands of those. It's unfair to say the unsoundness is freshly introduced by the port, but Rust also doesn't help in this way where no unsafety is encapsulated and calling anything can be a wild ride.
Zig does have invariants. It doesn't have an aliasing invariant like rust though, but it does have its own invariants, naturally. Zig is a memory unsafe language.
> Broken invariant literally means you are reaching it. The word you are looking for is "unsoundness".
A reachable bug means one that can be triggered. Undefined behavior does not mean a bug can be triggered.
> There's a neat class of UBs called "immediate UB"s. They can ruin the code just by being compiled, instead of reached at runtime. And guess what? They have a lot of these.
Can be, yes.
> Not for unsoundness in safe functions that can be called incorrectly and ruin everything, can't be reasoned about by any existing tools
This is only possible if unsafe is used. `unsafe` is grep'able, hence all memory safety bugs are grep'able. That's the whole point of rust.
> `unsafe` is grep'able, hence all memory safety bugs are grep'able.
Wrong implicit premise: "all memory safety bugs resides in unsafe functions/blocks".
No. Even assuming everything is done idiomatically, memory safety bugs can still originate from unsafe blocks and all the safe functions in the same module. So we want the module containing unsafe to be small and closed. Otoh with this code base unsafe lives in every module.
Making them encapsulated is the whole point of Rust, in this code nothing is encapsulated so no, they missed the whole point of it.
Aaand it's not like you can just remove the unsafe blocks one by one trivially. It's as hard as rewriting the codebase from ground up without reference (unlike the current migration) as every referenced object in the call graph needs to be reordered. Well partly because the original code sucks I assume.
> Not these in particular. You are again ignoring the context.
What context? I just said afterwards that aliasing is not one of those cases.
> Undefined behavior are bugs by themselves. Let's check if you are holding any of the wrong assumptions:
Nope and your post wouldn't justify the statement. Not all UB leads to a reachable bug. The blog post doesn't say otherwise, and in fact it indicates exactly this (that UB can compile "correctly" one day and "incorrectly" the next). Check the errata on the post.
> Wrong implicit premise: "all memory safety bugs resides in unsafe functions/blocks".
No, I'm right other than l-unsound. Saying "but safe code that references unsafe code" doesn't change that.
> It's as hard as rewriting the codebase from ground up without reference
Not necessarily. At least multiple cases I've seen in the rewrite would be a matter of just moving `unsafe` from one spot to another and then placing the assertions at the caller.
This conversation is increasingly dumb. I've made my point repeatedly - moving to Rust means memory unsafety violations can be grepped for and that's not up for debate. You can say that that's not sufficient as a win for the project, I really am ambivalent.
That's untrue. It has already been maximally dumb since your first comment with the various logical fallacies you managed
to carry out in a single sentence. The only reason I'm still making my replies is that you are making so many false claims
that may mislead someone else.
Yes you are. Either that or you are too distracted to read or you wouldn't be repeating
> ~2X potential
at this point. That's what I've found in 10 minutes. And they are actual bugs that I've take extra time to (statistically) verify. Please worship me as the new machine god if you think I've found all the bugs with a glance.
And I'm not going to debunk each of your false claims, when you are doing that at the expense of appearing either dishonest or ignorant. I'm allergic to apologism.
Additionally I'd admit that I've intentionally avoided talking about the specifics of these problems, giving links to each of them or something. That's for a concrete reason - I can't bear it if Bun gets (even in the slightest bit) better because of my contribution. It would be one of the worst things I can do, morally.
> And they are actual bugs that I've take extra time to (statistically) verify.
I'm confused. You said that you've just grepped and found some undefined behavior. What do you mean that you've statistically verified them?
> And I'm not going to debunk each of your false claims, when you are doing that at the expense of appearing either dishonest or ignorant. I'm allergic to apologism.
My false claims? Like that pointer aliasing is undefined behavior in both languages? lol okay?
> Additionally I'd admit that I've intentionally avoided talking about the specifics of these problems, giving links to each of them or something. That's for a concrete reason - I can't bear it if Bun gets (even in the slightest bit) better because of my contribution. It would be one of the worst things I can do, morally.
I'm taking all of your claims at face value, I haven't said that you have to provide evidence of them. I'm not saying that your claims are false, I'm saying that I can grant them and still disagree with you.
I don't know what to tell you. Even if you said that those 2x bugs were 100% verified, I'd still say that this is a win because you can grep for these bugs now. That is obviously better to me.
Instead of "possible" undefined behaviors, potential bugs, the samples I've randomly picked are all actual undefined behaviors, real bugs. Hence statistically.
> pointer aliasing is undefined behavior in both languages
That included and also basically every other claim in that comment. I'd be happy to learn otherwise if you have concrete evidence.
[Edit: erased information that can help people find the bugs without prior knowledge]
> I haven't said that you have to provide evidence of them
Sure, but if I'm going to it would be a lot easier to convince everyone how bad it is (just like I did in private message groups). I can't take the risk that "everyone" also includes Jarred though.
> you can grep for these bugs now
You can grep for the greppable new bugs. I raised them as an argument because these issues are glaring. What about the ungreppable ones? More than half (again, randomly sampled) unsafe usage in the 10,413 unsafe blocks in current Bun looks iffy to me. I just haven't taken the time to verify them because many requires reasoning across the code base (see? the exact problem Rust ought to prevent). From a Rust point of view it's a huge failure.
All these while considering that the Bun agents (no people at this point I'm afraid) don't even know how to grep for the easy ones.
This is going in circles. I think my point has been made. You can grep for every memory safety violation in Rust, that is a win. Pointer aliasing is apparently not UB in Zig, that's cool, assuming that's what you are referring to - but I just can't stress enough how little this matters to my point.
- 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.
You are missing the big picture here
The AI literally was able to do a year's work of a top notch developer team in just 11 days (mainly because of a lot of human intervention, otherwise it would have been faster)
Why do you think its cant or wont be able to replace the lead developer and/or designer's 11 day job !
and btw, if it can write code, it can write tests and test suite
Ai has come a long way, 2 years ago, this task would be impossible ! 1 year ago, it would hit a dead-end in the first hours of the execution
This blog post is nothing short of an amazing and fascinating tale, yet in some aspect very very scary ...
No I'm not missing anything. The existing specifications and tests provide a huge validation surface to work against for this kind of migration - they're the foundational pieces of the control loop. Without those two things, this kind of rewrite would not be possible.
We have known for decades that the hard part in programming isn't programming, it's making sure you have the right target! Bad designs and bad specifications have caused more bugs and broken software than anything else, and the time taken to develop the testing and validation suites (that is - the javascript spec tests) this rewrite used must be considered part of the engineering effort.
> and btw, if it can write code, it can write tests and test suite
You must be very early in your career. Again, the hard part is not writing the test, it's knowing which tests to write.
> You are missing the big picture here The AI literally was able to do a year's work of a top notch developer team in just 11 days (mainly because of a lot of human intervention, otherwise it would have been faster) Why do you think its cant or wont be able to replace the lead developer and/or designer's 11 day job !
It would help if you actually engaged at all with any of the points they just made. They were good points!
Not only that. I think most of us, including the author wouldn't have thought this was actually feasible.
Not only is the time and dollar spent lower than a lot of people expected. We could now foresee a lot of these human interaction, mistakes, time and cost could be further reduced by a factor of 2, 5 or even 10+ in the not far future.
Also worth taking into account what is stated in the blog post is also acting as PR piece for Claude and LLM in general.
This project is very well suited for AI. It's not clear to me if AI is nearly as good or cheap when building things that are new, where it doesn't have an existing target to match and doesn't have an existing test suite to bounce off of and has the benefit of being lead by an actual human with a very intimate understanding of the codebase.
I am seeing the complete opposite. 200k senior engineers can now do large scale projects way beyond what they could do just a year ago. My company is now able to implement stuff that we used to only dream about. Having 200k senior engineers who master AI coding is a true super power.
> 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.
Sure, if you're wasting money in silicon valley. They could have hired in Europe and got three people for $300k, which is only double what they spent.
I think the time is the really significant factor, not the money. I bet if they had the option of paying $300k to have it done by humans rather than AI, but magically in a week instead of a year, they would have gone for that instead. $300k is nothing to Anthropic.
Opportunity cost is not a real cost. No money leaves your bank account. It is a decision making tool, and treating it as an actual financial cost is a misuse of the idea.
It’s literally the price of lost opportunities. It’s not understood to be a financial cost. It’s exactly what it says on the tin. Lost opportunities may not be a financial cost, but they’re certainly a cost.
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%.
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.
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.
I find it curious that people who take other's people product and rewrite in their favorite programming language still name their own creation the name of the original one.
Like, you have now created your own new database engine that happens to be compatible with Postgres. Wouldn't you take an absolute pride in giving it your own name? Why call it "Postgres rewrite in <programming language>"?
If this is still speaking about the Postgres rewrite in Rust, then naming it something like pgrust[1] makes sense for ease of discovery for anyone aware of these technologies.
> 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.
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.
I’ve been noticing that it will test hypotheses for evidence frequently. I really like that. With Opus I have to instruct it with a skill to build prototypes, but Fable will do it and do it really well by default. Really nice detail. I’m guessing it’s part of the system prompt, but the higher capability paired with this experimentation lean makes it far better at planning and verifying.
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.
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.
Funny you mention ORMs, I'm building a project with bun, and just using raw bun sqlite until I feel the app gets too complicated and I need it.
AIs are really damn good at SQL, I can just trust them with it, and it keeps the project much lighter.
A few years ago this would just sound stupid, but here we are.
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.
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.
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".
Unfortunately (and I say this because I hate this whole rust rewrite) no. There is no fixing a third-party garbage collector on top of the non-memory-managed language. Jarred explains in a post what would that Zig look like.
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.
On the other side of the scale, this codebase started in Zig from 5 years ago while the Zig of today is still very much pre-1.0 - still in the middle of things like finishing up moving to a self hosted compiler. Things like binary size, performance, or some of the oddities around drift in the language (like the custom macros vs now built-in language features) in this rewrite are not really as bad as they'd seem if this was a port from a more complete language.
That said, I think the parts around wanting to properly have memory safety guarantees rather than try hard & patch as issues are found is a more serious concern for Zig as those speak more to the design goals than the current implementation. "better safety than C while maintaining C compatibility" may not be a very compelling reason to chose Zig if other languages are able to do that portion better anyways, even ones without a GC.
I hope Zig won't do a hostile reply to this blog post. But some thoughts on Zig's future where a lot of these problems could be fixed or migrated by better tooling and compiler checking.
But a lot of people have been saying this for sometime, Rust and LLM is a great match. A lot of friction of the language were smoothed out by LLM assisted programming.
Zig was the right tool to start, Rust is the right tool to finish.
Making something possible and refining something until it is high security and reliability are different problems. Zig is great, but for a JS runtime, I just don't think that's the best long-term fit.
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.
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
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.
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.
It's a direct translation without changing the overall code structure or data structures. I do think this process deserves a distinct name from blind whole-of-project vibe coding.
Translation does seem to be a strength of LLMs, and as they said in the post, the code at the function-level all still feels familiar to the team. They've also already moved users to the codebase without anyone noticing; that's a better result than typical vibe coding.
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.
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.
There clearly aren't catastrophic bugs. The question is whether the artifact is maintainable over time, since clearly there's a massive amount of net new code that was not thoroughly reviewed. Give it a year or so and we'll know. I claim either way, it doesn't really matter to Anthropic--if it's a disaster they might be able to keep it limping along well enough by just throwing tons of tokens at it. The value in this is not the lasting software artifact, it's the marketing of the rewrite. If over time it turns out to be a great success, all the better!
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.
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...
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
There are different definitions of "maintainable". It seems the prevailing culture at Anthropic is to not touch code manually anymore. So for them "maintainable" means the LLM can fix it.
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.
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.
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.
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.
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.
I would be mad if the syntax was constantly changing but I want the internal implementation to be moving as fast as possible while retaining success. I think that rate is higher than what humans alone can do.
That's a monkey's paw desire because nowhere is Hyrum's law more true than programming languages. Alternatively you just end up with something like C++ where no one understands the whole thing.
> 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.
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.
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.
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).
Nonsense. Junior salaries are on the order of $50k in the UK. There's no healthcare to pay, but employer taxes and overheads might be around 30%, so you're talking way under $100k.
> 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.
> 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.
I did some more sizeable work with GLM 5.2 on Max reasoning (planning and implementing 8 features end to end) and it performed pretty well, but worse than Opus 4.8, with largely the same adversarial agent review loop.
The GLM Coding Plan seems to have lower token limits than the corresponding Anthropic Max subscriptions, but if you had to pay API rates for some LLM to do work somewhat reliably, it's a no brainer (unless you're swimming in money that you can give away and value your time more).
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?
$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].
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.
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.
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.
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.
Many of the large enterprises we work for did move software engineering work from HCOL locations in Europe or the US to India, often with disastrous results.
On Teams, channels related to AI are flooded with daily support requests from supposed engineers from India who clearly are not competent enough to set up GitHub Copilot or properly report issues they encounter during the setup.
And don't get me started on the shared libraries some teams located in India work on. If the library I need to use is full of obvious bugs where I wonder how any competent engineer could have shipped this to production, and then I see that the work has been moved to India, how am I supposed to feel about this?
It's very odd how quickly people fall back on emotional claims to attack this. Like we're engineers, if you can point at concrete problems with this rewrite I'd love to hear them. Obviously Jared is going to give the positive case, saying that he's doing that doesn't prove the rewrite is a bad idea. You need to point at objective problems, not your vague sense of unease. As it stands, by all available measures, this appears to have been a massive success, which is absolutely remarkable.
There were/are absolutely plenty of real problems with the resulting code pointed out. Running Miri trivially found soundness issues, `SAFETY` comments that demonstrate that the model in question fundamentally doesn't understand/simulate understanding how unsafe rust works [0], etc.
First, we're talking about a massive rewrite of complex software project which no one has fully reviewed and which the people most familiar with the code base (the bun maintainers) aren't even qualified to do so. As such, the issues people have found are mostly surface level.
But second, you're right, this is an easy thing to search for (especially with LLMs). And yet, the example I linked has been there since may, surviving multiple rounds of review. From this, we can draw a few conclusions: 1) claude (including apparently mythos/fable) fundamentally doesn't "understand" how unsafe rust works, and 2) no one on the bun team is aware that they need to tell it to fix this (if they're even aware that this isn't allowed in the first place).
The reason such trivial defects in a codebase are a red flag isn't so much those specific issues themselves, it's what they reveal about the authors. If you find a lot of obvious defects in some code, it's very likely that there are also many more subtle harder to detect issues as well.
I think that's an interesting point that the models wrote SAFETY comments that are so obviously not what SAFETY comments are for. A SAFETY comment can never be about callers, that's the whole point of `unsafe`.
Well the rewrite has newly introduced many immediate and critical safety (as in Rust sense) problems. It's clear and obvious if you read the code knowing the basic rules of unsafe Rust. And don't be surprised if it doesn't appear as obvious to you or Jarred or Claude, because not knowing they don't know is the exact reason why they failed at it.
And for the emotional aspect. I'm working as an R&D engineer and one of my recently assigned experiments is to evaluate replacing workers with LLMs, quality software with slops. Every bit of exaggeration they make is making my coworkers lose jobs and I'll be no exception. The entirety of me consists of reasons going against this kind of marketing compaign.
I don't think "better" really had to be proved. The same but aligned with your org strategy is perfectly acceptable given these sorts of technology choices are often driven by exogenous and wooly factors like licensing, your confidence in the future direction of the technology, or the ability to hire staff (or the ability for LLMs to work with the technology!)
Technology does not exist in a vacuum, nor does anything that is engineered. It's not this abstract stuff detached from the world.
PEOPLE make stuff, people use stuff, and people are ultimately the ones who are going to pick and choose which stuff gets made, used, adapted, enhanced, and carried into the future.
AI is an inherently anti-social, anti-human technology, and this rewrite is the perfect example of that.
Assessed from the perspective of "technology in a vacuum", of course. it's a success. He did the thing that transformed the thing from one kind of stuff to another kind of stuff. It still does all the things it did before, and in many cases with better stats than it did before.
Assessed from the human angle, and especially the angle of Bun as a community, I would bet money that this rewrite -- executed by nobody for nobody, built and maintained by machines, maintainable only by machines -- has killed the entire project.
Maintainable only by machines, because anybody with any knowledge, experience, or investment into Bun as a platform, or who contributed patches themselves, or whoever had a question about how it works and went "Hmm, I'm gonna go into the codebase and take a look at how that happens", they all got slapped in the face and summarily kicked out of the tent with the rewrite.
> AI is an inherently anti-social, anti-human technology, and this rewrite is the perfect example of that.
Not really. LLMs are a tool, and they do possess some interesting properties, but they are, in essence, a very surprising auto-complete.
No, what sucks is the AI companies marketing them as if they are The Holy Grail. And people are assuming that somehow LLM -> AGI -> ASI, even though there isn't really a causal link to be had, and acting like it's The Singularity.
I don't blame autocomplete for fucking up RAM, labor and god knows what else. I blame the idiots (at OpenAI and Anthropic) buying all RAM stocks and pretending this shit is any way good for anyone.
If you think like this - and you are most probably right IMO as well - then you should somehow share GP feelings, because LLMs are made by companies like OpenAI and Anthropic and Bun was bought by Anthropic and ported to Rust by Anthropic.
TBH in hindsight it seems that the Bun acquisition was also for the PR stunt they just did with the Rust porting.
I don't because I think the GP is blaming the tech, not the actual culprit - a bit like blaming the invention of fridges for people hiding the body. LLMs can be made and hosted independently of OpenAI and Anthropic.
> TBH in hindsight it seems that the Bun acquisition was also for the PR stunt they just did with the Rust porting.
The events went roughly like this:
- Anthropic used Bun. So they acquired it.
- Bun made some LLM derived patches for Zig. They were rejected due to Zig no-LLM stance.
- Bun couldn't get patches in, so they switched to Rust.
Was it a PR stunt, an attempt to pressure Zig maintainers into changing AI stance, or just doing the fastest thing possible? It's difficult to tell. I'm inclined to believe the last option.
As easy as it is to blame Bun for a PR stunt, it's also possible that you can't really associate with someone who rallies against your employer/owner.
To add more context around lifetime errors and TigerBeetle's particular style guide:
>Many projects opt to answer these kinds of questions through a style guide. TigerBeetle's TigerStyle is an example in Zig and Google's 31,000 word C++ style guide is another. The challenge with style guides is enforcement.
TigerStyle[1] is a bit more than just a style guide. The key rule for this discussion, uplifted straight from of NASA[2], is *static memory allocation*: all memory is allocated in the startup phase, and there's absolutely zero `alloc`s afterwrads . This plus crash only[3] design means that we never call `free`.
This rule is self-enforcing and compositional, in Zig. There's no global memory allocator, so the code after startup simply hasn't the API to allocate. You can't circumvent this by accident. Of course, if the programmer is byzantine, they can stuff allocator in the global, or just directly `mmap` and `unmap` pages of memory, but, at our scale, we don't have problems with that. This is a similar in kind (not degree) to Rust, where untrusted code generally can circumvent safety guarantees, even without literally spelling `unsafe`.
And, naturally, never `free`ing goes a long way towards solving many memory errors by construction. Empirically, they just haven't been a problem for TigerBeetle. It's hard to untangle contribution of static allocation in particular from everything else we are doing, but it would make sense for it to play a leading role.
(As a footnote, we aren't actually do static allocation to avoid memory errors, we use it as a linter to check that every quantity has a known _logical_ static limit, the main property we care about)
By all accounts, TigerBeetle has been a tremendous success, congratulations! My understanding is that it has a deliberately fixed scope, which makes me wonder: how applicable would TigerStyle be in more general-purpose applications? If the system needs to, say, ingest arbitrary JSON documents ranging from 100 bytes to 100 GB, how would TigerStyle fare?
What matklad said as a footnote deserves a little more attention!
A huge benefit is having to think and be explicit about the limits up front. To take your example of arbitrary sized JSON and flip it around: how would you do it normally?
Maybe, you'd allocate a buffer to hold your entire object when it comes in - but now you'll end up crashing when you get a large document that exceeds your available memory.
Maybe you can do things in a fixed amount of memory, using streaming or chunking - which would be pretty simple to turn to static allocation!
Static allocation forces understanding of those limits upfront.
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.
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
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?
Getting to an LTS release train of bun is probably a good idea, assuming they are still interested in external adoption rates. They shipped 1.0 a little under 3 years ago and the acquisition has had ~6 months to get settled. Looking at an LTS release would enable a lot of the more slower moving places to look at bun within being worried about getting caught up in the velocity.
I don't know it makes sense to try to make the an LTS version of where the Zig version left off, particularly if they know they are shipping a different solution & codebase to tackle the bulk of their security and memory bugs. Let this settle a few more months with the intent of releasing an LTS of it by the end of the year, if there really is demand for it. All of the benefits of having an LTS version like Java, Node, and .NET without needing to jump to a pre-port version of the codebase which was never targeted to be a good version to LTS in the first place.
A final Zig-based LTS would have made great sense if LTS releases had already been in the picture though.
I don’t follow how it would be in Anthropic’s interests to maintain an LTS version of Bun. It seems unlikely they’d use it, and it would cost them money (in the form of labor).
To my understanding, Java and .NET offer public LTSes because they’re financially buoyed by huge companies using those LTS versions, and Oracle and Microsoft are fundamentally selling that LTS support as a product. I have no idea why Node does, maybe it’s similar. But Bun’s position appears to be different than all three.
> - No LTS support for the Zig version regarding CVEs etc.
Every release would have tons of CVEs and would take so much effort. E.g. the example from blog with memory issues. Better just think that Zig version was not there what comes to security. Use at your own risk.
> Jarred basically keeps operating as if he was a lone hacker working on his personal project.
They have right to do it, however. It is expected, especially if company owns it.
Of course he has the right to do it, no one disputes that. The users and community also have the right to complain, or stop using and supporting Bun because they don't like his actions
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.
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.
1) My (and possibly other people's) last impression of this was when it was merged just based on all tests passing. In many projects, relying just on tests would definitely be reckless (not sure about coverage/quality of Bun tests).
I didn't follow much what where they doing later, maybe it is indeed good enough. For example, Claude Code using it and being fine is reassuring.
2) Making such a big decision that quickly and not (even having the time to) consulting community doesn't really inspire confidence.
3) You can be reckless even if everything ends up being perfect in the end.
Going 80mph in a city, you probably have like 80% chance of not crashing. And if you don't crash, you just had a much faster and more fun trip. Doesn't mean it wasn't reckless.
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.
> 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.
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.
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.
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.
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.
Without accusing anyone of anything, I do think that this coming from the head of Zig, who gets a lot of negative publicity from the Bun rewrite (unjustifiably, it's a wonderful language) makes it harder for me to take this without wondering if there's some animosity that's really the main complaint.
> Two, I actually don't have any personal criticisms of Jarred
The author says two things that really popped out to me that you could say are "professional" and not "personal" criticisms, but I think they're still rude and contrast this statement.
> Jarred was already writing slop well before he had access to LLMs
> The grapevine was large and healthy and full of juicy grapes, and all those grapes contained the juice of the same message: Jarred was a stinky manager. Poor communication, unrealistic expectations, low empathy, no experience
Now, both of these may be true. I don't have any evidence though, so I don't know how to take it.
All this to say, I'll take both of these posts without a ton of salt when it comes to the non-technical parts.
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?
> But my guess is that maybe it doesn’t have as robust a test suite?
Not sure about what's going on over there, but over the last year Claude Code has gotten way better, I sure hope that they're working on a good enough test suite to avoid a crapload of regressions (and pave way for more refactoring, should they need it).
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.
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.
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.
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.
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.
I mean, surely the main motivation for "use an LLM to rewrite a huge project in a new language" was excitement about the shiny new tech that made it possible.
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.
> 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.
>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.
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.
I'm not sure individual examples is the right way to go about this. A correlation isn't a guarantee for every instance and it's easy to concoct individual examples which tell any story you'd like them to.
To properly answer this you'd need to compare a large number of identical implementations written idiomatically in several languages and see if there is a correlation.
If I were to throw my 2 cents in I'd say "a very weak correlation" is probably right. Not because verbose languages HAVE to result in more bloated code but because it seems to me languages fine having a lot of bloat in the syntax also tend to be languages fine having a lot of bloat in the implementation or attracted to abstraction (which never does seem to actually compile away fully in large projects, even though it often largely does).
Sure, I did not think that one example is a full survey of all possibilities. I think that it's quite intuitive that this feels right:
> it seems to me languages fine having a lot of bloat in the syntax also tend to be languages fine having a lot of bloat in the implementation or attracted to abstraction
Which is why I chose an example of the exact opposite: a language not known for bloat, taking way more code to produce the exact same thing as one that's more succinct.
It's not as good as some sort of scientific survey of a wide variety of options, but if you can find examples in all directions, assuming there's no correlation until proven otherwise is a pretty solid bet, I think.
I'm not saying it's not as good as a scientific survey, I'm saying it results in no information at all about the strength of correlation one way or the other.
E.g. one could seek to find a 6' preteen and 6' adult to construct a counterexample to the idea height is in some way correlated with age. Doing so gives just as little evidence of what the strength of correlation is as seeking to find a 5'9" preteen and a 6' adult to show the correlation is positive or seeking to find a 6'1" preteen and a 6'0 adult to show the opposite. I.e. it doesn't follow one can filter the search as they please and then assert that's what the correlation of the unfiltered searches should be assumed to look like. In all 3 cases of positively correlated, negatively correlated, and not correlated we'd expect to be able to construct an example which says whatever we want to say - that isn't the same thing as sampling what the actual correlation usually is.
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 :)
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.
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.
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.
Passing by pointer (in C) reduced the difference a lot, but swapping the order of Add and Int in the Rust enum was enough to reduce the different to:
cmp ecx, 1
je .LBB0_3
vs
cmp ecx, 2
jne .LBB0_2
LBB0_3 and LBBO_2 were the same in both outputs (up to alpha renaming).
Oddly, both sources seemed to be quite sensitive to match switch and enum reordering, resulting in very different generated code. Possibly something to look into further.
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.
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.
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”.
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.
That goal doesn’t imply verbosity is necessary- just a style thing which is contrary to its goal of being a better C, given verbosity is the opposite of most C.
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.
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.
I tried Bun for a weekend around Christmas 2024. I quickly hit a bug that would freeze the runtime (issue #13237) when piping a stream into a file. I found that this had been open since August 2024, scrapped the experiment and moved on.
The issue is open to this day. If the GitHub comments can be trusted, this behavior even carries over to the Rust port.
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.
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.
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.
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.
Sounds to me like his choice of Zig was made in haste, as was his choice of Rust. If you find yourself changing a project's primary language more than once a decade (more like 15 years, but let's say a decade), the problem isn't the language but your technical decision process, and that's what you should look into first.
Some of the world's more important software - from browsers to the JVM - mix high-level languages with a GC and low-level languages, and it works not because of a style guide (even though one may exist). As someone working on the HotSpot JVM, I can say that it's done with a lot of thinking about constructing the right primitives that make this work well. Zig doesn't lack the features to construct the mechanisms required for getting good results in that domain, and Rust doesn't have features that could save you the thinking about such mechanisms.
I should add that in the 30 years I've been a professional software developer, I've worked on and advised many projects. They all ran into serious challenges at one point or another. Not of those projects that was held in high technical regard changed their language (except for things like JS -> TS or when the project planned to change languages, starting with one suitable for prototyping and expecting to switch if and when their workload grew).
All the ones that opted to switch language after less than a decade were those with serious shortcomings in their technical decision process, and those problems, unsurprisingly, persisted after the language change. After all, the very decision to switch so soon is an admittance that they'd made a very serious misjudgment, but these projects never properly debrief why they'd made such a big mistake and how they can avoid making one again.
likely you never were on a project that had tens of millions of users, you hit different classes of problems and you have to scale to new runtime or language often
(BTW, when I wrote "Not one of those projects ... changed their language", I meant after less than a decade, as a continuation to the previous comment)
First, technically respected products like the ones you describe either 1. plan or expect to switch in advance (e.g. they start with, say, Python/Ruby, expect that if they grow they'll switch to, say, Java) or 2. they improve their chosen language runtime (e.g. Facebook with PHP/Hack or Shopify with Ruby). Projects that switch a language without expecting to always show a pattern of bad decisions (clearly, if they thought their chosen language will carry them through growth and then they're convinced that it won't, that means that they don't know to judge languages' merits).
Second, this is clearly not the situation here, is it? There is absolutely no new information that Bun learnt in the past year that they didn't have five years ago, and certainly this has nothing to do with growing workloads on some service. They say they believe the language they have chosen lacks the features needed for the very core of the domain, which is dealing with JS objects. As someone working on the HotSpot JVM, I can tell you this is not true, but fine - that's what they believe. What could have taken them five years to come to that conclusion? Again, this happens to be a domain close to my own, only much simpler, and I seriously doubt they made some novel discoveries in the past year. And if it's taken them five years to acknowledge what they now think are fundamental limitations with the language they had chosen, how can they be so confident they've made a right choice now after a few weeks? It looks like they chose Zig on a whim and then chose Rust on a whim, and neither of these choices is the source of their problems and neither is the solution to them.
Putting on my machine learning PhD student hat, the way to do this was to leave 10% of the tests out as a ‘test’ set and then once the port was done, bring them back in and find out how good the port is. The port may genuinely be good but because they spent 100k of compute hill climbing the whole test suite, “the test suite passes” now provides far less evidence that the port is good. Its weird that at Anthropic, a very ML phd company, no one pointed this out.
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.
It's depressing seeing so little critical thinking despite clear and obvious incentives (Bun now being part of Anthropic) behind the reckless decisions that's been made here. Judging by this thread a well-formed article is all that's required for lots of people to just take everything at face value since it confirms the biases of what's currently fashionable.
I'm similarly distraught by comments like this. They are a staple, and they always fail their own standards. Critical thinking would lead me to believe that your judgement is heavily clouded, and that it is way more likely you're the one who's biased; either to find other people to be generally below you, or to find people being receptive to this effort any positively to be simply wrong. I'm even wondering if this is a stock comment of sorts.
Strong subjective judgements about an inexact but large sounding fraction of people, without any actual details, is a red flag the size of a skyscraper. And to top it all off, your conclusion is extremely convenient too: you're right, people are wrong, despite the blatant facts otherwise. Not exactly the hallmark of a particularly robust position, not for me anyways.
That this is a technological decision rather than rationalizations (e.g. fixing self-inflicted problems are now marketed as a rewrite win) that Rust is a better fit for an Anthropic-owned project.
Indeed as the developers behind Bun, it would be rather difficult for them to not be the originators of the bugs that they have now fixed with this.
Why is your unsupported speculation about the guy (or the people above him) supposedly deciding that "Rust being a better fit for an Anthrophic-owned project" a critical insight exactly? You not being convinced by the rationale presented does not mean he himself wasn't. Do you imagine critical thinking as just coming up with and preferring (to you) plausible-sounding alternative explanations?
Because respectfully, that's very much not how I understand the word, and I'd hope most people do not either. Maybe that's the issue. Post-hoc rationalization being a rather shaky gate with people (and AI) anyways.
Worse still, neither of the options you present are trustworthy summaries necessarily in the first place. From the blogpost:
> What if, instead, I spend a week testing if Anthropic's new model can rewrite Bun in Rust?
That sounds to me like something of an excited but cautious dare, not an arbitrary technological decision, nor some hyper-strictly rationale-supported one. It's the same kind of exploratory excitement anyone who used these things at all would be familiar with: you have an unlikely project idea, with some contentious details that are fair (see their blogpost), and some that would be simply annoying to justify (see your comment). Buuuut you also have heaps of corpo money, a lingering suspicion and interest, and AI tokens to burn. And so "fuck it, we ball". Not much to believe on it when it's a shared experience. And it's not because of just having read so somewhere, despite your assertions otherwise.
On the bright side, that price would continue to drop rapidly even if the models themselves never improved anymore. I'd be very surprised if we didn't actually end up with ~100x cost reduction of this task in the next 10 years between hardware improvements, model perf/$ improvements, and commoditization/conpetition.
For now though it is a bit disappointing trying something like this is relegated to project proposals at work rather than my personal hacking.
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.
For Bun to not have torched its reputation among its users, it would have had to publish this blog post _before_ pressing merge on that PR.
That's what underlies most of the vitriolic reaction to the events, it was done really in a really rash way.
All they had to do was a)not gaslight people about your intentions when they found the branch b)publicly post the intent to do this, and then c)publish a doc like this one right before merging, ideally leaving the branch open for like a week in case anyone in the "community" finds things to fix.
Then those UB/Miri issues others found would have been "yay collaboration" boosts instead of negative issues that prove that the approach was risky/unthoughtful.
If you're going to cross a rubicon, maybe tell people a)that you actually want to do it, b)why you want to do it and c)what it looks like after you've done the rewrite.
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.
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.
(1) The original zig code was probably heavily AI coded with lower quality, hence the bag. There is a chance that a full rewrite in zig might do as well but we will never find out.
(2) The rewrite itself is a massively successful marketing move. It shows what Claude code can do and how little it costs compared to human engineering. But the question remains whether someone else, not knowing zig, rust, and TypeScript can pull this off.
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.
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.
> 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.
I am a bit suspicious about the choice of startup time as the metric to evaluate performance in Claude Code. With a rewrite from a language like Zig to Rust, my biggest performance concern would be allocation. Where a Zig app might use a fast linear or buddy allocator, a Rust app is more likely to use malloc. During startup, both versions are likely to make tons of allocations. In fact, the Zig version is likely to make larger allocations during startup to reserve memory for its custom allocators. So I would expect both versions to be roughly on par, or Zig slightly worse there.
However, during normal execution, I would expect the Zig version to be potentially faster, because it has paid the cost of malloc at startup and now an allocation might be as fast as incrementing an integer.
This is speculation, but I would like to see performance numbers for the rest of the app lifecycle.
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.
It's partly a problem because the narrative is still "rewrote Bun in Rust in 11 days". And they didn't do that, if you consider quality of code. And now people look and see "look what you can do with an LLM in 11 days"
Engineers are pretty jaded about plans expressed by authority, especially when there are obvious pressures opposing those plans. Yearly planning doesn't matter when a reorg will change the trajectory by Q3. Sprint planning doesn't matter when you know a fire will hit before then and you won't be given enough time budget to fix it well enough for that not to happen again next sprint. Project planning doesn't matter when the whole point is masturbatory spreadsheet production before you've actually taken a dive into the hairier details and figured out what's possible and what's necessary. That barely working demo strapped on top of a non-existent backend they swore would never become production? Congratulations, you have two weeks to build the next fake demo on top of it, but the base has to actually work now.
Maybe Jared just broadcasted uncertainty and was wrong, but given his position he's not being given the normal grace you might extend to an engineer you trust.
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.
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.
> 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.
Any chance for 1.3.15 with top bugfixes for those of us who once trusted Bun and are stuck on it in production? I have migrated almost everything out of Bun by this point but I have one single project that builds into executables with Bun and relies heavily on Bun's SQLite.
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.
The condition that made this possible is that this task is well within frontier LLM capability and he had tokens to burn. Domain knowledge is separate to language semantics.
"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.
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.
> 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.
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?
To me this whole saga stands on a very thin overlapping region between "it has merit" and "I hate it". Like, the blog post clearly explains the merits and they are strong. At the same time, I absolutely hate how the author handled the whole rewrite, including throwing the whole community out the window along with all their contributions and human love.
I got curious and had a look at some of the code (>1m .rs). I was surprised to see code for a S3 client in there?
I clearly don't get the value proposition of bun? And even if I accept that you want to bundle your run time, package manager, test runner and bundler, why do you want to include things like a custom S3 client?
This post was clearly an important marketing effort from Anthropic and Jarred. Those interactive demos alone would take serious effort from a seasoned frontend engineer, AI-assisted or not. Pretty sure multiple devs were working on this post.
I wonder how much the authors now understand their project? Like, if they were given a bug, would they be able to intuit a possible location in their files that might be causing it? Or are they now essentially locked in to using LLMs to write/rewrite their code?
He's been teasing this blog post everywhere (in commit messages, multiple times on X, here on NH [1]) so I wonder how much of it was building hype compared with it legitimately taking two months to write.
I wonder if the delay of Fable has also been a factor and maybe they didn't want to release this blog post while they couldn't allow customers to use Fable and waste the advertising opportunity.
It took TypeScript team 1 year to port the code to Go, but if Claude Fable was available back then, would they better use it to port the code in 1 week instead?
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.
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?
(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.
> I asked Claude to loop the workflow on all 1,448 .zig files, and about 2 minutes in, one Claude ran git stash before committing. Another ran git stash pop. And then git reset HEAD --hard. They were stepping on each other!
I hate how easy git makes it for llms to catastrophically fuck up repos
> And if I put each Claude into a separate worktree, I would run out of disk space because Bun's git repository is too big and eventually the changes will need to be compiled and seen together.
This seems like a stupidly easy problem to fix.
> So, I asked Claude to edit the workflow to instruct Claude to never run git stash or git reset or any git command that doesn't commit a specific file at once. No cargo either. No slow commands at all.
What's the right way to fix this? I have a Pi extension that blocks any use of the word 'git' with 'stash/checkout/reset/restore' in commands which is a very large hammer approach. Is there a way I can allow a subset of git use in a nicer way without the less nice commands?
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.
> 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.
The article is very clearly human written. The author discussed on twitter that he used Claude for visualization and feedback. You can simply say you don't like the writing style, but it is not a very useful comment to have written in any case.
An extremely interesting blog post for me on a few fronts:
I'm very glad to see a holidtic approach to the memory errors and segfaults. I was tinkering on a static webpage just this this weekend, using Bun as the transpiler+bundler since it's so turnkey, and I ran into a few segfaults. E.g. when Bun saw I used an empty data uri for the favicon (avoids the browser trying to ask for one) it'd just crash. It reminded me of my own tinkering with Zig in its current pre-release state where it's usually a good mix of my poor memory management and working around bugs in Zig itself.
This post is also the best ad for AI I've seen yet. Not just comments saying they have 10xed themselves, a small personal project or thing which can (and likely will) be abandoned next month, or a one off dump of unusable code for the world's buggiest C compiler (come on Anthropic?). Instead this is a well thought out way of leveraging LLMs to do something which would otherwise probably not be deemed a reasonable enough effort.
I'm glad they included the rough cost as well. Crazy high, more than I can afford to be throwing at the wall to see what sticks, but still low enough to make sense over trying to hire developers for (even ignoring the timeline).
But it also highlights 2 really key things about current LLMs: the scaffolding can be just as valuable as the model & they still need someone able to figure out the right way to instruct and orchestrate them. Without the scaffolding the current models could never get close to handling something of this scale & quality. With the scaffolding you could probably get this to work okay enough even with a weaker model. On the orchestration side, Claude could help answer what good porting practices would be but it doesn't just get there itself, it requires hours of someone who understands the context of the project from bottom up and a clear understanding of what will/won't work to get the right scaffolding to do the job well.
Finally, it was an interesting dichotomy on presenting the port. On one hand it has been a bit opaque up until now. People saw the repo and there were some comments about testing the waters but then it suddenly shipped into production. On one hand that's awesome and I'm sure the reception here would be very different if there wasn't the "it's already been boringly shipped in Claude Code" shining result. On the other... I think I'll stick to using Bun as a personal tinkering tool for now. The velocity is so high I'm just not sure it'll land in a place I can rely on it st the speed of my org. Of course, that velocity is what has made Bun's success story and they should probably continue with it - I'm just looking forward to an LTS release :).
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.
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.
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?
Not the author but I also moved from C# to Rust. In the first place I did not consider Rust for C# works like REST API but after I proficient with Rust I no longer want to work with C# for the following reasons:
1. Microsoft don't want to open source .NET Core debugger.
2. I tired of keeping upgrade .NET on my projects.
3. Result type in Rust make me more productive than exception in .NET.
4. async/await in Rust is lightweight and a better than .NET.
5. Thread-safety in Rust is a compiler error instead of figure out by checking the docs if type is thread-safe.
6. Community libraries in Rust has a great quality and docs.
Only thing I am not a fan of with Rust is how insanely massive a debug output build folder can get (tens of GBs) and if you have enough Rust projects it can eat away a ton of storage.
This was purely a hobby project I wanted to test the limits of Claude and see how quickly it could do such a change. It was surprisingly very stable I still found bugs but was able to resolve them within a small time window. For additional context I didnt use Fable as only Opus was available to me.
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.
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.
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).
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?
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
> C++ instead of Zig would be a reasonable choice for Bun. We would get constructors & destructors. We could delete lots of extern "C" wrapper code.
> But, we would still be reliant on style guides enforced through code review, and even with ASAN, memory corruption and memory leaks would still happen.
Tell me you didn't even look at C++ without telling me you didn't even look at C++. I don't understand this at all, what's missing? There's clang-format, clang-tidy, cppcheck and so many others, what is missing exactly? Memory safety? Then why bring up C++ and style guides(?) at all?
Not replying directly to OP, just to people who never coded in C++.
Clang-format doesn’t save you from all C++ footguns, e.g. using exceptions, macros or templates in the wrong way where „wrong“ is defined by a fuzzy set of rules that requires a lot of experience and vigilance to enforce.
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
This is a frequently mentioned criticism. Is there a good argument about why that approach could have been done in the same amount of time? Seems like larger scope and more uncertainty to me.
>Is there a good argument about why that approach could have been done in the same amount of time?
as I said because it's a much smaller codebase. This is a million lines of code project. A literal Zig to Rust translation that is mostly syntactic is not going to be more than 10-20k LOC for a transpiler. That's two orders of magnitude less work.
> 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.
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?
The thing you have to remember with that $165k spend on tokens is that token prices are going to keep rising, and models may not get much better. I wouldn't be surprised if doing this same migration in 6 months time would end up costing $250k+
That's not the direction of LLM progress these past 2 years. Cost has always decreased per unit intelligence. Open weight models with lower parameters beat gpt4 that we were so impressed by.
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.
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.
In your "opinion". So are you going to stop people from making "overdone" jokes on this site or others using variations of it from now on? Or is it only mine?
My link suggests that is it just a joke and it is fine if you do not get it.
Nobody is actually stopping you, It's okay to receive feedback it didn't go over well though. You're welcome to like that or not just as everyone else is welcome to see it as a well made joke or not.
Pulling off humor is possible on HN if you really want to, just not usually by making the same joke the article already chided or blaming others for not seeing it as a joke. Humor is also usually better received here if it leans towards the explicitly obvious side (e.g. quotes, a laugh expression, a /s, or the like) or ties into a following seriously stated point in a way that is still meaningful without the joke. These kinds of things don't always need to be done all of the time, but it helps greatly since the default assumption starts as a serious post.
All of that aside, sometimes you can very obviously crack a real roller and have it downvoted or the discussion steered back to a serious one about the post. That's okay too, it's intentional the site isn't humor first and it's not reasonable to blame a reader for seeing it as such.
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.
> 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.
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”.
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.
> 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.
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.
> 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.
Stride should mostly fit the bill: https://github.com/stride3d/stride
Their homepage: https://www.stride3d.net/
Even the physics engine they use is in C#: https://github.com/bepu/bepuphysics2
Not a very popular game engine (never got the attention that the likes of Godot did), but it's nice to work with! It’s up there with Stride in regards to the “indie” game engines I like, maybe alongside jMonkeyEngine (since you typically don’t see that many Java game engines either).
> It’s up there with Stride
Edit: I mean that it's up there with Flax: https://flaxengine.com/ whoops
Stride, Flax and jMonkeyEngine are all pretty cool, not just Godot and O3DE!
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?
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.
> Gosh, I don't think any game engines have particularly good test suites at all.
What? I do understand that a CRUD app with little to no logic do not focus on test.
But any kind of engine.. i can not understand that it's not a priority? In general I'm not a big fan of unit test on simple websites, they do not give any real value compared to effort
But I remember working on a complex codename. It was extremely important to have close to 100% unit test in the core part. Saved me a lot.
Mostly, because a lot of game engines are ancient relics, tracing their lineage all the way back to Quake 1.
The development practices are not exactly up to date, and game development is in no hurry to change. It doesn't help that software development wages there are not at all competitive - game development selects for passion, not skill. People who want to build robust modern codebases and people who want to build AAA games are different people. So there aren't many game devs who want to push for better test coverage.
But it's also because game engines are dealing with many, many things that are hard to test for.
You know how messy it is to test a website for "does this layout look right" or "can you navigate from A to B"? Now multiply that by complex 3D geometry. A lot of what game engines do is dealing with complex 3D geometry, where the primary verification is "does it look right" and "does this interaction feel right". Which is why game development traditionally has wide human QA, and slim unit testing.
Only now do we have software that can sort of, semi-reliably, automate testing for "does it look right".
A game engine has a vast space of possible outputs, all of which will be considered good enough.
Its primary output is pixels and sound. Those are hard to test in a reasonable way. Screenshot testing is useless in a codebase where most of the changes are about making the pixels prettier.
> In general I'm not a big fan of unit test on simple websites, they do not give any real value compared to effort
And then your site gets more traction, features are added, things are refactored.
And now you're looking at what used to be a simple site, still with no tests.
It's a habit, that pays off long term. You don't do it for yourself, you do it for who changes the code next. Might be you, or not. Even when you do it yourself, you can't hold all the requirements in you brain, you write those up in tests
I agree - maybe some modern game engines have unit tests for stuff like their physics engine and their "standard library" code (optimised data structures, maths utilities, string utilities etc) but as others have said, testing sound and vision is hard, and something that hasn't been mentioned is all the different flags in a game engine - testing even a sensible subset of all the different sound and rendering variables would be a huge undertaking.
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.
Box3D just showcased some stuff including deterministic replays. If you wanted to port that, you could probably import the replay and make sure it plays back the same way in your new language. I think it captures the inputs and forces applied, not the pixels.
I suppose rendering is a component of a game engine too though, not just physics. I don't know how to do that reliably. Even if you captured pixels, it'd be annoying. If you've ever tried doing screenshot based diffing on web you will know that slight changes in aliasing in Chrome bugger everything up. Things that should be equivalent randomly aren't but not in a way that any human would care.
Several C++ parts of Unity have been slowly migrated to HPC# though.
UE 5 doesn’t come with a scripting language even though there is blueprints which a node editor easy enough to be used by non dev. Studios like embark (The Finals, ARC Raiders) have been successful integrated AngelScript in UE 5 and use it in these games. UE 6 will see the appearance of Verse: the scripting language used for Fortnite (and the end of blueprint at some point). At first I was sad to see yet another language but it is worth looking at the doc to see why and how it makes a lot of sense.
> 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).
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.
> 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.
I addressed some of these points in my reply to a sibling comment:
https://news.ycombinator.com/item?id=48856158
I may have been a little overly specific, since there are other issues besides cycles that also block splitting crates apart, but from what I’ve seen it’s very common for modules within a crate to have cyclic dependencies and therefore not be easily factorable into separate crates.
The industry accepted way of handling circular dependencies is to not have them and heavily lint against them in languages which permit them in compilation or runtime.
You’re thinking at the wrong scale. Rust allows circular dependencies just fine, within modules in a crate. And it’s extremely common for modules within a crate to have at least some circular dependencies - type X has some method (trait impl of inherent impl) that mentions type Y, and type Y has some method that mentions type X. In fact, I would be surprised if you could name me a single medium-size-or-larger popular crate that doesn’t have at least one cyclic reference between modules! Though, sometimes those cycles are not essential and could be avoided by splitting up modules. But sometimes they are. Either way, in C or C++ those modules would probably be their own compilation units.
That said, you also run into related parallelism blockers without cycles. For example, the orphan rules force most trait impls for a type to be in the same crate as the type definition. Also, a module which has no source-level cycles will often have cycles after monomorphization. In this case, Rust doesn’t prevent you from splitting the code into crates like it does with source-level cycles, but you do lose most of the actual codegen parallelization unless you can switch from generics to trait objects.
> The rust compiler is very slow.
It's not “very slow”, that's a tired meme. It's slower than it could/should, but complaining about rustc being “very slow” is a clear misrepresentation, especially when everybody seems to have been fine with tsc's historical performance for instance. It could be nice if it was faster indeed, but people claiming it's “very slow” are just showing they never worked with it.
> The best way to speed it up appears to be organizing a codebase in many crates. This is not preferable ergonomics to many.
In this context (where you don't plan on publishing you stuff on crates.io) a “crate” are just a directory at the root of your repo, the ergonomic impact is literally zero.
I am using Rust since 2016 productively... before I dabbled with it.
Rust is not compiling any slower than a comparable C++ codebase for me.
It is compiling much slower than a managed language like Kotlin, C# etc. though. Which is an unfair comparison anyway.
The problem with e.g. gamedev is the iteration cycles. It's very creative work and not so much your average engineering job (apart form game engine dev).
But again, that's an unfair comparison, because even in Unity and many if not most other game engines, there is a scripting language that is used for most of the game logic, that doesn't need hyper performance...
Still, when compared to such languages, Rust indeed does compile slowly AND one has to say: Rust is selling itself not only as a safe, blazingly fast systems programming language these days, but it also is used for its type system etc. and then, when you come from a managed language, compile times really suck.
(Although debug builds are better, they are not an option for game dev for example, because the binary is just too slow then... 200fps vs. 20 :X)
Why do you think it is not slow? As far as I know the only language that compiles slower is C++, and even then the compilation speeds between c++ and rust seem to be comparable. I believe c, Fortran, zig, C#, Java and golang are all faster compiling languages. That makes rust pretty slow in my book. I get that it doesn’t bother everyone, but that doesn’t change the facts.
> Why do you think it is not slow?
The average cargo check for the projects I've worked on, usually finish in less than 1 second, with `cargo build` completing in a single digit second (often below 2s), it's not slow by any means.
> I believe c, Fortran, zig, C#, Java and golang are all faster compiling languages.
Sure, but the difference between type checking is 10ms and type checking in 500ms is barely noticeable for a human being anyway, despite the x50 difference.
> That makes rust pretty slow in my book.
“Slow” is a perceptual thing. It doesn't matter if it's slower in absolute benchmark performance. If it doesn't slow you down in your work it's not “slow”.
> As far as I know the only language that compiles slower is C++
Typescript's compiler is much slower than Rust's, but it's plenty fast enough for most people and you almost never see complains about it because it mostly doesn't matter outside of pissing contests.
Typescript's compiler is much slower than Rust's, but it's plenty fast enough for most people and you almost never see complains about it because it mostly doesn't matter
But you have to compile Rust code to run it. You can run TypeScript code without type-checking it. That’s a massive difference in the development workflow.
The new TSC, supposedly 10x faster, will be very pleasant to have but not as much of a game-changer as you might expect. A 10x faster Rust compiler would be incredible.
> But you have to compile Rust code to run it. You can run TypeScript code without type-checking it. That’s a massive difference in the development workflow.
And yet I'm waiting for TSC every day while almost never thinking about rustc…
> The new TSC, supposedly 10x faster, will be very pleasant to have but not as much of a game-changer as you might expect.
It will be very nice, but I don't expect it to be a game changer, tsc isn't fast but it's fast enough to get the work done, the annoyance is there but it's objectively minimal. Anything else is pointless internet language war.
> A 10x faster Rust compiler would be incredible.
For development? Not really, not for me at least. Against the endless rants about rustc's performance on HN, absolutely.
> tsc isn't fast but it's fast enough to get the work done, the annoyance is there but it's objectively minimal.
For our small codebases, maybe. The tsc-in-Go announcement had VS Code compilation go from >120 seconds to ten.
"Compiling" is vague here; for TS I think you need to distinguish bundling from type-checking.
If you're talking about bundling the entire app, 120 seconds down to 10 seconds is a great saving, but other bundlers can do it much faster already. Most people don't bother using TSC to bundle their code. I can understand why Microsoft might insist on using it, but it's not typical.
For type-checking the entire app, I would see that as akin to running all the unit tests. 120 -> 10 seconds is excellent, but not something that should be a constant bottleneck in your development workflow.
I can definitely see that 10x improvement being crucial on large teams (and/or LLM swarms) where the speed of the CI queue becomes a bottleneck.
Exactly: tsc was “slow enough to be painful” in the context of the 2.5Mloc codebase of VScode.
But it's not too slow for most people.
Likewise, Rust may be slow enough to be painful for some big projects that need to often rebuild from-scratch in release mode, but that niche is definitely much smaller than the size of the “rust compiles too slowly” crowd on HN.
I gave Rust classes in university a few years back, and literally none of my students complained about slow build times. At this point it's much more of an internet meme than an actual pain point for most devs.
Small apps in college are much different than huge apps in the real world
Most people complaining about Rust being slow have never worked on anything close to a production app written in Rust.
By the way, for most apps, rhe difference from an app we'd write in class is not as nearly as big as you'd expect: most of the code lies within dependencies anyway, and you need roughly the same amount of them in both cases.
Of course there are exceptions, apps that are tens of millions of LoCs exist, but it's not the majority.
(And they tend to be naturally split in multiple crates, which is the default workaround if a rust project takes too much time to compile).
Speaking as someone who has also given courses at university teaching a programming language (Swift,) the students also do not know how fast computers are and that when their brand new super-computer lags and hitches for full seconds while coding it's pretty much "working as expected" to them. I haven't written Rust in a few years, but I remember it being remarkably similar to Swift both in API design ergonomics and compiler quality. I am open to this having changed, and I can appreciate @stymaar's frustration if it has done so drastically.
Compiling my C code with gcc happens in a single eye blink. Changing the format to .cpp and compiling with g++ takes 5 eye blinks. I've never used rust and I can't imagine blinking more than 6 times while waiting for my code to compile.
And you wouldn't need to, because the Rust compiler is "slow" relative to compilers like Go. Relative to Clang and g++, the Rust compiler is fast.
Most people use esbuild or swc or oxc instead of the typescript compiler directly specifically because of how slow tsc is.
In fact tsc was slow enough that it was rewritten into a different language for version 7, with the performance of the compiled output as the primary motivation.
Actually it is possible to make C++ compile faster than Rust, because the ecosystem is more friendly towards binary libraries, then besides incremental compilation, you can also get incremental linking.
Additionally there are ways to have interactive code reloading, e.g. Visual Studio and Live++.
Or even a proper REPL, ROOT, CINT, Xeus.
Naturally all things that Rust could also have, only it hasn't been the focus and there are several decades to catch up.
It depends on what you're comparing it to. It is indeed very slow when compared to a C compiler, or a zig compiler, or even a Java compiler. C++ can be comparable, or slower, or faster, depending on the C++ features used.
Sure, maybe rustc's performance compares favorably to how tsc used to be, but that's not the benchmark most Rust developers (such as myself, for more than 10 years now) care about.
> a “crate” are just a directory at the root of your repo, the ergonomic impact is literally zero.
Nonsense. That's another Cargo.toml to maintain, and another place you might need to add/remove dependencies, and you have to manage the dependency tree among your sub-crates. The ergonomic impact is absolutely not literally zero, and I'd even say it's enough to be annoying.
As far as I'm concerned, I already hate the write-compile-run cycle, any further slowdown in that irritates me exponentially.
it is insanely slow. I regularly need to wait for minutes just for the final crate to compile when compiling some tui program from scratch
As much as I like Rust,
> In this context (where you don't plan on publishing you stuff on crates.io) a “crate” are just a directory at the root of your repo, the ergonomic impact is literally zero.
Is not true, you can't have circular out of crate dependencies. This often means you now need a third crate that's a trait crate, but then you can't implement external traits on external types, so you need bridge crates, and so on.
Rust's limitation of performance requiring lots of crates indeed has real impacts on projects beyond simple hello worlds or trivial cli apps.
Considering it to be a zero impact issue is rather reductive, even in the context of the language's design principles itself.
Rust for all it's good sides has had a lack of interest from core team and energy to drive real valuable changes beyond the nightly blockers into stable, or maybe they are working real hard and the boulders are so hard to move that we can't see any change looking outside in.
Is it justified after the gargantuan effort that was merging Async and GATs? Yes.
But acknowledging the problem doesn't help us solve it.
This is to say, Rust is an amazing labour of love project that seems rather stuck in time due to lack of investment/time/effort or all of the above, I am not sure, but it's moving slower than I would like, at solving the problems Rust developers face everyday.
And yes Rust compiler is slow (very slow is arguable, compared to modern C++ it isn't that bad, but compared to say Go without cgo, its horrid), Cargo is just bad, without proper hermetic builds and stuff, even when I setup sccache for our team and our cache hit rate remained below 20% and most of it was just C++ deps hitting the cache.
Just to be clear Zig builds are quite slow too, especially on windows where debug builds also use llvm.
TBH Zig debug builds on Linux also don't really feel that fast, C still compiles faster for me by a considerable margin.
Either way as someone doing Rust everyday for last 8+ years, 5+ in small/large teams, I have lots of complaints and I am sad, it has been over years of me complaining without nearly enough progress, they have a survey declare ambitions, and then well... things just don't move much.. not nearly as much as I would have expected.
Honestly given I have been a rust dev for over half a decade now, I should instead of commenting here probably be figuring out if I can contribute to Rust to help things along (faster?).
But most meetings and discussions happen at very EU/US centric times, and number of non US/European core contributors in Rust is also rather small(I don't know of one but I hope there are a few) so as someone not in those circles, I don't have the energy to figure out my way in, with my day job.
Tldr; Is Rust the language for the job here, likely. But the question should be why couldn't have been the language Bun was written from the very start. Why does Zig or C++ or C seem so much more productive.
Sorry for ranting about this but this felt a little relevant since you claimed people complaining, are likely people who have never worked with Rust.
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).
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.
> The rust compiler is very slow.
It was very slow. It's gotten a lot faster over time (over 2x faster). It's still not exactly fast, but it's definitely faster than C++. Although C++'s slow compile times are often complained about they were never really enough to stop most people using it, including for games.
> a garbage collector eliminates a large amount of defects (including the ones stated in the article) without any added friction
I'd be careful about that "without any added friction". Rust's lifetime/borrowing system tends to lead to less buggy code because it encourages structuring code in a less spaghetti way. GC does eliminate memory errors but you also lose that non-spaghetti code structure.
Because contrary to Rust, C and C++ have a culture of binary libraries.
You are seldom compiling the world from scratch.
Especially in the platforms dear to game devs.
> You are seldom compiling the world from scratch.
True in Rust too though - you're normally doing incremental compiles. And even though you're compiling the world, it's still on par with C++. For example I just tried compiling a hello world Bevy project, which has 462 crate dependencies - pretty big. It took 2m20. Totally reasonable to build an entire game engine and all it's dependencies.
I wish they had reported the compile time of Bun before/after the Rust port - that would have been very interesting.
Yeah but compiling full Unreal from scratch already requires going down the path of forking it for own purposes.
Same applies to most commercial libraries, where code is usually provided for debugging purposes, not for building everything from scratch.
Also incremental linking on Rust, or hot code reloading is still not something that works out of the box.
How beefy is that machine to achieve 2m20? I started using C++ on MS-DOS, on a 20 MHz 386SX PC with 2MB RAM and 20 MB HDD.
Especially relevant in current times.
> How beefy is that machine to achieve 2m20?
Ryzen 9 3950X (16 core). I think it was top of the line 5 or 6 years ago but it only cost me about £300 second hand for the whole PC (with 128 GB RAM - before the RAMpocalypse!) Definitely not a crazy machine.
> I started using C++ on MS-DOS, on a 20 MHz 386SX PC with 2MB RAM and 20 MB HDD
Yeah, I mean early C++ was quite a lot simpler than modern C++23! Of course it's going to compile way faster. You're not compiling UE 5 on that machine! Compilers didn't have so many slow optimisations back then either.
Yes, but no one needs to use C++23 to the full extent to stress test the compiler in -O3, or go crazy with compile time execution.
While I could comfortably still develop C++ in a Asus 1215B netbook with 8 GB and SSD, thanks to all the native libraries I could install, and make use via pkgconfig, the same could not be said to play around with Rust on the same netbook.
This matters, because not everyone can afford top of the line desktops, especially in 2nd and 3rd level countries, which then plays a role in language adoption.
Some even make do with what they can run on tablets.
I don't think I really agree with that. You can make do with less powerful machines in Rust too. Until this year I was using a 12 year old quad core machine that was only a bit faster than a RPi 5.
I think the biggest issue is actually disk space. C++ isn't exactly efficient with disk space but Rust is on another level. You're going to run out of disk space on that netbook it you have any more than like 2 Rust projects built.
On that netbook, this tiny Gtk Rust application took about 10 minutes from a git clone.
https://github.com/pjmlp/gwc-rs
The original C++ versions was done in 2 minutes, because it spent zero minutes compiling all dependencies.
Needlees to say that first compilation had an impact on battery charge as well.
Naturally on such a beefy machine it will fly given how fast Bevy gets compiled.
For what it’s worth game devs often use C# or C++ engines which have even worse issues. Rust also has the early beginnings of hot reload which bevy adopted if I recall correctly [1]. I still think a higher level language is good for “business” logic to orchestrate how efficient low-level pieces connect, but Rust is holding its own even against those use cases IMHO.
[1] https://docs.rs/hot-lib-reloader/latest/hot_lib_reloader/
> 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#.
Well for c++ memory safety and sharp abstractions and even worse compile times than Rust. I’m not aware of hot reload really being done in c++ at any scale but I’m not a game dev so I’m open to learning.
C# AFAIK holds a minor place in gamedev and also has slow compile times maybe? I assume it has better support for hot reload times. But generally the performance profile isn’t there for the most demanding games even if the DX is.
It's not specific to game dev but Visual Studio has hot reload for C++ that you should be able to make use of.
C# compile times are fast. Performance is a lot better than you probably think, especially with modern .NET (not what Unity uses).
Visual Studio limitations around hot reload are quite unrealistic for any serious codebase and only work on Windows with Visual Studio when you started it under a debugger.
Rust’s hot reload is cross platform if I recall correctly and is always available until you disable it from the build (eg debug on, release off). It also has a better story for working around the limitations that Visual Studio just throws up on.
C++ hot reload is not a common experience in the ecosystem.
> only work on Windows with Visual Studio
Really shouldn't be a dealbreaker when 95% of your users will be using Windows (to play games), so your most tested platform should be Windows.
> when you started it under a debugger
Hot reload isn't a replacement for scripting IMO. It will never be as good. Even hot reload in Rust would have more limitations than an actual scripting language.
Sure, that doesn't take away from the experience of Rust being better than C++ even if you probably still want a scripting language too.
In total Microsoft only holds ~12% of the total video game market share across PC and console in terms of owning the platform (i.e. Xbox + Windows). I think you're overestimating how many game developers get to use reverse debugging for gaming. In practice given the limitations for Visual Studio's implementation, I highly suspect that number is very rarely used anyway.
It is a share big enough that Valve cannot have games for the SteamDeck without Proton.
Yes, it is, most game studios use Live++, a commercial product which whole goal is to enable live reload in game engines.
Likewise CERN's ROOT is quite famous, nowadays superseded by CINT, and integrated in Jupiter netbooks via Xeus.
> Beside that, for many problems, a garbage collector eliminates a large amount of defects (including the ones stated in the article)
Languages with garbage collection are generally considered "memory safe". GP was talking about choosing a language that requires manual memory management, but doesn't have something like rust's lifetimes to catch things like use-after-free.
Hey thanks for teaching me a word today, and to be finicky myself, the convention seems to be to use a single n it. :)
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.
Agree 100%. Almost everything I have written with AI is in Go, and strong typing is really really nice (as is go vet and golangci-lint to keep the generated code in line).
I imagine writing plain js or python with it would be much much riskier.
Well annotated code is fine in Python too.
> and you decide to drop to down to C++
Going from Rust to C++ seems a strange choice, since you get most of the same problems just without memory safety. Zig, Odin, C3 or even plain old C though? At least those languages have things to offer that neither Rust nor C++ provide (and if it's just compilation speed).
Market share, IDE and graphics tooling, and industry standards.
LLVM is not going to take PRs written in Rust to fix the Rust compiler backend, for example.
Neither are OpenJDK, .NET, V8, JSCore going to take such PRs.
By the way, LLVM and GCC would also not take PRs written in C.
'Industry standards' is where programming languages go to die ;)
As for PRs: well yeah of course, when in Rome...
C has been doing quite well with industry standards like UNIX/POSIX, OpenGL, Vulkan, VFX, OpenMP,..
Same applies to C++ with CUDA, SYSCL, HPC/HFT frameworks, LLVM/GCC, AI compilers,...
They don't look dead to me, even if we as industry could be much better by now.
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.
> The first language I could "just write" in was C. I had internalised the language and its standard lib and didn't need the internet to work with it.
I bet $4.20 you didn’t write C. You wrote something C-like which the compiler didn’t reject because the C standard has a gigantic surface of ‘undefined behavior’ which means once your program does one thing out of spec it isn’t C anymore silently.
> 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.
Rust-the-language may be medium-sized. Rust-the-stdlib though?
The Rust stdlib has a lot of essential low-level types needed for adding a 'semantic layer' on top of the language so that the language user can exactly 'express intent' (types that arguably should be language features instead). Just look at all those detailed methods needed to make RefCell work, and what does 'into_inner' or 'undo_leak' even mean?
https://doc.rust-lang.org/std/cell/struct.RefCell.html
E.g. what's a single concept in C (e.g. "the pointer") easily has a dozen specialized equivalents in Rust, just because Rust needs the additional information to do its memory safety magic correctly.
The entirety of Rust and its stdlib has a huge 'semantic surface' compared to most other languages (even C++), and I think this difference in the semantic surface size to other languages is exactly the one thing that either attracts or repels people to/from Rust ;)
> what's a single concept in C (e.g. "the pointer") easily has a dozen specialized equivalents in Rust
That "the pointer" is a single concept in C is the root cause of absurd numbers of bugs over the history of C.
The questions of how long the memory a pointer points to lives, what threads it is safe to access from, and how it is allocated and destroyed all still exist in C. Those answers are just implicit rather than explicit like they are in Rust. It's not like Python/etc where you don't have to worry about these things.
In general I agree, but this topic is IMHO exactly what separates the Rust lovers from the Rust haters ;) E.g. how strong is too strong when it comes to type systems. Rust afficionados generally seem to tend towards 'the stronger the better', and accepting the downside of a fairly rigid code base.
I prefer a middle ground between strong and weak typing (but yeah, C is arguably too weakly typed, but the exact sweet spot is different for every programmer).
A reasonably smart C compiler that has visibility on all code in a project could theoretically infer a lot of the same semantic details that must be manually provided in Rust by looking at how the pointer is used in the wider codebase (basically what static analyzers are doing by reconstructing control flows). Of course such an extensive analysis would result in even worse compile times than Rust ;)
Of all the things I expected to read today on HN, "I chose a programming language that appeals to my political leanings" was certainly not one of them.
With the use of quotes there, you've put those words in my mouth. I didn't say that.
What I am trying to express with the statement you refer to is that zig appeals to me on an aesthetic level. It suits my tastes.
I mentioned liberty because I appreciate that zig allows me to have complete control of memory allocations, and gives me quite a deal of control over the metal. I like this and I like that I don't have to appease a borrow checker. Zig's compiler and type system is strict enough to guide me to correctness, but the experience, broadly, is not so onerous that programming becomes tedious and frustrating.
These qualities, I suspect, resonate with my individualistic tendencies.
With respect, it's difficult to interpret "libertarian sensiblities" as something else than "political leanings". Now "liberal" is a much more general -- I wouldn't necessarily call that political -- but what you said had a strong political connotation, hence my comment.
Your explanation lands otherwise. I can't relate to "I don't have to appease a borrow checker" though. That reads like a deliberately uncharitable read of what Rust's compiler is doing. That being said, it's definitely not for everyone.
I tried Zig. Loved it. But then after a few weekends I said to myself: "Wait a bit. I've been down this path before with C and C++. I know exactly where it ends." -- and bailed.
To me these days low-level programming is basically: either go all the way, or don't go at all. Sadly Rust is not like, going really all the way, but it's IMO the closest we got. And before somebody starts enumerating obscure languages that barely have a community: I include multi-axial evaluation here i.e. PL features, stdlib, ecosystem, richness of education (Rust has _a lot_ of good books and courses), and others I am surely forgetting at the moment.
Zig is great. But I'll not take marginal improvements anymore. Not in my personal life and not in my work. I'll get big ones, or not get them.
Since we are explaining philosophies, now without political undertones: that's mine.
> 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++.
It depends just how fast you need it. C++ is much easier to get to zero abstraction code.
In Rust you are constantly fighting the stdlib and other libraries, and you have to litter your hot code with unsafe blocks to get it to stop adding a branch to nearly every object access, be it for bounds checks or over/underflow checks.
C++ does a much better job at giving you a zero abstraction API, and you can always drop down to raw pointers if you want, without(!!!!) unsafe blocks and weird tricks. Of course it's unsafe in C++ but the friction to writing a branchless hot loop is muuuuch smaller.
When profiling and optimizing Rust code, I very often find myself poring over the generated code, making small changes, reading api docs, and trying again, much more than in C++. Lots of unsafe Rust APIs are not even nearly good enough, even with most checks turned off you will find branches that just branch to panic!(), which is, you guessed it, still more code and a branch than the code would suggest.
I get why people think that most systems languages are the same "speed", but they really are not if you are hitting limits of the hardware in your hot loops.
How is not having to mark your unsafe code as unsafe a good thing?
You couldn't have come up with something more incomprehensible.
If 99% of your code doesn't use unsafe, why contaminate 100% of your code base with footguns?
I agree with your point, but for completeness:
> How is not having to mark your unsafe code as unsafe a good thing?
The problem with unsafe code in Rust is that IIRC nobody actually figured out yet the "rules" of unsafe i.e. which invariants you can stretch and which can cause UB. My (not super up to date) understanding is that this is an active area of research and progress is being made and also that in practice there are many well understood usages.
In short unsafe rust is somewhat worse than C++ as the boundaries of UB are less well understood/defined
I don’t know what you’re referring to. Unsafe seems pretty well defined for 99% of use cases. Unsafe blocks allow you to dereference raw pointers and call unsafe functions. Thats about it. Remarkably, even in codebases which need a lot of unsafe (eg the kernel), almost all code is safe code.
> over/underflow checks.
Integer overflows are not checked in release builds by default, since they are not related to memory safety.
On the other hand, rust emits noalias everywhere, which helps in autovectorization.
Yep. And array bounds checks have a miniscule performance impact at runtime because they're so friendly to branch prediction.
It depends what kind of hot loop you have.
If you have a hot loop where it matters, you can put an assert outside the loop which lets llvm remove the bounds checks. Or use unsafe { get_unchecked() } to remove the bounds check entirely.
Exactly, yes. I know it's possible, of course it's possible, its just not trivial like it is in C++.
Most developers I have met don't know how to use a profiler, so not sure any of this discussion matters at all anyway, but I feel like it's important to note when the default in Rust is safe, whereas the default in C++ is fast (and more or less unsafe)
Is it though.
There are so many situations where something is guaranteed to be safe but there is no way to express that in the Rust typesystem, so the only thing you can do is to wrap everything in Arcs and Mutexes, which introduces allocations, pointerchasing and locks
Hard to imagine a scenario where you don’t need a mutex for correctness and yet somehow Rust forces you to do it?
Unless maybe you mean tokio’s work stealing executor, but you can just not use it.
I said rust is just as fast as C++. Not safe rust. Use unsafe where it’s appropriate, obviously.
Just use unsafe then
yeap, unfortunately, only few can see this.
It depends a lot on the coding style. The sort of Rust code that's heavy on Rc, Arc, Box, RefCell etc... (e.g. the typical band-aids to work around borrow checker restrictions) will be slower than typical C++ code (it's also possible to kill performance in C++ of course, just use std::shared_ptr for everything). E.g. I'd wager that performant Rust code is trickier to write than performant C++ code because you'll have to design your entire Rust codebase around borrow checker restrictions, while C++ lets you 'cheat' without having to fall back to helper types that incur runtime overhead.
It's not though. It's fast enough for many applications but if you need to write a hypervisor then suddenly bounds checks and atomic pointers become significant. Not to mention that rust dramatically reduces your ability to control where memory is allocated.
I write in rust and c++, rust isn't as fast. Rust is easier to work with and, compared to the Java crap it's replacing at my work, it's a lot better but it's certainly not zero cost abstractions the way c++ can be, nor is it great for data oriented design because you're hoping the compiler will do the right thing, consistently.
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…
Sometimes we have no option, given the industry standards that expect C or C++.
Khronos, Open Group, NVidia, Microsoft, Sony, Nintendo... aren't going to change their APIs and SDKs, just because of social media discussions on the merits of C, C++ vs other safer alternatives.
I agree we should minimise their use, however not everyone accepts a dual language approach, nor there are alternatives in such domains, even if they technically exist, you still need to overcome the human and political factors.
Hence why it is so relevant to fix C and C++ security flaws to some extent as well.
Obviously my comment of irresponsibility was “given that there is a choice.”
Though that’s one nice thing about Swift: it has a very good interop’ with C now, and a “starting to get pretty good” interop’ with C++. So that can help, sometimes. (Obviously, I reiterate, I understand there are situations where the choice is just not possible, and enhancing C and C++ is indeed a good thing.)
The nice thing about Swift, or Java/Kotlin on Android, is the platform owner attitude, either adopt it, or go elsewhere, that is the only way safety improvements are pushed into mainstream.
Im constantly surprised by the disk size required by rust builds. It takes over 50G to compile zed IIRC.
> and human involvement
Isn't ironic for a project that successfully killed all past and future human involvement?
> I can understand when you need the absolute best performance and you decide to drop to down to C++
Could you help me understand with an example or two? My understanding is that well written Rust and C++ are often identical in performance thanks to relying on the same compiler backend (both clang and rustc use LLVM).
Even, possibly, the other way around in some cases. A seemingly identical program may (and it does occur) compile to a faster machine code in rust than in C++ due to extra markers (eg alignment) that rust compiler is able to provide to llvm.
This comment makes no sense. For one, "you need the absolute best performance and you decide to drop to down to C++", no, C++ and Rust are virtually equivalent in that they pretty much expose the underlying machine fully; if anything Rust makes it easier to write idiomatic performant code.
For two, there are plenty of reasons to use C++ unfortunately: compatibility with existing code based and availability of developers to name two.
The main reason to use C++, and Rust compiler also falls into it, is existing infrastructure, SDKs and industry standards.
I would love that Java and .NET would provide all layers like several managed languages in the 90's,
However it has taken a quarter century to get back features we already had in Modula-3, Mesa, Oberon and co.
People get attached to things they've been using for decades. Also most of the world is still written in c/c++ so any critical mass has quite a lot to go up against.
Rust isn't perfect but it solves a lot of the pitfalls of C++ (not just UB, package management, horrible cmake files, linker errors etc.)
Rust is C++ like language, with more safety. It makes no sense to say that to get performance one can drop down to C++. As far as I am aware, you can get as fast as C with Rust. Of course, that might mean to compromise on something, some bound checks, some code ergonomics, or something else. You can write ASM in Rust, so it really gets as low level as it gets. And what I find amazing is that, similarity to C++, you can get both low level and high level code in the same language. And this is intrinsic in the language complexity: if you take a simpler language with a less powerful type system (C-class languages), you lose this ability.
Ownership is a very limiting coding constraint, and bypassing methods, when ultimately needed (e.g. cell), cannot be engineered to be ergonomical.
Fortunately there are also many other memory safe languages to choose from.
rust is still a non starter in some niche embedded applications (way too big). i still write c and assembly constantly.
> way too big
https://github.com/tormol/tiny-rust-executable
This produces a 137 byte binary. Obviously AMD64 isn't used in embedded, but I've seen ARM ones that are in the ~256 range.
It's all in how you use it. Of course, if you don't care about binary sizes, they can get large, but that's very different than actually paying attention to what you're doing.
I tried to use Rust for a tiny microcontroller (GD32VF103, 128KB flash).
First of all, I was amazed by how much I could do with Rust (safe Rust, even), and how well it was interfacing with my handwritten RISC-V assembly. I will definitely use Rust again for the next such project.
But, every time my functions would get over a certain size, suddenly some optimizations stopped working, and Rust was trying to put the whole panic/fmt machinery into the thing, going above my linker's flash size limit. It was insanely frustrating, since there was no rhyme or reason to it. Simply adding another branch to a match made it do that. Or another if statement that was exactly the same as the 4 before it.
The 137 binary thing does not scale.
On that universe you would be better off with BASIC or Pascal compilers than Rust, which would already be safer than C, while offering similar sizes.
Mikroe has C, Pascal and BASIC compilers for all kinds of microcontrollers, that is their main market.
I don't disagree that I think that the Rust project could do more to make this kind of development easier, and it is true that it doesn't come for free. That doesn't change the point that if you want to, you can do it, it is not a fundamental language limitation.
It is a fundamental language limitation, unless you want to claim that the core library (or rather what's left when using no_std) is not part of the language.
The problem comes from a combination of three things:
1. Rust's standard library (including core) likes to panic a lot, e.g. for code that is genuinely unreachable (and this is fine)
2. Rust/LLVM cannot always optimize unreachable code away (and this is also fine)
3. The presence of at least one panic causes Rust to also include the error string format machinery, which is HUGE (and this is completely unavoidable)
Because of #2, there is no way to prevent this for larger code. I can define my own panic handler, but I can't prevent panic!() calls from inside core from constructing the format message using core::fmt before they call my panic handler.
And so any non-trivial code sometimes just randomly becomes 3x larger, and I can no longer fit it on my MCU, despite never actually printing or caring about any panic messages.
I think we just disagree about what "fundamental" means. If you don't use panics, you don't get the machinery. This means it's not fundamental.
What you're talking about is the ease of which you can not include the panic machinery. I agree that it is not always easy to keep out, and that I would like if it were to be made easier.
But people are doing real, commercial projects on MCUs your size and smaller.
> If you don't use panics, you don't get the machinery.
I'm not using panics, and yet I'm getting the machinery. That is where my frustration is coming from.
> niche embedded applications
How niche are we talking? Rust is deployed on a bunch of popular microcontrollers at this point
> I can understand when you need the absolute best performance and you decide to drop to down to C++
What? Rust generally doesn't have worse performance to C++, so this argument makes no sense at all to me.
> and I also relate with just personal preference, but beyond those it seems a no brainer to me.
That's another argument altogether.
It's totally fine to have preferences and decide to go with them of course.
tl;dr: my job requires me to do things where Rust's memory model can't save me.
https://news.ycombinator.com/item?id=48833867
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.
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
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
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
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.
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.
"In economics, the Jevons paradox is said to occur when technological improvements that increase the efficiency of a resource's use lead to a rise, rather than a fall, in total consumption of that resource. Greater efficiency reduces the amount of the resource needed per application, lowering its effective cost; if demand is sufficiently price elastic, this induces demand, frequently resulting in a net increase of total resource consumption."
https://en.wikipedia.org/wiki/Jevons_paradox
the elastic demand will be consumed by ai
jevon's paradox just says people will consume more software as software gets cheaper, which is likely true, not that there will be more high paid jobs for programmers.
as programmers are not the resource, the program is the resource, programmers were the means of production of said resource.
stated differently: in a world where you dont need programmers to make programs, there is infinity of programs, and no jobs for programmers.
You are assuming an infinite productivity boost, i.e. that no programmers at all are needed to make programs.
A more realistic scenario is that programmers are still needed in the foreseeable future (for some definition a what a programmer is, even if it's "understands software enough to be able to write good prompts and judge the results"). So the question is how the productivity boost compares to the increase in the amount of software being made.
Yes ai + programmer are the resource.
Ai won't work on it's own until we get agi.
yes, I assume we will have the 'replicator' from Star Trek, and programs will just appear as you want them.
experiencing the gpt3->4o->sonnet4->opus4.6->fable trajectory I am fairly confident what we call programmer today will not exist, in the same time regular people will finally be able to tell computers what to do and this will unlock the next stage of complexity in manufacturing/material science/medicine and so on.
of course I am likely wrong, people say: its never as good or as bad as you think.
> gpt3->4o->sonnet4->opus4.6->fable
While there are a lot of resources being poured into improving and integrating tooling and use cases and increasing model sizes, the leap between the models you notes are not as much as you think it is. It's the same tech that's scalable to a certain limit of diminishing return. It's a recurrent pattern in technology.
> yes, I assume we will have the 'replicator' from Star Trek, and programs will just appear as you want them.
Yes, perhaps one day. Probably no other "job" as they are today will have the same shape and form. Cancer will be cured and fission will be solved. We may even crack teleporting. Let's hope these all happen and the outcome is not detrimental the livelihood of humans.
> It's the same tech that's scalable to a certain limit of diminishing return.
of course, my point was that gpt3->4o was smaller jump than opus 4.6->fable
Sorry, but I don't think you understand how many different skills are involved in building software that large companies can actually rely on.
Writing code is only one part of the job. I use Claude Code every day and I love it. It has made me much more productive. But I still have to guide it carefully, review every change, and fix the bugs and poor design decisions it introduces.
Personally, I'm looking forward to retirement. I expect there will be no shortage of consulting work helping companies clean up the AI-generated mess generated by inexperienced developers and overconfident middle manager with zero software development experience :)
It is possible because they hired the original author of Bun to do this.
It won't be possible to HIRE anyone doing this job confidently, they won't even know if they f*ked up.
I am not too worried anyway, one person with no context, with or without AI, can't do this job. Just like with all the AIs you have, giving you 10 millions, you still can't build a AAA game, it is that simple.
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
It's only 4% unsafe and most of it is single-line pointers that came from C++
> At the time of writing, about 4% of Bun's Rust code sits inside an unsafe block (~13,000 unsafe keywords across ~27,000 lines / ~780,000 lines), and 78% of those blocks are a single line — a pointer that came from C++, or one call into a C library.
I don't know much about Rust but I imagine this is safer than 100% 'unsafe' code in Zig or C++.
That’s a lot of unsafe. I worked in a project with 50k lines of rust. 9 lines were unsafe. Turned out one of those was a hairy bug. Now it’s 8 lines.
4% of 100k is 4k. 4k lines of unsafe rust is more likely to be unmanageable compared to 4k lines of zig or c dependency on a 100k line rust codebase.
Not sure if they have 100k or a million lines of code
I'm honestly surprised, almost disappointed, that Claude couldn't reduce this 4% to way less.
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.
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.
> No one would have entertained the idea of rewriting a project in Rust before this.
I largely agree with your comment, but is this sentence typo'd or something? "Rewrite it in Rust" happens so often that it's become a meme (and that was so before the rise of agentic coding).
Maybe you meant to say that nobody would have entertained the idea of rewriting this project in Rust?
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.
Exactly. AI opens up a massive development frontier of projects that were simply impossible before. It does differentiate though. In the old world most "software engineering" work had nothing to do with software engineering so being highly skilled, educated, and experienced in software engineering made very little difference in compensation, position, promotion, etc. "software engineer" isn't a real thing anyway. coding is a secretarial job. you have to move beyond the mindset that coding is doing something useful. it's not. it is a means to an end and now better means exist. if you want to be an engineer you have to think in terms of systems engineering and building systems that deliver defined externally testable capabilities. in a few more years the idea of reading and writing source code will seem as absurd as reading and writing asm seems today.
> 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.
Ha. You'll be surprised when you find out how much new problems were created in the code base precisely because the author's (not sure if it's still the right word here, they barely involved) lack of knowledge of Rust.
And no, since they don't know they don't know about it, there are no signs of fixes around these real issues. They had posted something about the unsafe usage, but lol most of the UBs are casually swept away (not even treated as unsoundness), if you actually look at the code and the summary.
As opposed to the known problems caused by using Zig?
Measurably yes. They claim that 128 problems from the zig version was fixed, so I grepped for two known categories of UBs and unsoundness unique to unsafe Rust and found 237.
So there were 128 known problems fixed and you've found 237 potential bugs that were greppable. And you think that's a regression?
Can't assume good faith in you at this point but I'll explain it.
- They've written two articles, one by claude doing the migration another by the human behind it, neither acknowledge these problems. Nor does the incorrect SAFETY comments in code.
- I only spent ten minutes and found two code patterns that are wrong with little exceptions. Also randomly checked a few samples and there was no exception. This basically means that failure patterns not explicitly picked and disallowed will repeat themselves over and over. Try imagine the more subtle ones hiding in this huge codebase.
- Trivial to find != Trivial to fix. 107 of the problems (one of the categories) are borrow issue and requires large refactoring (rearrange and rethink whole modules of code) to be removed completely.
So yes, huge regression by my standards. And I'm not questioning Rust the language. I'm questioning Claude, Jarred the person, their dev & marketing practice and the Bun project.
Btw these categories are separate from the (still unfixed) category of problems I mentioned 54 days ago in the comments before.
Our standards are different. I don't see any of that as a regression. You're pointing out potential problems that can be resolved, and specifically can be resolved because rust makes those problems grep'able.
From my perspective.
1. 128 known bugs were fixed.
2. 237 potential bugs were made grep'able.
That is a massive win to me.
> made grep'able
That's not the correct understanding. These are specifically the ones that were not bugs in Zig. They are forbidden in Rust because of reference invariants that don't even exist in Zig, so correct code are made incorrect during the port. That's what I meant by new problems were created and unique to unsafe Rust in my previous comments, if that wasn't clear enough.
Again I'm not sure if you are intentionally ignoring the context. Please clarify that.
> They are forbidden in Rust because of reference invariants that don't even exist in Zig, so correct code are made incorrect during the port.
I'm not sure that this is true - who says that the same invariants weren't broken on the Zig side? (Aliased pointers are UB either way, for example). Also, "unsafe invariant broken" does not strictly mean that there's a reachable bug. It should be cleaned up though, obviously. But in theory, callers may never actually trigger a bad invariant in an unsafe block.
Regardless, even assuming that these are genuinely new bugs, it doesn't change my point. Going from ~X known bugs to ~2X potential, grep'able bugs, is a win to me. Sounds like it isn't to you. Great.
> Again I'm not sure if you are intentionally ignoring the context. Please clarify that.
I'm obviously not intentionally ignoring anything, if you think I am then you can stop responding.
There wasn't a reply button on your latest reply so I'm posting here instead. Also because I now have more time to clarify what's exactly wrong about the claims.
> who says that the same invariants weren't broken on the Zig side
There are no such invariants in Zig.
> "unsafe invariant broken" does not strictly mean that there's a reachable bug.
Broken invariant literally means you are reaching it. The word you are looking for is "unsoundness".
> callers may never actually trigger a bad invariant in an unsafe block.
There's a neat class of UBs called "immediate UB"s. They can ruin the code just by being compiled, instead of reached at runtime. And guess what? They have a lot of these.
> potential, grep'able bugs
We are indeed going in circles but I have to ask: you still don't understand that? Grep works for violated lints, unsafe blocks and all things explicitly exist in the code. Not for unsoundness in safe functions that can be called incorrectly and ruin everything, can't be reasoned about by any existing tools. They also have thousands of those. It's unfair to say the unsoundness is freshly introduced by the port, but Rust also doesn't help in this way where no unsafety is encapsulated and calling anything can be a wild ride.
> There are no such invariants in Zig.
Zig does have invariants. It doesn't have an aliasing invariant like rust though, but it does have its own invariants, naturally. Zig is a memory unsafe language.
> Broken invariant literally means you are reaching it. The word you are looking for is "unsoundness".
A reachable bug means one that can be triggered. Undefined behavior does not mean a bug can be triggered.
> There's a neat class of UBs called "immediate UB"s. They can ruin the code just by being compiled, instead of reached at runtime. And guess what? They have a lot of these.
Can be, yes.
> Not for unsoundness in safe functions that can be called incorrectly and ruin everything, can't be reasoned about by any existing tools
This is only possible if unsafe is used. `unsafe` is grep'able, hence all memory safety bugs are grep'able. That's the whole point of rust.
> Zig does have invariants
Not these in particular. You are again ignoring the context.
> Undefined behavior does not mean a bug can be triggered.
Undefined behavior are bugs by themselves. Let's check if you are holding any of the wrong assumptions:
https://predr.ag/blog/falsehoods-programmers-believe-about-u...
> `unsafe` is grep'able, hence all memory safety bugs are grep'able.
Wrong implicit premise: "all memory safety bugs resides in unsafe functions/blocks".
No. Even assuming everything is done idiomatically, memory safety bugs can still originate from unsafe blocks and all the safe functions in the same module. So we want the module containing unsafe to be small and closed. Otoh with this code base unsafe lives in every module.
Making them encapsulated is the whole point of Rust, in this code nothing is encapsulated so no, they missed the whole point of it.
Aaand it's not like you can just remove the unsafe blocks one by one trivially. It's as hard as rewriting the codebase from ground up without reference (unlike the current migration) as every referenced object in the call graph needs to be reordered. Well partly because the original code sucks I assume.
> Not these in particular. You are again ignoring the context.
What context? I just said afterwards that aliasing is not one of those cases.
> Undefined behavior are bugs by themselves. Let's check if you are holding any of the wrong assumptions:
Nope and your post wouldn't justify the statement. Not all UB leads to a reachable bug. The blog post doesn't say otherwise, and in fact it indicates exactly this (that UB can compile "correctly" one day and "incorrectly" the next). Check the errata on the post.
> Wrong implicit premise: "all memory safety bugs resides in unsafe functions/blocks".
No, I'm right other than l-unsound. Saying "but safe code that references unsafe code" doesn't change that.
> It's as hard as rewriting the codebase from ground up without reference
Not necessarily. At least multiple cases I've seen in the rewrite would be a matter of just moving `unsafe` from one spot to another and then placing the assertions at the caller.
This conversation is increasingly dumb. I've made my point repeatedly - moving to Rust means memory unsafety violations can be grepped for and that's not up for debate. You can say that that's not sufficient as a win for the project, I really am ambivalent.
> increasingly dumb
That's untrue. It has already been maximally dumb since your first comment with the various logical fallacies you managed to carry out in a single sentence. The only reason I'm still making my replies is that you are making so many false claims that may mislead someone else.
https://doc.rust-lang.org/nomicon/working-with-unsafe.html
I'm not even trying to prove any point since the beginning. Can't do that when you have a different definition of bug from others.
Please if you are going to reply to this ever again try stop making any claims. Otherwise I'm afraid that it will continue into infinity.
Yes you are. Either that or you are too distracted to read or you wouldn't be repeating
> ~2X potential
at this point. That's what I've found in 10 minutes. And they are actual bugs that I've take extra time to (statistically) verify. Please worship me as the new machine god if you think I've found all the bugs with a glance.
And I'm not going to debunk each of your false claims, when you are doing that at the expense of appearing either dishonest or ignorant. I'm allergic to apologism.
Additionally I'd admit that I've intentionally avoided talking about the specifics of these problems, giving links to each of them or something. That's for a concrete reason - I can't bear it if Bun gets (even in the slightest bit) better because of my contribution. It would be one of the worst things I can do, morally.
> And they are actual bugs that I've take extra time to (statistically) verify.
I'm confused. You said that you've just grepped and found some undefined behavior. What do you mean that you've statistically verified them?
> And I'm not going to debunk each of your false claims, when you are doing that at the expense of appearing either dishonest or ignorant. I'm allergic to apologism.
My false claims? Like that pointer aliasing is undefined behavior in both languages? lol okay?
> Additionally I'd admit that I've intentionally avoided talking about the specifics of these problems, giving links to each of them or something. That's for a concrete reason - I can't bear it if Bun gets (even in the slightest bit) better because of my contribution. It would be one of the worst things I can do, morally.
I'm taking all of your claims at face value, I haven't said that you have to provide evidence of them. I'm not saying that your claims are false, I'm saying that I can grant them and still disagree with you.
I don't know what to tell you. Even if you said that those 2x bugs were 100% verified, I'd still say that this is a win because you can grep for these bugs now. That is obviously better to me.
Instead of "possible" undefined behaviors, potential bugs, the samples I've randomly picked are all actual undefined behaviors, real bugs. Hence statistically.
> pointer aliasing is undefined behavior in both languages
That included and also basically every other claim in that comment. I'd be happy to learn otherwise if you have concrete evidence.
[Edit: erased information that can help people find the bugs without prior knowledge]
> I haven't said that you have to provide evidence of them
Sure, but if I'm going to it would be a lot easier to convince everyone how bad it is (just like I did in private message groups). I can't take the risk that "everyone" also includes Jarred though.
> you can grep for these bugs now
You can grep for the greppable new bugs. I raised them as an argument because these issues are glaring. What about the ungreppable ones? More than half (again, randomly sampled) unsafe usage in the 10,413 unsafe blocks in current Bun looks iffy to me. I just haven't taken the time to verify them because many requires reasoning across the code base (see? the exact problem Rust ought to prevent). From a Rust point of view it's a huge failure.
All these while considering that the Bun agents (no people at this point I'm afraid) don't even know how to grep for the easy ones.
This is going in circles. I think my point has been made. You can grep for every memory safety violation in Rust, that is a win. Pointer aliasing is apparently not UB in Zig, that's cool, assuming that's what you are referring to - but I just can't stress enough how little this matters to my point.
Oh it's so nice of you when I've spent the bottom half of my comment explaining how you cannot grep for most of them in this BAD codebase.
Please READ. Including the one I've added at slightly higher layers of replies.
You can grep for every memory safety violation in rust.
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.
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...
[dead]
Every single SaaS app will be completely rewritten in the next couple years. Fair warning. If you aren't on that train you won't have a job.
You are missing the big picture here The AI literally was able to do a year's work of a top notch developer team in just 11 days (mainly because of a lot of human intervention, otherwise it would have been faster) Why do you think its cant or wont be able to replace the lead developer and/or designer's 11 day job !
and btw, if it can write code, it can write tests and test suite
Ai has come a long way, 2 years ago, this task would be impossible ! 1 year ago, it would hit a dead-end in the first hours of the execution
This blog post is nothing short of an amazing and fascinating tale, yet in some aspect very very scary ...
No I'm not missing anything. The existing specifications and tests provide a huge validation surface to work against for this kind of migration - they're the foundational pieces of the control loop. Without those two things, this kind of rewrite would not be possible.
We have known for decades that the hard part in programming isn't programming, it's making sure you have the right target! Bad designs and bad specifications have caused more bugs and broken software than anything else, and the time taken to develop the testing and validation suites (that is - the javascript spec tests) this rewrite used must be considered part of the engineering effort.
> and btw, if it can write code, it can write tests and test suite
You must be very early in your career. Again, the hard part is not writing the test, it's knowing which tests to write.
> You are missing the big picture here The AI literally was able to do a year's work of a top notch developer team in just 11 days (mainly because of a lot of human intervention, otherwise it would have been faster) Why do you think its cant or wont be able to replace the lead developer and/or designer's 11 day job !
It would help if you actually engaged at all with any of the points they just made. They were good points!
I am also very curious what the actual cost of this is, esp. if you are not an Anthropic employee and have to pay the API cost.
Getting tired of these comments trying to hype AI. All of us use AI, and if we don't, we have a reason. Chill.
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.
Not only that. I think most of us, including the author wouldn't have thought this was actually feasible.
Not only is the time and dollar spent lower than a lot of people expected. We could now foresee a lot of these human interaction, mistakes, time and cost could be further reduced by a factor of 2, 5 or even 10+ in the not far future.
Also worth taking into account what is stated in the blog post is also acting as PR piece for Claude and LLM in general.
This project is very well suited for AI. It's not clear to me if AI is nearly as good or cheap when building things that are new, where it doesn't have an existing target to match and doesn't have an existing test suite to bounce off of and has the benefit of being lead by an actual human with a very intimate understanding of the codebase.
I am seeing the complete opposite. 200k senior engineers can now do large scale projects way beyond what they could do just a year ago. My company is now able to implement stuff that we used to only dream about. Having 200k senior engineers who master AI coding is a true super power.
> 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.
Sure, if you're wasting money in silicon valley. They could have hired in Europe and got three people for $300k, which is only double what they spent.
I think the time is the really significant factor, not the money. I bet if they had the option of paying $300k to have it done by humans rather than AI, but magically in a week instead of a year, they would have gone for that instead. $300k is nothing to Anthropic.
Nah. You got it wrong. Don’t think too much of yourself, pal
If you already employed the engineers the extra cost would have been $0.
https://en.wikipedia.org/wiki/Opportunity_cost
Opportunity cost is not a real cost. No money leaves your bank account. It is a decision making tool, and treating it as an actual financial cost is a misuse of the idea.
It’s literally the price of lost opportunities. It’s not understood to be a financial cost. It’s exactly what it says on the tin. Lost opportunities may not be a financial cost, but they’re certainly a cost.
Opportunity cost isn't just a real cost. It's THE real cost.
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%.
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.
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.
I hope that you're going to call it PostGrust.
Na, PostPostgres would be much cooler.
Then you'll have postgrest on postgrust
I find it curious that people who take other's people product and rewrite in their favorite programming language still name their own creation the name of the original one.
Like, you have now created your own new database engine that happens to be compatible with Postgres. Wouldn't you take an absolute pride in giving it your own name? Why call it "Postgres rewrite in <programming language>"?
If they did the opposite and called it Mygres or whatever people would give them shit for that too.
Maybe not everyone is utterly obsessed with vanity and its delusion?
Then why use someone else's established brand for your toy project?
If this is still speaking about the Postgres rewrite in Rust, then naming it something like pgrust[1] makes sense for ease of discovery for anyone aware of these technologies.
[1] https://github.com/malisper/pgrust I guess
Would love to follow your journey!
If you want to follow along, I've been writing about it on my blog (https://malisper.me/) an you can follow the github repo here: https://github.com/malisper/pgrust
Bookmarked. I love ambitious projects like this. I'll check in!
> 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.
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.
I’ve been noticing that it will test hypotheses for evidence frequently. I really like that. With Opus I have to instruct it with a skill to build prototypes, but Fable will do it and do it really well by default. Really nice detail. I’m guessing it’s part of the system prompt, but the higher capability paired with this experimentation lean makes it far better at planning and verifying.
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.
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.
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.
Funny you mention ORMs, I'm building a project with bun, and just using raw bun sqlite until I feel the app gets too complicated and I need it. AIs are really damn good at SQL, I can just trust them with it, and it keeps the project much lighter. A few years ago this would just sound stupid, but here we are.
That's what I always did pre LLM, it was fine
The result of this will be that you end up at the highest level of abstraction.
Let me save you time and tell you that C# and it's ecosystem is where you'll be happy.
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.
A sophisticated rewrite? Sure. This was a naive like-for-like rewrite, though.
Wouldn't the same improvements have been made in zig if they instructed the agents to improve instead of rewrite?
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.
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".
Unfortunately (and I say this because I hate this whole rust rewrite) no. There is no fixing a third-party garbage collector on top of the non-memory-managed language. Jarred explains in a post what would that Zig look like.
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.
On the other side of the scale, this codebase started in Zig from 5 years ago while the Zig of today is still very much pre-1.0 - still in the middle of things like finishing up moving to a self hosted compiler. Things like binary size, performance, or some of the oddities around drift in the language (like the custom macros vs now built-in language features) in this rewrite are not really as bad as they'd seem if this was a port from a more complete language.
That said, I think the parts around wanting to properly have memory safety guarantees rather than try hard & patch as issues are found is a more serious concern for Zig as those speak more to the design goals than the current implementation. "better safety than C while maintaining C compatibility" may not be a very compelling reason to chose Zig if other languages are able to do that portion better anyways, even ones without a GC.
“better safety than Zig while losing compatibility with C” doesn’t seem as compelling a story to me.
No, you don't get it. Zig is a language about having _fun_. Not memory safety and all that crap. That's why unused variables are hardcoded as errors!
I hope Zig won't do a hostile reply to this blog post. But some thoughts on Zig's future where a lot of these problems could be fixed or migrated by better tooling and compiler checking.
But a lot of people have been saying this for sometime, Rust and LLM is a great match. A lot of friction of the language were smoothed out by LLM assisted programming.
Zig and Rust solve different problems, Bun got burned by its indiscipline, and Zig’s response was sadly to flood HN with “how to use Zig” articles
I don't want to say I knew it but it did happen. Slightly disappointed.
I hope this isn't the takeaway!
Zig was the right tool to start, Rust is the right tool to finish.
Making something possible and refining something until it is high security and reliability are different problems. Zig is great, but for a JS runtime, I just don't think that's the best long-term fit.
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
>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.
But how can it be a mechanical rewrite if the tool used isn't deterministic?
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
The article explicitly mentions the maintainability as a foremost concern.
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.
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].
[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...
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.
You're entitled to call things as you wish, of course, but your definition of "vibe-coding" differs quite a bit from mine.
500k lines in 11 days? With 8-hour working days that's 100 lines per minute. There's no way you're comprehensively reviewing code that quickly.
The code was generated by a LLM, and the output wasn't even read by its user. That's definitely vibe coding.
It's a direct translation without changing the overall code structure or data structures. I do think this process deserves a distinct name from blind whole-of-project vibe coding.
Translation does seem to be a strength of LLMs, and as they said in the post, the code at the function-level all still feels familiar to the team. They've also already moved users to the codebase without anyone noticing; that's a better result than typical vibe coding.
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.
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.
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.
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
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.
There clearly aren't catastrophic bugs. The question is whether the artifact is maintainable over time, since clearly there's a massive amount of net new code that was not thoroughly reviewed. Give it a year or so and we'll know. I claim either way, it doesn't really matter to Anthropic--if it's a disaster they might be able to keep it limping along well enough by just throwing tons of tokens at it. The value in this is not the lasting software artifact, it's the marketing of the rewrite. If over time it turns out to be a great success, all the better!
That vibe coded app is generating billions. Does the word "vibe coded" mean anything anymore?
> 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?
Claude code is buggy and they don't appear to be maintaining it just fine.
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.
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...
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
Last time I used it, it was a a flicker fest. Has it been fixed?
> 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.
> There’s no way in hell it’s maintainable
There are different definitions of "maintainable". It seems the prevailing culture at Anthropic is to not touch code manually anymore. So for them "maintainable" means the LLM can fix it.
I find Rust more readable than zig
you're not alone.
I would guess that people looking to use Zig understand that those are project concerns and not language concerns.
The stability gains are a direct language concern as mentioned throughout the article.
Judging from comments on this article: no.
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.
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.
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)?
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.
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.
From a PL Theory perspective, Zig is vibe-coded.
Not sure why people use it.
Pretty much everything except Haskell and the like can be considered as such.
That's because closely following PL theory isn't always the right goal for a language. Ergonomics and pragmatism are far more important.
I wouldn't disaree on the ergonomics: a powerful but unusable tool is... useless!
Though ignoring all the PL lessons for the sake of "pragmatism" is just plain ignorance.
Rust has a quite solid theory backing. Zig has nothing interesting really: it's "vibe coded" by someone who was doing game dev or something like that.
The scary thing is the zig project prohibits LLM contributions - the world is going to move faster than them.
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.
I would be mad if the syntax was constantly changing but I want the internal implementation to be moving as fast as possible while retaining success. I think that rate is higher than what humans alone can do.
That's a monkey's paw desire because nowhere is Hyrum's law more true than programming languages. Alternatively you just end up with something like C++ where no one understands the whole thing.
> 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.
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.
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
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.
Humans can't become 100x efficient cost wise. That's how cheap LLMs are.
Less money? Cost of living is much lower in EU
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).
> Why assume the upper level salary here?
Even a junior is going to cost you $200k by the time you're done paying payroll taxes, healthcare, etc.
Nonsense. Junior salaries are on the order of $50k in the UK. There's no healthcare to pay, but employer taxes and overheads might be around 30%, so you're talking way under $100k.
> 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.
> 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:
I did some more sizeable work with GLM 5.2 on Max reasoning (planning and implementing 8 features end to end) and it performed pretty well, but worse than Opus 4.8, with largely the same adversarial agent review loop.
Opus 4.8 still found some real issues afterwards and spent about an hour fixing things, before the code was good enough to ship. Overall promising, wrote about it here: https://blog.kronis.dev/blog/z-ai-s-glm-5-2-is-a-great-model...
The GLM Coding Plan seems to have lower token limits than the corresponding Anthropic Max subscriptions, but if you had to pay API rates for some LLM to do work somewhat reliably, it's a no brainer (unless you're swimming in money that you can give away and value your time more).
But not all models are equally capable, so I don't know your basis of comparison is even valid, let alone the numbers.
I think it'd take you at least eleven days to meaningfully coordinate 50 people!
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?
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...
$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].
Salary info: https://www.levels.fyi/companies/anthropic/salaries/software...
[0]The maths I used (posting because I'm tired and prone to mistakes):
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.
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.
Outsourcing to India would actually be the disaster the naysayers were saying this would be.
Have you seen the "rewrite by outsourcing to India" thing work?
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.
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.
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.
Many of the large enterprises we work for did move software engineering work from HCOL locations in Europe or the US to India, often with disastrous results.
On Teams, channels related to AI are flooded with daily support requests from supposed engineers from India who clearly are not competent enough to set up GitHub Copilot or properly report issues they encounter during the setup.
And don't get me started on the shared libraries some teams located in India work on. If the library I need to use is full of obvious bugs where I wonder how any competent engineer could have shipped this to production, and then I see that the work has been moved to India, how am I supposed to feel about this?
Do we really need to sugarcoat this?
India has amazing software engineers and less competent ones.
USA has amazing software engineers and less competent ones.
Europe has amazing software engineers and less competent ones.
etc
You get what you pay for, pay top end in India and they will be same as top end in Bay Area (and many in Bay Area/USA are migrants...)
"weird" is a euphemism.
It's very odd how quickly people fall back on emotional claims to attack this. Like we're engineers, if you can point at concrete problems with this rewrite I'd love to hear them. Obviously Jared is going to give the positive case, saying that he's doing that doesn't prove the rewrite is a bad idea. You need to point at objective problems, not your vague sense of unease. As it stands, by all available measures, this appears to have been a massive success, which is absolutely remarkable.
There were/are absolutely plenty of real problems with the resulting code pointed out. Running Miri trivially found soundness issues, `SAFETY` comments that demonstrate that the model in question fundamentally doesn't understand/simulate understanding how unsafe rust works [0], etc.
[0] https://github.com/oven-sh/bun/blob/fc865b398e51de8a95ddde4b...
These seem really easy to address. Any SAFETY comment that relies on the caller is something you can trivially find and fix.
First, we're talking about a massive rewrite of complex software project which no one has fully reviewed and which the people most familiar with the code base (the bun maintainers) aren't even qualified to do so. As such, the issues people have found are mostly surface level.
But second, you're right, this is an easy thing to search for (especially with LLMs). And yet, the example I linked has been there since may, surviving multiple rounds of review. From this, we can draw a few conclusions: 1) claude (including apparently mythos/fable) fundamentally doesn't "understand" how unsafe rust works, and 2) no one on the bun team is aware that they need to tell it to fix this (if they're even aware that this isn't allowed in the first place).
The reason such trivial defects in a codebase are a red flag isn't so much those specific issues themselves, it's what they reveal about the authors. If you find a lot of obvious defects in some code, it's very likely that there are also many more subtle harder to detect issues as well.
I think that's an interesting point that the models wrote SAFETY comments that are so obviously not what SAFETY comments are for. A SAFETY comment can never be about callers, that's the whole point of `unsafe`.
Look a few more till you find absolutely bs SAFETY comments marked on immediate UBs. They are everywhere.
Well the rewrite has newly introduced many immediate and critical safety (as in Rust sense) problems. It's clear and obvious if you read the code knowing the basic rules of unsafe Rust. And don't be surprised if it doesn't appear as obvious to you or Jarred or Claude, because not knowing they don't know is the exact reason why they failed at it.
And for the emotional aspect. I'm working as an R&D engineer and one of my recently assigned experiments is to evaluate replacing workers with LLMs, quality software with slops. Every bit of exaggeration they make is making my coworkers lose jobs and I'll be no exception. The entirety of me consists of reasons going against this kind of marketing compaign.
We also need to ask if the better is because of Rust, or just because the old was a mess and the language was good otherwise.
I don't think "better" really had to be proved. The same but aligned with your org strategy is perfectly acceptable given these sorts of technology choices are often driven by exogenous and wooly factors like licensing, your confidence in the future direction of the technology, or the ability to hire staff (or the ability for LLMs to work with the technology!)
Technology does not exist in a vacuum, nor does anything that is engineered. It's not this abstract stuff detached from the world.
PEOPLE make stuff, people use stuff, and people are ultimately the ones who are going to pick and choose which stuff gets made, used, adapted, enhanced, and carried into the future.
AI is an inherently anti-social, anti-human technology, and this rewrite is the perfect example of that.
Assessed from the perspective of "technology in a vacuum", of course. it's a success. He did the thing that transformed the thing from one kind of stuff to another kind of stuff. It still does all the things it did before, and in many cases with better stats than it did before.
Assessed from the human angle, and especially the angle of Bun as a community, I would bet money that this rewrite -- executed by nobody for nobody, built and maintained by machines, maintainable only by machines -- has killed the entire project.
Maintainable only by machines, because anybody with any knowledge, experience, or investment into Bun as a platform, or who contributed patches themselves, or whoever had a question about how it works and went "Hmm, I'm gonna go into the codebase and take a look at how that happens", they all got slapped in the face and summarily kicked out of the tent with the rewrite.
> AI is an inherently anti-social, anti-human technology, and this rewrite is the perfect example of that.
Not really. LLMs are a tool, and they do possess some interesting properties, but they are, in essence, a very surprising auto-complete.
No, what sucks is the AI companies marketing them as if they are The Holy Grail. And people are assuming that somehow LLM -> AGI -> ASI, even though there isn't really a causal link to be had, and acting like it's The Singularity.
I don't blame autocomplete for fucking up RAM, labor and god knows what else. I blame the idiots (at OpenAI and Anthropic) buying all RAM stocks and pretending this shit is any way good for anyone.
If you think like this - and you are most probably right IMO as well - then you should somehow share GP feelings, because LLMs are made by companies like OpenAI and Anthropic and Bun was bought by Anthropic and ported to Rust by Anthropic.
TBH in hindsight it seems that the Bun acquisition was also for the PR stunt they just did with the Rust porting.
I don't because I think the GP is blaming the tech, not the actual culprit - a bit like blaming the invention of fridges for people hiding the body. LLMs can be made and hosted independently of OpenAI and Anthropic.
> TBH in hindsight it seems that the Bun acquisition was also for the PR stunt they just did with the Rust porting.
The events went roughly like this:
- Anthropic used Bun. So they acquired it.
- Bun made some LLM derived patches for Zig. They were rejected due to Zig no-LLM stance.
- Bun couldn't get patches in, so they switched to Rust.
Was it a PR stunt, an attempt to pressure Zig maintainers into changing AI stance, or just doing the fastest thing possible? It's difficult to tell. I'm inclined to believe the last option.
As easy as it is to blame Bun for a PR stunt, it's also possible that you can't really associate with someone who rallies against your employer/owner.
> AI is an inherently anti-social, anti-human technology, and this rewrite is the perfect example of that.
This is a very weird issue to be mad about, and can be extended to multiple technologies - if you think about it, from computers to cellphones.
To add more context around lifetime errors and TigerBeetle's particular style guide:
>Many projects opt to answer these kinds of questions through a style guide. TigerBeetle's TigerStyle is an example in Zig and Google's 31,000 word C++ style guide is another. The challenge with style guides is enforcement.
TigerStyle[1] is a bit more than just a style guide. The key rule for this discussion, uplifted straight from of NASA[2], is *static memory allocation*: all memory is allocated in the startup phase, and there's absolutely zero `alloc`s afterwrads . This plus crash only[3] design means that we never call `free`.
This rule is self-enforcing and compositional, in Zig. There's no global memory allocator, so the code after startup simply hasn't the API to allocate. You can't circumvent this by accident. Of course, if the programmer is byzantine, they can stuff allocator in the global, or just directly `mmap` and `unmap` pages of memory, but, at our scale, we don't have problems with that. This is a similar in kind (not degree) to Rust, where untrusted code generally can circumvent safety guarantees, even without literally spelling `unsafe`.
And, naturally, never `free`ing goes a long way towards solving many memory errors by construction. Empirically, they just haven't been a problem for TigerBeetle. It's hard to untangle contribution of static allocation in particular from everything else we are doing, but it would make sense for it to play a leading role.
(As a footnote, we aren't actually do static allocation to avoid memory errors, we use it as a linter to check that every quantity has a known _logical_ static limit, the main property we care about)
[1]: https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/TI...
[2]: https://spinroot.com/gerard/pdf/P10.pdf
[3]: https://www.usenix.org/legacy/events/hotos03/tech/full_paper...
By all accounts, TigerBeetle has been a tremendous success, congratulations! My understanding is that it has a deliberately fixed scope, which makes me wonder: how applicable would TigerStyle be in more general-purpose applications? If the system needs to, say, ingest arbitrary JSON documents ranging from 100 bytes to 100 GB, how would TigerStyle fare?
What matklad said as a footnote deserves a little more attention!
A huge benefit is having to think and be explicit about the limits up front. To take your example of arbitrary sized JSON and flip it around: how would you do it normally?
Maybe, you'd allocate a buffer to hold your entire object when it comes in - but now you'll end up crashing when you get a large document that exceeds your available memory.
Maybe you can do things in a fixed amount of memory, using streaming or chunking - which would be pretty simple to turn to static allocation!
Static allocation forces understanding of those limits upfront.
Some thoughts on this here: https://matklad.github.io/2025/12/23/static-allocation-compi...
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.
> Zero involvement with the Bun community
Yeah. The human aspect of the transition was just incredibly bad. The person behind Bun has just demonstrated how much he values the community.
But I'm sure he will build another community around this rewrite. After all, there is an abundance of people cheering "Rust rewrites".
Until the new favorite language comes up.
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
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?
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.
Getting to an LTS release train of bun is probably a good idea, assuming they are still interested in external adoption rates. They shipped 1.0 a little under 3 years ago and the acquisition has had ~6 months to get settled. Looking at an LTS release would enable a lot of the more slower moving places to look at bun within being worried about getting caught up in the velocity.
I don't know it makes sense to try to make the an LTS version of where the Zig version left off, particularly if they know they are shipping a different solution & codebase to tackle the bulk of their security and memory bugs. Let this settle a few more months with the intent of releasing an LTS of it by the end of the year, if there really is demand for it. All of the benefits of having an LTS version like Java, Node, and .NET without needing to jump to a pre-port version of the codebase which was never targeted to be a good version to LTS in the first place.
A final Zig-based LTS would have made great sense if LTS releases had already been in the picture though.
> assuming they are still interested in external adoption rates.
If they are not it would be a good reason to move away from it.
So not just free work, but you expect Anthropic to pay to maintain a Zig version...?
I don’t follow how it would be in Anthropic’s interests to maintain an LTS version of Bun. It seems unlikely they’d use it, and it would cost them money (in the form of labor).
To my understanding, Java and .NET offer public LTSes because they’re financially buoyed by huge companies using those LTS versions, and Oracle and Microsoft are fundamentally selling that LTS support as a product. I have no idea why Node does, maybe it’s similar. But Bun’s position appears to be different than all three.
Are you asking for an LTS Zig version as a member of Anthropic?
> - No LTS support for the Zig version regarding CVEs etc.
Every release would have tons of CVEs and would take so much effort. E.g. the example from blog with memory issues. Better just think that Zig version was not there what comes to security. Use at your own risk.
> Jarred basically keeps operating as if he was a lone hacker working on his personal project.
They have right to do it, however. It is expected, especially if company owns it.
Of course he has the right to do it, no one disputes that. The users and community also have the right to complain, or stop using and supporting Bun because they don't like his actions
> One day it was "stop the drama I'm just playing with this" and a couple of days later "yolo merged to main".
Yeah, that was beyond ridiculous.
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.
> 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.
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.
I have a few opinions on this:
1) My (and possibly other people's) last impression of this was when it was merged just based on all tests passing. In many projects, relying just on tests would definitely be reckless (not sure about coverage/quality of Bun tests).
I didn't follow much what where they doing later, maybe it is indeed good enough. For example, Claude Code using it and being fine is reassuring.
2) Making such a big decision that quickly and not (even having the time to) consulting community doesn't really inspire confidence.
3) You can be reckless even if everything ends up being perfect in the end.
Going 80mph in a city, you probably have like 80% chance of not crashing. And if you don't crash, you just had a much faster and more fun trip. Doesn't mean it wasn't reckless.
> You can be reckless even if everything ends up being perfect in the end.
This. Something I expect any person who think they are "engineer" to understand without thinking.
this reminded me of WoW classics: Leeroy Jenkins
yolo!!!
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.
> 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.
I like using Odin with LLMs for this. it's a simple statically typed language with no GC and very fast compile
But then you have to deal with manual memory management. Not a bad thing, but it's the big win you get from GC languages and Rust.
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.
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.
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.
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.
"The blog post is expertly written. It's almost like the marketing department of a trillion dollar company has a lot of money riding on this article."
-- Andrew Kelley
https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...
Without accusing anyone of anything, I do think that this coming from the head of Zig, who gets a lot of negative publicity from the Bun rewrite (unjustifiably, it's a wonderful language) makes it harder for me to take this without wondering if there's some animosity that's really the main complaint.
> Two, I actually don't have any personal criticisms of Jarred
The author says two things that really popped out to me that you could say are "professional" and not "personal" criticisms, but I think they're still rude and contrast this statement.
> Jarred was already writing slop well before he had access to LLMs
> The grapevine was large and healthy and full of juicy grapes, and all those grapes contained the juice of the same message: Jarred was a stinky manager. Poor communication, unrealistic expectations, low empathy, no experience
Now, both of these may be true. I don't have any evidence though, so I don't know how to take it.
All this to say, I'll take both of these posts without a ton of salt when it comes to the non-technical parts.
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?
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…
It's extremely difficult to have a robust test suite for a TUI app like Claude Code. Hence regressions keep showing up in every update.
> But my guess is that maybe it doesn’t have as robust a test suite?
Not sure about what's going on over there, but over the last year Claude Code has gotten way better, I sure hope that they're working on a good enough test suite to avoid a crapload of regressions (and pave way for more refactoring, should they need it).
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.
> Historically, rewrites are a terrible idea.
This changed for me over the last 5 years.
The first scenario was joining a company where a software product barely worked. We did the traditional incremental refactoring / rewriting, but eventually learned how rotten the core was that rewriting from first principles was the best path forward.
The lesson learned here is that the conventional wisdom probably only applies to rewriting complex but working systems.
Then multiple scenarios in the agentic coding age. Between day jobs and hobbies I've reproduced major chunks of complicated software like Salesforce, Gmail, Pioneer Rekordbox with very lean teams.
Much like the blog post, the trick is to get an excellent verification loop with a compiler, linter, and test harness / test suite around the core behaviors.
It's feeling more and more that designing and implementing comprehensive test harnesses is the real work, once you have that let the LLM cook.
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.
I've always felt [0] the people who created Bun had, as their first and foremost goal, a desire to use Zig--and that's great, I like Zig, I like when people build things their own way.
However, I've been skeptical of using Bun, because I want a project whose first and foremost goal is to build good tools that achieve the objectives of the project.
It reminds me of asking game developers: Do you want to build a game, or do you want to build a game engine? Building a game engine is fine, but if you're goal is to make a game, then building an engine is a poor way of achieving your goals.
Likewise, I've wondered if the creators of Bun wanted to build better JavaScript tools, or if they wanted to use Zig.
[0]: https://news.ycombinator.com/item?id=35970044
So does that mean the rewrite made you less skeptical?
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.
"Make more money" in this case could also be "do high-profile rewrite for marketing reasons, silently abandon a year later".
I mean, surely the main motivation for "use an LLM to rewrite a huge project in a new language" was excitement about the shiny new tech that made it possible.
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.
> the assumption that the rewrite was happening with an Opus-like model, and not with Fable
I thought the same thing. Looking back, I was probably mislead in May when Jarred was explaining the pattern to "Rewrite every .zig file to .rs" as if it was something I could have done in May following his pattern. What he wasn't telling us was he was using pre-release Fable. [1]
A possible signal for next time is when we see an Anthropic owned company disabling the Claude Co-Authored-By trailer. [2] In an IPO year they have to take every chance to promote Claude unless it was something (Fable) that we weren't supposed to know about back in May.
[1]: https://xcancel.com/jarredsumner/status/2060050586024743376#...
[2]: https://github.com/oven-sh/bun/commit/23427dbc12fdcff30c23a9...
Silly assumption, Mythos was available at the time. Benefit of the doubt should've gone to Jarred.
>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.
Not a compiler expert - shouldn't language verbosity and binary size be, at best, very loosely related?
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.I'm not sure individual examples is the right way to go about this. A correlation isn't a guarantee for every instance and it's easy to concoct individual examples which tell any story you'd like them to.
To properly answer this you'd need to compare a large number of identical implementations written idiomatically in several languages and see if there is a correlation.
If I were to throw my 2 cents in I'd say "a very weak correlation" is probably right. Not because verbose languages HAVE to result in more bloated code but because it seems to me languages fine having a lot of bloat in the syntax also tend to be languages fine having a lot of bloat in the implementation or attracted to abstraction (which never does seem to actually compile away fully in large projects, even though it often largely does).
Sure, I did not think that one example is a full survey of all possibilities. I think that it's quite intuitive that this feels right:
> it seems to me languages fine having a lot of bloat in the syntax also tend to be languages fine having a lot of bloat in the implementation or attracted to abstraction
Which is why I chose an example of the exact opposite: a language not known for bloat, taking way more code to produce the exact same thing as one that's more succinct.
It's not as good as some sort of scientific survey of a wide variety of options, but if you can find examples in all directions, assuming there's no correlation until proven otherwise is a pretty solid bet, I think.
I'm not saying it's not as good as a scientific survey, I'm saying it results in no information at all about the strength of correlation one way or the other.
E.g. one could seek to find a 6' preteen and 6' adult to construct a counterexample to the idea height is in some way correlated with age. Doing so gives just as little evidence of what the strength of correlation is as seeking to find a 5'9" preteen and a 6' adult to show the correlation is positive or seeking to find a 6'1" preteen and a 6'0 adult to show the opposite. I.e. it doesn't follow one can filter the search as they please and then assert that's what the correlation of the unfiltered searches should be assumed to look like. In all 3 cases of positively correlated, negatively correlated, and not correlated we'd expect to be able to construct an example which says whatever we want to say - that isn't the same thing as sampling what the actual correlation usually is.
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.
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 :)
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.
It required a little bit of messing with optimisation settings and library generation in Rust, but they emit very very similar x86-64 assembly:
https://godbolt.org/z/89W4srz4d
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.
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.
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.
Passing by pointer (in C) reduced the difference a lot, but swapping the order of Add and Int in the Rust enum was enough to reduce the different to:
vs LBB0_3 and LBBO_2 were the same in both outputs (up to alpha renaming).Oddly, both sources seemed to be quite sensitive to match switch and enum reordering, resulting in very different generated code. Possibly something to look into further.
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.
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.
> 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.
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.
> There may be some prompting that can help
Sounds like a good time to tell Claude to create a system wide memory of how to implement lifetimes and borrowing and what to NEVER do.
Claude will then make the memory file. Usually memories help a lot. I see it think about it when it reasons through code.
Agree. But just because it feels the same doesn’t mean it compiles the same.
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 trust a lot more Rust code generated by an LLM than anything else ngl.
That can often depend on how you write it.
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.
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.
That goal doesn’t imply verbosity is necessary- just a style thing which is contrary to its goal of being a better C, given verbosity is the opposite of most C.
Performance alone doesn't always imply verbosity, but combining it with other goals—such as increased security and more power std APIs—often does.
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.
> Rust is (mostly) safer and more succinct than Zig while being dramatically less ergonomic
This is just your opinion.
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.
Abstraction doesn't necessarily lead to a smaller binary. Much of the bloat in modern software is indeed due to (bad) abstractions.
> 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.
I tried Bun for a weekend around Christmas 2024. I quickly hit a bug that would freeze the runtime (issue #13237) when piping a stream into a file. I found that this had been open since August 2024, scrapped the experiment and moved on. The issue is open to this day. If the GitHub comments can be trusted, this behavior even carries over to the Rust port.
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.
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.
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.
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.
That's the approach I've taken with a bunch of legacy OpenCL code I've mechnically translated to Metal, worked great.
Sounds to me like his choice of Zig was made in haste, as was his choice of Rust. If you find yourself changing a project's primary language more than once a decade (more like 15 years, but let's say a decade), the problem isn't the language but your technical decision process, and that's what you should look into first.
Some of the world's more important software - from browsers to the JVM - mix high-level languages with a GC and low-level languages, and it works not because of a style guide (even though one may exist). As someone working on the HotSpot JVM, I can say that it's done with a lot of thinking about constructing the right primitives that make this work well. Zig doesn't lack the features to construct the mechanisms required for getting good results in that domain, and Rust doesn't have features that could save you the thinking about such mechanisms.
I should add that in the 30 years I've been a professional software developer, I've worked on and advised many projects. They all ran into serious challenges at one point or another. Not of those projects that was held in high technical regard changed their language (except for things like JS -> TS or when the project planned to change languages, starting with one suitable for prototyping and expecting to switch if and when their workload grew).
All the ones that opted to switch language after less than a decade were those with serious shortcomings in their technical decision process, and those problems, unsurprisingly, persisted after the language change. After all, the very decision to switch so soon is an admittance that they'd made a very serious misjudgment, but these projects never properly debrief why they'd made such a big mistake and how they can avoid making one again.
likely you never were on a project that had tens of millions of users, you hit different classes of problems and you have to scale to new runtime or language often
(BTW, when I wrote "Not one of those projects ... changed their language", I meant after less than a decade, as a continuation to the previous comment)
First, technically respected products like the ones you describe either 1. plan or expect to switch in advance (e.g. they start with, say, Python/Ruby, expect that if they grow they'll switch to, say, Java) or 2. they improve their chosen language runtime (e.g. Facebook with PHP/Hack or Shopify with Ruby). Projects that switch a language without expecting to always show a pattern of bad decisions (clearly, if they thought their chosen language will carry them through growth and then they're convinced that it won't, that means that they don't know to judge languages' merits).
Second, this is clearly not the situation here, is it? There is absolutely no new information that Bun learnt in the past year that they didn't have five years ago, and certainly this has nothing to do with growing workloads on some service. They say they believe the language they have chosen lacks the features needed for the very core of the domain, which is dealing with JS objects. As someone working on the HotSpot JVM, I can tell you this is not true, but fine - that's what they believe. What could have taken them five years to come to that conclusion? Again, this happens to be a domain close to my own, only much simpler, and I seriously doubt they made some novel discoveries in the past year. And if it's taken them five years to acknowledge what they now think are fundamental limitations with the language they had chosen, how can they be so confident they've made a right choice now after a few weeks? It looks like they chose Zig on a whim and then chose Rust on a whim, and neither of these choices is the source of their problems and neither is the solution to them.
It would be prudent for you to do a little click through of someone’s profile before you make a comment like this next time
Putting on my machine learning PhD student hat, the way to do this was to leave 10% of the tests out as a ‘test’ set and then once the port was done, bring them back in and find out how good the port is. The port may genuinely be good but because they spent 100k of compute hill climbing the whole test suite, “the test suite passes” now provides far less evidence that the port is good. Its weird that at Anthropic, a very ML phd company, no one pointed this out.
Huh? This approach makes sense for non-deterministic problems. Not engineering problems that have deterministic end results.
I’d want to estimate P(a random test passes) where the existing suite of tests is taken to be sampled from a distribution.
> non-deterministic problems
I'm guessing you mean probabilistic? Nevertheless, you have an indeterministic variable here which is what the LLM generates.
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.
It's depressing seeing so little critical thinking despite clear and obvious incentives (Bun now being part of Anthropic) behind the reckless decisions that's been made here. Judging by this thread a well-formed article is all that's required for lots of people to just take everything at face value since it confirms the biases of what's currently fashionable.
I'm similarly distraught by comments like this. They are a staple, and they always fail their own standards. Critical thinking would lead me to believe that your judgement is heavily clouded, and that it is way more likely you're the one who's biased; either to find other people to be generally below you, or to find people being receptive to this effort any positively to be simply wrong. I'm even wondering if this is a stock comment of sorts.
Strong subjective judgements about an inexact but large sounding fraction of people, without any actual details, is a red flag the size of a skyscraper. And to top it all off, your conclusion is extremely convenient too: you're right, people are wrong, despite the blatant facts otherwise. Not exactly the hallmark of a particularly robust position, not for me anyways.
What specific critical thought(s) do you wish were voiced?
That this is a technological decision rather than rationalizations (e.g. fixing self-inflicted problems are now marketed as a rewrite win) that Rust is a better fit for an Anthropic-owned project.
Indeed as the developers behind Bun, it would be rather difficult for them to not be the originators of the bugs that they have now fixed with this.
Why is your unsupported speculation about the guy (or the people above him) supposedly deciding that "Rust being a better fit for an Anthrophic-owned project" a critical insight exactly? You not being convinced by the rationale presented does not mean he himself wasn't. Do you imagine critical thinking as just coming up with and preferring (to you) plausible-sounding alternative explanations?
Because respectfully, that's very much not how I understand the word, and I'd hope most people do not either. Maybe that's the issue. Post-hoc rationalization being a rather shaky gate with people (and AI) anyways.
Worse still, neither of the options you present are trustworthy summaries necessarily in the first place. From the blogpost:
> What if, instead, I spend a week testing if Anthropic's new model can rewrite Bun in Rust?
That sounds to me like something of an excited but cautious dare, not an arbitrary technological decision, nor some hyper-strictly rationale-supported one. It's the same kind of exploratory excitement anyone who used these things at all would be familiar with: you have an unlikely project idea, with some contentious details that are fair (see their blogpost), and some that would be simply annoying to justify (see your comment). Buuuut you also have heaps of corpo money, a lingering suspicion and interest, and AI tokens to burn. And so "fuck it, we ball". Not much to believe on it when it's a shared experience. And it's not because of just having read so somewhere, despite your assertions otherwise.
I just glanced at it, but in "Rust supports cross-language link-time optimization between C/C++ and Rust" it's not Rust but LLVM.
Any languages with LLVM backends get cross-language LTO for free.
Have they ever tried Zig Bun with LTO?
> around $165,000 at API pricing
This is the bit I was really curious about. Definitely not something within reach for us mortals.
On the bright side, that price would continue to drop rapidly even if the models themselves never improved anymore. I'd be very surprised if we didn't actually end up with ~100x cost reduction of this task in the next 10 years between hardware improvements, model perf/$ improvements, and commoditization/conpetition.
For now though it is a bit disappointing trying something like this is relegated to project proposals at work rather than my personal hacking.
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.
For Bun to not have torched its reputation among its users, it would have had to publish this blog post _before_ pressing merge on that PR.
That's what underlies most of the vitriolic reaction to the events, it was done really in a really rash way.
All they had to do was a)not gaslight people about your intentions when they found the branch b)publicly post the intent to do this, and then c)publish a doc like this one right before merging, ideally leaving the branch open for like a week in case anyone in the "community" finds things to fix.
Then those UB/Miri issues others found would have been "yay collaboration" boosts instead of negative issues that prove that the approach was risky/unthoughtful.
If you're going to cross a rubicon, maybe tell people a)that you actually want to do it, b)why you want to do it and c)what it looks like after you've done the rewrite.
It seems that Deno made the right decision by choosing Rust from the get-go.
Deno started in Go, but was rewritten in Rust before 0.1
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.
> 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.
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.
(1) The original zig code was probably heavily AI coded with lower quality, hence the bag. There is a chance that a full rewrite in zig might do as well but we will never find out.
(2) The rewrite itself is a massively successful marketing move. It shows what Claude code can do and how little it costs compared to human engineering. But the question remains whether someone else, not knowing zig, rust, and TypeScript can pull this off.
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.
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.
> 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.
I am a bit suspicious about the choice of startup time as the metric to evaluate performance in Claude Code. With a rewrite from a language like Zig to Rust, my biggest performance concern would be allocation. Where a Zig app might use a fast linear or buddy allocator, a Rust app is more likely to use malloc. During startup, both versions are likely to make tons of allocations. In fact, the Zig version is likely to make larger allocations during startup to reserve memory for its custom allocators. So I would expect both versions to be roughly on par, or Zig slightly worse there. However, during normal execution, I would expect the Zig version to be potentially faster, because it has paid the cost of malloc at startup and now an allocation might be as fast as incrementing an integer. This is speculation, but I would like to see performance numbers for the rest of the app lifecycle.
Those were in the article https://bun.com/blog/bun-in-rust#2-5-faster
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.
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
It's partly a problem because the narrative is still "rewrote Bun in Rust in 11 days". And they didn't do that, if you consider quality of code. And now people look and see "look what you can do with an LLM in 11 days"
what about new bugs introduced after the rewrite?
Got a reference to something specific? Per the blog post the overall quality, speed and size all improved. And multiple users have corroborated.
Like have you run into a specific bug or seen a regression - that's the cause of your reaction?
> 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.
Engineers are pretty jaded about plans expressed by authority, especially when there are obvious pressures opposing those plans. Yearly planning doesn't matter when a reorg will change the trajectory by Q3. Sprint planning doesn't matter when you know a fire will hit before then and you won't be given enough time budget to fix it well enough for that not to happen again next sprint. Project planning doesn't matter when the whole point is masturbatory spreadsheet production before you've actually taken a dive into the hairier details and figured out what's possible and what's necessary. That barely working demo strapped on top of a non-existent backend they swore would never become production? Congratulations, you have two weeks to build the next fake demo on top of it, but the base has to actually work now.
Maybe Jared just broadcasted uncertainty and was wrong, but given his position he's not being given the normal grace you might extend to an engineer you trust.
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.
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.
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.
> 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.
The way this trend is going we might need "rewritten in Rust" catalog similar to Google's graveyard.
Any chance for 1.3.15 with top bugfixes for those of us who once trusted Bun and are stuck on it in production? I have migrated almost everything out of Bun by this point but I have one single project that builds into executables with Bun and relies heavily on Bun's SQLite.
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.
The condition that made this possible is that this task is well within frontier LLM capability and he had tokens to burn. Domain knowledge is separate to language semantics.
"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.
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.
> Where is the cost breakdown?
From the article
> Pre-merge, this took 5.9 billion uncached input tokens, 690 million output tokens, and 72 billion cached input token reads — around $165,000 at API pricing
> It's hard to believe that there have been no problems/downsides since the port.
A significant portion of the article was dedicated to the 19 regressions they've found. Starting here: https://bun.com/blog/bun-in-rust#porting-mistakes
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.
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?
To me this whole saga stands on a very thin overlapping region between "it has merit" and "I hate it". Like, the blog post clearly explains the merits and they are strong. At the same time, I absolutely hate how the author handled the whole rewrite, including throwing the whole community out the window along with all their contributions and human love.
I got curious and had a look at some of the code (>1m .rs). I was surprised to see code for a S3 client in there?
I clearly don't get the value proposition of bun? And even if I accept that you want to bundle your run time, package manager, test runner and bundler, why do you want to include things like a custom S3 client?
In a world without AI/LLMs/agents the rewrite would have been major news how much better software gets when ported to Rust.
Until this bug is fixed, there's no trusting Bun
This is also not a memory issue but an actual logic issue, so Rust doesn't help there.
https://github.com/oven-sh/bun/issues/14144
> Compiler errors are a better feedback loop than a style guide
So essentially this whole re-write was about making Bun LLM compatible.
This post was clearly an important marketing effort from Anthropic and Jarred. Those interactive demos alone would take serious effort from a seasoned frontend engineer, AI-assisted or not. Pretty sure multiple devs were working on this post.
I wonder how much the authors now understand their project? Like, if they were given a bug, would they be able to intuit a possible location in their files that might be causing it? Or are they now essentially locked in to using LLMs to write/rewrite their code?
> how much the authors now understand their project
I don't think this is a value anymore for them.
What does it say that it took 2 months to write the blog post? (or at least have it published)
He's been teasing this blog post everywhere (in commit messages, multiple times on X, here on NH [1]) so I wonder how much of it was building hype compared with it legitimately taking two months to write.
I wonder if the delay of Fable has also been a factor and maybe they didn't want to release this blog post while they couldn't allow customers to use Fable and waste the advertising opportunity.
[1]: https://news.ycombinator.com/item?id=48133519
That a human wrote it?
It took TypeScript team 1 year to port the code to Go, but if Claude Fable was available back then, would they better use it to port the code in 1 week instead?
This makes me sad :( I've always really liked Zig, and Bun was pretty much the only big thing I could point at and say "that was done in Zig"
Electrobun is still zig and doubling down on it
TigerBeetle has you covered then.
ghostty is a zig project too!
> Bun was acquired by Anthropic in December 2025
Great for the Bun creators, but now we will have major runtimes that are optimised to work with one companies models...
> 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?
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.
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?
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.
(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.
> 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.
use Node or Deno.
if you want superior developer experience - Deno.
if you want stability over everything - Node.
> I asked Claude to loop the workflow on all 1,448 .zig files, and about 2 minutes in, one Claude ran git stash before committing. Another ran git stash pop. And then git reset HEAD --hard. They were stepping on each other!
I hate how easy git makes it for llms to catastrophically fuck up repos
> And if I put each Claude into a separate worktree, I would run out of disk space because Bun's git repository is too big and eventually the changes will need to be compiled and seen together.
This seems like a stupidly easy problem to fix.
> So, I asked Claude to edit the workflow to instruct Claude to never run git stash or git reset or any git command that doesn't commit a specific file at once. No cargo either. No slow commands at all.
What's the right way to fix this? I have a Pi extension that blocks any use of the word 'git' with 'stash/checkout/reset/restore' in commands which is a very large hammer approach. Is there a way I can allow a subset of git use in a nicer way without the less nice commands?
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.
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.
We need to coin a new term for the paranoic feeling that every text on the internet is written by LLMs.
I propose GPTSD (GPT + PTSD)
EDIT: Another one, AIdar (like gaydar but for AI text). EDIT2: GPTSD has prior art (literally) https://ryanthompson.name/project-gptsd.html
> that this blog was so clearly written by LLM's is offputting for some reason
It doesn't read at all AI-generated to me. What section do you think is?
(Pangram is very good at distinguishing between AI-generated and human text, and assigns a very low score to the article: https://www.salahadawi.com/hacker-news-ai-detector/rewriting...)
> Contrary to the amount of times "But honestly" or "genuinely" is mentioned, nothing about having your LLM speak for you feels honest or genuine.
"Honestly" is used once in that post, in a way that's pretty much the core, self-deprecating human use for it ("It would have been possible to do X, but honestly I didn't want to"), rather than the filler word use-case.
"Genuinely" is not used at all.
> I know it's not cool to leave responses like this, but I'm really tired of all of this at this point.
I think it is cool to flag AI-generated slop and either leave a comment or upvote an existing comment about it being slop. But only if you are sure it's AI-generated. And sorry to say, you don't seem very well calibrated on this. If you can't actually tell the difference and back up your opinion but are just guessing, then it indeed isn't cool.
The article is very clearly human written. The author discussed on twitter that he used Claude for visualization and feedback. You can simply say you don't like the writing style, but it is not a very useful comment to have written in any case.
> Pangram is very good at distinguishing between AI-generated and human text
It's not.
An extremely interesting blog post for me on a few fronts:
I'm very glad to see a holidtic approach to the memory errors and segfaults. I was tinkering on a static webpage just this this weekend, using Bun as the transpiler+bundler since it's so turnkey, and I ran into a few segfaults. E.g. when Bun saw I used an empty data uri for the favicon (avoids the browser trying to ask for one) it'd just crash. It reminded me of my own tinkering with Zig in its current pre-release state where it's usually a good mix of my poor memory management and working around bugs in Zig itself.
This post is also the best ad for AI I've seen yet. Not just comments saying they have 10xed themselves, a small personal project or thing which can (and likely will) be abandoned next month, or a one off dump of unusable code for the world's buggiest C compiler (come on Anthropic?). Instead this is a well thought out way of leveraging LLMs to do something which would otherwise probably not be deemed a reasonable enough effort.
I'm glad they included the rough cost as well. Crazy high, more than I can afford to be throwing at the wall to see what sticks, but still low enough to make sense over trying to hire developers for (even ignoring the timeline).
But it also highlights 2 really key things about current LLMs: the scaffolding can be just as valuable as the model & they still need someone able to figure out the right way to instruct and orchestrate them. Without the scaffolding the current models could never get close to handling something of this scale & quality. With the scaffolding you could probably get this to work okay enough even with a weaker model. On the orchestration side, Claude could help answer what good porting practices would be but it doesn't just get there itself, it requires hours of someone who understands the context of the project from bottom up and a clear understanding of what will/won't work to get the right scaffolding to do the job well.
Finally, it was an interesting dichotomy on presenting the port. On one hand it has been a bit opaque up until now. People saw the repo and there were some comments about testing the waters but then it suddenly shipped into production. On one hand that's awesome and I'm sure the reception here would be very different if there wasn't the "it's already been boringly shipped in Claude Code" shining result. On the other... I think I'll stick to using Bun as a personal tinkering tool for now. The velocity is so high I'm just not sure it'll land in a place I can rely on it st the speed of my org. Of course, that velocity is what has made Bun's success story and they should probably continue with it - I'm just looking forward to an LTS release :).
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.
> 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.
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.
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?
Not the author but I also moved from C# to Rust. In the first place I did not consider Rust for C# works like REST API but after I proficient with Rust I no longer want to work with C# for the following reasons:
1. Microsoft don't want to open source .NET Core debugger. 2. I tired of keeping upgrade .NET on my projects. 3. Result type in Rust make me more productive than exception in .NET. 4. async/await in Rust is lightweight and a better than .NET. 5. Thread-safety in Rust is a compiler error instead of figure out by checking the docs if type is thread-safe. 6. Community libraries in Rust has a great quality and docs.
Only thing I am not a fan of with Rust is how insanely massive a debug output build folder can get (tens of GBs) and if you have enough Rust projects it can eat away a ton of storage.
This was purely a hobby project I wanted to test the limits of Claude and see how quickly it could do such a change. It was surprisingly very stable I still found bugs but was able to resolve them within a small time window. For additional context I didnt use Fable as only Opus was available to me.
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.
Bay Area salaries are well-known to be extremely inflated.
Have European engineers do it for $100k or Asian engineers do it for $50k and the math is already looking a lot sketchier.
More gets done in the Bay Area than those places.
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.
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).
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?
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[flagged]
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.
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
fixed it
This slop rewrite introduced new vulnerabilities and regressions.
Care to elaborate?
> C++ instead of Zig would be a reasonable choice for Bun. We would get constructors & destructors. We could delete lots of extern "C" wrapper code.
> But, we would still be reliant on style guides enforced through code review, and even with ASAN, memory corruption and memory leaks would still happen.
Tell me you didn't even look at C++ without telling me you didn't even look at C++. I don't understand this at all, what's missing? There's clang-format, clang-tidy, cppcheck and so many others, what is missing exactly? Memory safety? Then why bring up C++ and style guides(?) at all?
Not replying directly to OP, just to people who never coded in C++.
Clang-format doesn’t save you from all C++ footguns, e.g. using exceptions, macros or templates in the wrong way where „wrong“ is defined by a fuzzy set of rules that requires a lot of experience and vigilance to enforce.
Rust is the clear winner of LLM era. You can't say otherwise.
This is just a hit piece and it's embarrassing to post it on your project's website. Could've been a tweet.
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
Because the author isn't employed by a transpiler company.
The entire point is to get people to spend money on LLMs. Writing a transpiler - even a LLM-coded one - pretty much defeats the purpose.
This is a frequently mentioned criticism. Is there a good argument about why that approach could have been done in the same amount of time? Seems like larger scope and more uncertainty to me.
>Is there a good argument about why that approach could have been done in the same amount of time?
as I said because it's a much smaller codebase. This is a million lines of code project. A literal Zig to Rust translation that is mostly syntactic is not going to be more than 10-20k LOC for a transpiler. That's two orders of magnitude less work.
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
> I was hoping it’d end in a “so how much did this cost?” so that others team looking at similar migrations have an estimate on what they can expect
It was in the middle. $165k.
It's right there under "Stats":
> 11 days (May 3 → merged May 14) · 6,778 commits
> Pre-merge, this took 5.9 billion uncached input tokens, 690 million output tokens, and 72 billion cached input token reads — around $165,000 at API pricing. By hand, I think this would've taken 3 engineers with full context on the codebase about a year, during which time we wouldn't be able to improve Node.js compatibility, fix bugs, fix security issues or implement new features. We never would've done that. The realistic alternative was to do nothing and keep fixing the bugs at the top of this post forever.
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?
The thing you have to remember with that $165k spend on tokens is that token prices are going to keep rising, and models may not get much better. I wouldn't be surprised if doing this same migration in 6 months time would end up costing $250k+
For sota perhaps but not convinced token price will shoot up if capability is held steady
do you think price per task completed will rise as well?
Isn't that equivalent? The task here was port Bun from Zig to Rust. He's saying that task will cost more.
That's not the direction of LLM progress these past 2 years. Cost has always decreased per unit intelligence. Open weight models with lower parameters beat gpt4 that we were so impressed by.
As expected [0] [1], this was a clear advertisement / marketing opportunity of Anthropic's Fable model on rewriting Bun (which powers Claude Code) from Zig into Rust.
Something that would have taken hundreds of developers now took 1 developer with Fable.
Now Claude, rewrite Claude Code from TypeScript to Rust. Make absolutely zero mistakes.
[0] https://news.ycombinator.com/item?id=48073893
[1] https://news.ycombinator.com/item?id=48240829
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.
> EDIT: the parent has effectively deleted their original comment
Not really and we both know that is not true.
The last line of the comment was the joke. [0] It is clear that you didn't get it and many others did. That is OK.
Heavens forbid anyone here is allowed to make any jokes on this site.
[0] https://news.ycombinator.com/item?id=48839063
[flagged]
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.
[flagged]
Jokes require mutual context. You failed to create a joke because you did not ensure the prerequisites were met.
> 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: ???
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.
> 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.
[0] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Everyone is calm. Many are just tired of you not taking a hint.
Except for those who did not get the joke and felt offended / embarrassed that they didn't and it shows in their replies to me.
It is not my fault if two people missed the joke and that is OK.
Its not even that, its one of the most overdone jokes as your link suggests.
In your "opinion". So are you going to stop people from making "overdone" jokes on this site or others using variations of it from now on? Or is it only mine?
My link suggests that is it just a joke and it is fine if you do not get it.
Nobody is actually stopping you, It's okay to receive feedback it didn't go over well though. You're welcome to like that or not just as everyone else is welcome to see it as a well made joke or not.
Pulling off humor is possible on HN if you really want to, just not usually by making the same joke the article already chided or blaming others for not seeing it as a joke. Humor is also usually better received here if it leans towards the explicitly obvious side (e.g. quotes, a laugh expression, a /s, or the like) or ties into a following seriously stated point in a way that is still meaningful without the joke. These kinds of things don't always need to be done all of the time, but it helps greatly since the default assumption starts as a serious post.
All of that aside, sometimes you can very obviously crack a real roller and have it downvoted or the discussion steered back to a serious one about the post. That's okay too, it's intentional the site isn't humor first and it's not reasonable to blame a reader for seeing it as such.
1 Developer with a 200k budget for tools.
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.
> 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.
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.
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”.
It states $165k in the article