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.
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.
> There are a lot of ways to do a terrible job of this. For example, prompting Claude "Rewrite Bun in Rust. Don't make any mistakes." and then praying it would work is not what I did.
It's not so much that I missed that it was a joke, I just don't think that it really added to the discussion.
What you've edited it to is a much better comment.
I just haven’t found another language that just makes sense. Zig doesn’t hide anything from you
It seems the reports of Bun's death have been greatly exaggerated.
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
He makes it sound like Claude did a fantastic Rust rewrite, and "the work continues."
But when the Rust port merged to main, the state of the code was very, very bad. There were 13,000 instances of `unsafe`, no Miri tests at all, and, sure enough, it exposed UB in safe Rust. https://github.com/oven-sh/bun/issues/30719
Observers could see this coming from a mile away, objected strongly to using AI to RIIR before the code merged. Rather than incorporate feedback and get the code ready for production, Jarred gaslit us all, right here on HN. https://news.ycombinator.com/item?id=48019226
Just 9 days before he merged the Rust rewrite to the main branch, Jarred wrote:
> This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.
It's plausible that Bun's Rust rewrite is now in much better shape than it was in May. But a blog post like this would have been a place to apologize, to accept that it was a very bumpy rollout, to acknowledge that public messaging was extremely poor, and to earn back our trust.
As it stands, I guess I'll have to run my own tests to try to evaluate whether Bun 1.4 is ready for prime time, because I just can't trust Jarred to give us a straight answer.
I think Rust is a locally optimal target for LLM coding, we might see a better language in the future, but I think Rust will dominate for quite some time.
Faster iteration, maybe? Rust's safety guarantee isn't exactly free (while still being very excellent) and does affect iteration time. I have a private project (>300K LoC) that has been translated from Python to TypeScript and the reason we couldn't use Rust was definitely the iteration time.
What costs rust in iteration time in my opinion is the low level (by default) nature of it. There's a faster-to-iterate language that has yet to be created which is rust but we sacrifice performance (and memory fiddling ergonomics for the odd person who does that) so we don't have to worry about things like whether a variable is stack or heap allocated. Which is in the direction of a GCed language but retains the mutable-xor-aliasable semantics.
Between rust and current GCed languages though... I guess I agree with "maybe" in both directions.
It's really the only systems language in its exact niche.
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 in my opinion feels the same.
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.
I think that when you have a $165,000 hammer, all of your problems begin to look a lot like nails.
Is it worth $165K? I'm less sure of that but it's honestly a moot point - this will get to 5 then 4 digits of cost pretty fast.
However, an open-sourced tool like that would've greatly harmed the Zig ecosystem and community.
People looking to abandon the ship first chance are unlikely to contribute much to the ecosystem and community.
So essentially this whole re-write was about making Bun LLM compatible.
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 will be a lot more excited when this is possible with <10k of api costs.
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.
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.
[1] For example, as a random sample, https://github.com/oven-sh/bun/blob/bun-v1.3.14/src/css/medi... -> https://github.com/oven-sh/bun/blob/4924862cffbf671792d47c92...
> I rewrote Bun in Rust using about 50 dynamic workflows in Claude Code run continuously over the course of 11 days.
> Excluding comments, Bun is 535,496 lines of Zig.
> How do you review a PR with +1 million lines added? How do you start to build the confidence needed to responsibly merge large quantities of LLM-authored code? A language-independent test suite with a million assertions, adversarial code review and when something does go wrong, fixing the process that generates the code instead of hand-fixing the code.
That’s vibe coding. This blog post is an ad for Claude, nothing more.
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.
Not sure why people use it.
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.
God forbid an engineer express uncertainty.
Based on that, the bun rewrite messaging was fairly misleading.
Either they estimated poorly, or it ended up the lesser portion of their estimate after all. After all, unless the estimate is 100%, there's always a chance it'll fall into the other portion.
I 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.
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.
#[derive(Copy, Clone)]
enum Expr {
Int(i32),
Add(i32, i32),
Neg(i32),
}
fn eval(expr: Expr) -> i32 {
match expr {
Expr::Int(x) => x,
Expr::Add(a, b) => a + b,
Expr::Neg(x) => -x,
}
}
#include <stdint.h>
typedef enum {
EXPR_INT,
EXPR_ADD,
EXPR_NEG,
} ExprTag;
typedef struct {
ExprTag tag;
union {
struct {
int32_t value;
} Int;
struct {
int32_t left;
int32_t right;
} Add;
struct {
int32_t value;
} Neg;
};
} Expr;
int32_t eval(Expr expr) {
switch (expr.tag) {
case EXPR_INT:
return expr.Int.value;
case EXPR_ADD:
return expr.Add.left + expr.Add.right;
case EXPR_NEG:
return -expr.Neg.value;
}
__builtin_unreachable();
}
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 :)
minimaxir•2h ago