Drilling into the original article where Jarred explained the reasoning behind the change, It's pretty clear that under zig the team was doing things by hand that are automatic in rust.
Humans and agents share one thing: they are both non-deterministic. He talks about the issue of tracking memory lifecycles manually in zig so it can be explicitly freed. As expected, this leads to a long list of bugs where people missed things.
Rust does this automatically. It removes an entire class of errors from his backlog. From an engineering management perspective, this looks like a pretty good trade.
The bonus here is that compiler errors are exactly the kind of deterministic guardrail you need to put around coding agents. Claude works really well if you give it a way to test for correctness and "make it compile" is a pretty good target.
There's a general version of this: the artifact you expose plus the test you run on it. Deterministic tests turn stochastic output into a hard guarantee. Wrote it up here if useful: https://michael.roth.rocks/blog/verification-surface/
Zig (like C) is simply not a good language to use if you're going to do many small allocations with uncorrelated lifetimes. To write robust Zig (or C) code, you must manage lifetimes yourself, for example by grouping allocations on an arena or by having fixed buffers of "things".
You can just do that, and then Zig is really no less robust than Rust. But if you want to do "managed language" style allocation patterns (like what llms generally prefer), it doesn't make sense to use it.
Grouped and arena allocations work really well in Zig. For awhile, we tried to use this pattern almost everywhere in Bun but it gets really tricky when there’s some GC-managed memory and you want to free things incrementally to reduce RSS. Also, using arenas for arrays that grow wastes memory a lot since it keeps every previous version around (mimalloc arenas are slightly better for this)
Grouped allocations works especially well in parsers & ASTs where the lifetime is very bounded. Since the Rust rewrite, we still use arenas for Bun’s parsers and the bundler but not a ton elsewhere.
Zig is intended to be as robust as it can be as long as it doesn’t implicitly add code (no destructors that run code you didn’t explicitly call), or increase compiler complexity and compilation time.
I don’t think it makes sense to say Zig is or isn’t intended to be robust in general. Like, we don’t say Rust isn’t robust since it doesn’t add dependent types and general purpose static verification that can do more general proofs. It’s focused on eliminating one class of memory bugs in particular, exactly the class of bugs that are the biggest challenge for software like Bun, and other software with complex lifetimes (it originated from Mozilla and Rust is perfect for browsers)
Zig is intended to be robust for software like TigerBeetle, or the Zig compiler itself, where memory lifetimes are simple.
I’d say the focus on built in tests, fuzzing, debug memory allocators and safe mode shows that Zig is absolutely intended to be robust, within the scope of what the language aims to be. Far more than C itself or most of its popular compilers ever did.
A casual read of TigerBeetle's practices makes it clear they're doing some very unusual things, both in their memory allocation strategy and in their testing/verification.
Despite TigerBeetle being one of the highest-profile remaining Zig projects, I actually don't think they're representative of the average Zig project at all.
It is quite representative of an embedded software project. TigerBeetle is not what we usually call embedded software, but it is built like it: static memory allocation, a self-contained executable, and a strong focus on determinism are typical in that field, especially for critical software.
And I think embedded software is a field where Zig will be at its best. The only thing it is missing is maturity. When project lifetimes are measured in decades and changing a single byte can cost millions, no one in his right mind will pick a language that is still in development. Things will become interesting when it reaches 1.0.
All necessary memory is allocated at initialization. The application is not allowed any allocations during it's normal runtime. This is how it avoid memory bugs.
Static memory allocation is widely used in quite a bit of embedded software, particularly safety critical stuff. There it's often latency related since you don't want hangs while memory is allocated.
I've even seen it on some simulation software's core that was written in the 80s originally; at the time memory was much more constrained so allocating upfront meant you could check upfront whether the simulation could actually run or not vs crashing out part way through.
I was just learning yesterday that's exactly what GTA did on PS2, which I thought was interesting. (Not to belittle your point, just giving an example)
I do this in Unity because allocations/GC cause hitches.
it's pretty normal thing to do there's even the built in pooling libraries so you can pre-allocate 10,000 gameobjects when the game starts.
I haven't played with ECS/DOTS yet but I assume it does something similar.
I do. The only thing I need dynamic allocations for is queues of asynchronous events, and that's just because I'm too lazy to calculate an upper bound for how many there may be.
> Like, we don’t say Rust isn’t robust since it doesn’t add dependent types and general purpose static verification that can do more general proofs.
Give it a few years! I've noticed an explosion in interest in formal verification recently, especially since nowadays the bar to entry is so low: just ask your LLM agent to give it a go.
Realistically much of the most reliable software in the world was written in C. Robustness is more so a function of coding style and engineering practice than it is of the programming language chosen.
Of course you could argue that on average, most programmers are not going to have the right practices and skill, so on average you should prefer Rust. But that's unrelated to the argument I was making, and in any case not a very interesting point in my opinion.
Conversely, most of the high impact bugs are also written in C and C++, because they rely on "coding style and engineering practice" to be correct. Rust raises the floor on this by a lot.
Adding that with a principled approach, I don't even see much of an issue with doing manual creates and deletes in a object-graph type app, with many unstructured lifetimes. Sometimes that might just be required, and then the complexity is just there either way. Having to cleanups manually or not doesn't change anything about that. It's a bit more cumbersome to get everything right when doing it manually -- sure.
The problem is mostly people graduating from school thinking that somehow there is only stack and heap, and malloc/free is how you do heap. That view completely ignores that the essence of programming systems is mostly to understand the machine, and then doing conceptual and architectural work on a solution (and also on a problem). The act of writing actual code is then mostly just translating those concepts into the digital world verbatim.
Above poster is talking about thinking in terms of grouped lifetimes and bulk allocations/deallocations, which is better for performance, and makes Rust borrow checking and other RAII style features pointless as they don't add any safety benefits. This video completely changed the way I think, and I subsequently moved on from Rust: https://www.youtube.com/watch?v=xt1KNDmOYqA
the buffer managemnt is just different pattern and style of code thats more low level. when you care about performance and cpu cache, you have to make sure that actual physical memory gets computed at same time as other memory near it so there is less latency.
the primary motivation isn't latency but complexity. People do in some applications free or allocate collectively because they have interrupt times in mind, but most of the time when you manually manage memory the issue is mental overhead, so people gravitate towards models they can keep in their head.
Allocating in large chunks is often not very performant which is why people came up with tools like the borrow checker, you often want to allocate and deallocate dynamically on a need-basis but that's exactly where bugs occur.
People tried to "just do that" (write their programs in a memory safe way) in C and other languages with manual memory management for decades, and we have countless vulnerabilities that prove this simply doesn't work. That's why newer languages, with the notable exception of Zig, prefer more advanced memory management methods.
> People tried to "just do that" (write their programs in a memory safe way) in C and other languages with manual memory management for decades, and we have countless vulnerabilities that prove this simply doesn't work.
Who are these "people" you speak of? It's possible to write software in low level languages that don't have these problems. Not a "non-zero" it might be possible, it can be done thoughtfully, and the popular notion it can't be done is backed only by incomplete anecdotes.
Should everything be written in low-level languages? No, that would be absurd. Is it a simple fact of life that not every person/team/organisation is capable of meeting certain standards of rigour? Yes. That's not to say anyone in the Bun team could not become sufficiently competent in the future. For whatever reason, current experience, incentives, and personal motivations did not make for a conducive environment to make Bun watertight in Zig.
Yes, it's possible. It's also possible for experienced pilots to fly an airliner completely manually for the full duration of a transatlantic flight without crashing. Still, over the last decades, autopilots and other assistance systems with ever more sophisticated features have been developed, and I would argue that without this technology crashes would be much more frequent than they are today. Same goes for memory management: you can do it manually, and it might work out most of the time, but if the programming language is helping you with it, the likelihood of memory safety issues decreases drastically. And the problem with avoiding these issues only by "meeting certain standards of rigour" is that you might only find out that you have failed to meet them years later, when you learn that your software has a vulnerability.
> Same goes for memory management: you can do it manually, and it might work out most of the time, but if the programming language is helping you with it, the likelihood of memory safety issues decreases drastically. And the problem with avoiding these issues only by "meeting certain standards of rigour" is that you might only find out that you have failed to meet them years later, when you learn that your software has a vulnerability.
Zig does help you. Array slices, explicit nullability of pointers, defer errdefer, explicit allocators, built-in leak detection, bounds checks, overflow detection, the list goes on. If you need to play around on that side of the fence, Zig gives you a lot to make sure you don't mess it up. If we were talking about C I'd give you your flowers, but we're not. The most common issues and vulnerabilities that crop in C from manually managing memory are strongly mitigated by a quarter of that list.
Just people like the linux kernel, all major browsers, most of our popular webservers, etc and basically all non-trivial software projects written in C.
The good news here is that we have more than just anecdotes to support this, we have empirical evidence.
That's like saying that they should have used assembler but they just weren't capable of it. It's personal insult dressed up as a nonsensical technical argument.
It matters what software you're writing. When it's a JavaScript runtime, it's not as if you can get away with preallocating all the memory you'll need like some games used to do.
I think the main issue is that Bun relies heavily on existing C++ libraries like JavascriptCore, and these require RAII and ref-counting semantics from C++ that are closer to Rust than Zig.
You could write a JS engine with Zig-like idioms (arena allocation, static initialization), but that would require re-writing the whole JS engine from the ground-up (though I would definitely be interested in it if someone actually tries to do it!)
> You could write a JS engine with Zig-like idioms (arena allocation, static initialization)
Could you actually? That seems like a bad fit for a JS engine to me. Predictable memory requirements are great when you can have them, perhaps you can avoid complexity then, but for a JS engine?
> You could write a JS engine with Zig-like idioms (arena allocation, static initialization)
Arena allocators & static initializers are not novel. You'll find them in high performance C++ projects as well, such as LLVM or JavaScriptCore. But arena allocators have the quite significant limitation that they only help when everything being allocated in them have approximately the same lifetime. So they don't help when you need to allocate memory to provide the native implementation of a JavaScript object, for example (eg, FFI).
Swift is very weak outside Apple ecosystem, compared to Rust. Not sure nowadays, but Swift used to have breaking changes each major release, that's a non go for a big project.
Andreas Kling talked about it. It boils down to C++ interop sucks (no surprise for lang made by Apple), ecosystem is tiny, Rust works well enough with LLMs.
He just wanted to use LLMs for coding, and not enough training data on Swift code exists for his use case. Admitting to that would be rather silly, so here we have this sentiment now exist rent free in people's brains.
The C++ interop of Swift is perfectly fine, to such a degree that FoundationDB is now using it effectively alongside its C++ origins.
Swift is one of the few toolchains that actually has some kind of builtin C++ interop, alongside Objective-C++, D, .NET (via C++/CLI), Carbon (eventually).
This reads like cope because you're re-inventing RAII from first principles.
I cannot take this seriously as tutorials on robust Zig Allocation Pools will store a deinit method for each item within the pool, so when the pool deinits, all internal objects can be deinit'd.
That is just RAII & dtors from first principles, except with extra overhead of manually storing fat pointers yourself (and the bugs that come with this). Instead of using a language with builtin guarantees & optimizations around handling this so your object pools don't need to carry around a bunch of function pointers. C++ has aggressive de-virtualization passes so at runtime a lot of the 'complex object hierarchies' can be flattened to purely static function calls.
This is a general problem with destructors, you can't "batch delete" objects. To free a lot of stuff you're required to go pointer by pointer through the tree to clean up each object. To get real performance gains from pools you can't have per-object/subobject custom cleanup code.
I've argued elsewhere some things that are wrong with RAII and C++ objects in general.
Here I would just like to mention that if you have to rely on "de-virtualization" passes, you're in a miserable situation architecturally. If you have code where the overhead of virtual function calls might be too much to pay, don't do virtual functions then. End of story.
To deconstruct a pool of objects, I don't see what should ever be wrong with a function pointer. The overhead of loading the function pointer will get divided by the number of objects being deconstructed. Care to explain what's the issue here?
1. No, you're not writing code you don't have to. It's not different to implementing this as non-virtual methods, in fact I'd argue doing simple functions is more straightforward.
2. And the code being compiled is abstract & generic, it won't be instantiated for every type and bloat the executable or instruction cache.
3. Security concerns: With C++ virtual methods every object carries a mutable pointer too (to a vtable containing function pointers). What resource management side effects please?
Of course they are. The pointers to the vtable are part of the object. They aren't mutable fields as per the language, but for security concerns it doesn't matter what the language thinks. Being part of the object, the vtable pointer has to live in a writeable memory mapping (like stack / heap).
Then I don't understand your argument. If you're just saying what could go wrong with heap corruption, then your vtable complaint also applies to storing function pointers in arena allocators in Zig? Zig doesn't have anything special here?
I thought that this was just an initial translation to unsafe rust in which they haven't actually gained any of those benefits yet, although presumably they can go there quickly now.
A garbage collected language does this automatically. Rust still requires thinking about and tracking memory lifecycles, but the borrow checker will complain and keep you from doing it wrong. That's why LLMs like Rust. It gives immediate feedback on what to fix. By-default constant reference parameters helps prevent major performance problems.
You're getting confused between lifetimes (the static analysis that prevents use after free and similar errors) and lifecycles (more commonly discussed under the heading of ownership) which determines when objects (and thus memory) are allocated and deallocated.
Ownership is automatic. You don't have to explicitly drop things when they go out of scope. (although the responsibility for that is split between the compiler and the library code).
Lifetimes are not automatic, but also have no effect on memory allocation. They are purely a static analysis path and you can make a functioning rust compiler that completely ignores lifetimes.
> You're getting confused between lifetimes (the static analysis that prevents use after free and similar errors) and lifecycles (more commonly discussed under the heading of ownership) which determines when objects (and thus memory) are allocated and deallocated.
Ownership is
That's a semantic distinction which does not matter in the point OP is making. And contrasting rust static approach to general GC.
Yeah but if you have tried writing unsafe Rust, you notice that you are obligating yourself to write code that is much stricter than C.
E.g. in C you can write code and say "don't call it outside the situation that this function was written for" and then blame [0] future users of the API.
In Rust you need to actually make sure that your code works, i.e. your safe interface is not unsafe.
[0] The blame game is not a technical solution to a technical problem...
True, but unsafe let's you conjure up any lifetime you want, or any lifetime necessary to satisfy the lifetime requirements in safe code. If you generously sprinkle pointer dereferences in unsafe code, you effectively disable the protection provided by the borrow checker – including in safe code – until you've checked and verified the correctness of all unsafe blocks.
The whole point of the rust rewrite is that bun is now thought to rely on rust’s memory safety features, but that assumption doesn’t hold if everything’s inside an unsafe block.
Only ~4% of code is inside an unsafe block, so the idea is that for new code/contributions, the chance of introducing a new memory-safety bug is an order of magnitude lower.
Maybe in the future the unsafe code will go down to 1%, bringing that to two orders of magnitude.
Of course, only time will tell if that is true or not, but from experience I’d be willing to bet it is.
fn main() {
let mut x = 1_u32;
let reference_a = &mut x;
let reference_b = trust_me_bro(reference_a);
*reference_b = 2; -- Whoops
println!("reference_a: {reference_a} reference_b: {reference_b}");
}
After the call to trust_me_bro, two aliasing, mutable references exist simultaneously. This would usually be prevented by the borrow checker, but the unsafe code has effectively disabled it.
Not sure what you meant by this example since it doesn't compile. It seems the borrow checker caught your mischief. So much for effectively disabling stuff :P
You haven't effectively disabled anything; you just (tried to) wrote unsound code that washes one mutable ref as another. This stuff is allowed provided shared refs are never accessed at the same time (for example, panicking upon reading reference_b).
But you know what? If you're dabbling in unsafe, you have this big button called Tools in the playground. Choose Miri, then run your code; it will display large Undefined behavior. It even highlights the `trust_me_bro` function.
Hell, run this with UBSAN, ASAN, and other C tools. They will probably catch any such behavior.
If you know what I meant, then what's up with your snarky comment about "So much for effectively disabling stuff"? In your playground link, you did effectively disable the borrow checker in safe parts of the code. Next thing you're moving the goalpost, now it's not about external, static analysis tools: "run this with UBSAN, ASAN, and other C tools". I don't think you're arguing in good faith here. Goodbye.
Sure; but I bet raw pointers are used very infrequently in the new codebase. The code was ported from zig to rust. I bet a lot of pointers became rust references in the process.
You don't need to rehash the same old argument. Runtime memory management is forgiving but also inferior in a lot of ways to compiled stuff that works with memory deterministically.
Garbage collection is a method to make programming easier, not to make the resulting program better.
As opposed to every commit abd line of code being unsafe? They use a lot of C/C++ libraries with their own code so unsafe isn't even a a problem in most places they use it.
Please try to interpret comments in the context of the discussion, not floating freely in a vacuum. The context of the discussion is the Bun port's excessive use of unreviewed unsafe blocks. unsafe in Rust can easily be misused to create Undefined Behavior, which renders any safety guarantees otherwise ensured by Rust's borrow checker invalid.
> Does bun actually do anything insane like that in its unsafe blocks?
Who knows? At 10k unreviewed uses of unsafe, I'd guess there are quite a few incorrect ones. LLMs don't produce perfect code (neither do humans), so there's a high probability that at least some of those create UB.
"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 expect this number to go down over time as we refactor from a faithful Zig port (which had no greppable unsafe keyword) to idiomatic Rust, but we are going to continue using C & C++ libraries like JavaScriptCore so it will always have more unsafe than pure Rust projects."
Relative "number of unsafe keywords" or "lines inside unsafe blocks" isn't a good metric.
It's unsafe to call a C library that gives you a raw pointer, that can be a single line. It's unsafe to use that pointer, that could be a second single line. Carrying that pointer around, the data structures it's in, that's all safe, and doesn't implicate lifetime checking at all, so Rust will let you do silly things with the actual lifetime.
A better metric would be absolute unsafe keywords (because each carries a need to review), or "code in a module that uses unsafe anywhere" vs total code, because module boundaries isolate unsafe.
Yeah, one needs to understand that "unsafe" does not mark which parts of the code are actually unsafe, it simply marks parts where the compiler ignores parts of its rule set. But the implications can crop up anywhere, there is no guarantee that a resulting use-after-free or similar can only happen inside the unsafe blocks.
In short, if you use an unsafe block, then potentially any part of your code is unsafe.
Right, so if I understand correctly, to make the code fully safe, it can be impossible? Because you have underlying dependencies which are unsafe. The best you can do is make the handling of the unsafe as safe and as restricted as possible. But I can imagine some of these are way more difficult than others, and in programming the last 10% can be the last 90% of the work. Alas in terms of perceptions, the argument works well.
> In short, if you use an unsafe block, then potentially any part of your code is unsafe.
The way I think about it is that the unsafe keyword is a promise that you’re going to maintain the safety invariants yourself, manually. The program is memory correct if it correctly maintains a certain set of invariants. Unsafe punts responsibility over those invariants to the programmer. If you use unsafe and mess up, the program may be in an invalid state. Yes - it might crash, anywhere. But the bug is still almost always in an unsafe block.
It’s often possible to make fully safe wrappers around unsafe code which maintains all those invariants manually. (Either statically or dynamically.). A lot of the rust standard library does this. For example, Vec, Box and slice all use unsafe code internally to create safe APIs.
> it simply marks parts where the compiler ignores parts of its rule set
This is a common misconception, in a literal interpretation. It doesn't invalidate your point, but since people get the wrong impression: unsafe doesn't turn off any of the checks the Rust compiler does.
It allows you to perform 5 additional operations, and that's it. Using those operations wrong is what breaks the safety promises of the language. As an example, you could dereference a raw pointer and tell the Rust compiler it lives forever, when it's really a pointer to an object that's about to be freed.
what is surprising about it? The way porting works has alway been first doing a faithful pass before going back to address impedance mismatches case by case. You would do that even when porting things manually, let alone in a super risky completely automated bulk migration.
> He talks about the issue of tracking memory lifecycles manually in zig so it can be explicitly freed. As expected, this leads to a long list of bugs where people missed things.
Yes, and again the "you're holding it wrong" people or "you are not a good enough developer" people will try to do juggling with a chainsaw and lose a couple of fingers in the process
Claude Code's endorsement (and real-world testing) speaks louder than internet discussions that are at this point 30 years old (and probably more)
But only as far as "make it compile" is a good predictor of runtime behavior. In C++ for instance, I can "make it compile" and it still crashes at runtime or does other undesirable things.
Personally my take on the entire affair is quite negative, whatever Jarred or Simonw says about it.
I think Bun owned by Anthropic and the entire rewrite with AI is not the real point (even if it's quite interesting, though).
My take is that Jarred, and Bun,didn't demonstrate a serious, adult approach, from "this is my branch, you are overreacting" message to just proceeding with a 1mil+ PR merged in less than month.
The communication is the issue, and it was handled very badly, in a way that impacted trust and divisions.
Was it so difficult to adopt the approach that the TS team adopted for 7.0?
There was a recent post on here with a Claude Code issue I and others responses to. Specifically, the person from Anthropic who caused the issue replied on HackerNews. In it, he claimed he was the sole contributor and reviewer of the code into production, that he would “do better” in the future. Commenters were confused how a company like Anthropic could allow something like this occur and for an engineer to publicly admit a complete failure and negligence of build processes.
It’s clear seeing your post here a couple days later what’s going on. It’s deliberate. I can only speculate on their reasons why but it seems to be an intentional form of disrespect on the engineering culture. “Your norms, your work, your principles” mean nothing. We can spend money and invalidate your life’s work. We don’t need your consent or support. That’s my personal guess at a surface level.
I don't know, I feel as though Bun went about it much more maturely than zig at any point in the process, from the initial attempted zig compiler commit by the Bun team to the Zig dev team member response to the Bun Rust blog post. Also, I think that fallout over this whole event will definitely favor Bun versus Zig.
It's a weird way to frame the event. Yeah, Andrew (Zig)'s responses were astonishingly immature, but it doesn't matter. Even if Andrew literally ate baby seals for breakfast and kicked puppies as a hobby, it wouldn't make Bun look better. You'd notice that the parent comment didn't even mention zig at all.
Saying Bun's communication was an issue here is clutching pearls. There is no evidence that Bun ever acted in bad faith, Jared definitely seemed to initally think it was just a trial, until he realized that it was actually something feasible. He isn't clairvoyant; there is no way he would have known it was going to be successful when he initially made the post.
Bun isn't Bun, it's a (notionally) trillion dollar AI company famous for ruthlessness and engineering controversy for marketing purposes. Zig just happens to be a language led by someone with an AI-skeptic philosophy. Are you saying I should just believe that their strategically deniable negative insinuations about Zig are not bad faith?
Sorry, but I'm calling bullshit. I know there's no absolute smoking gun here, but it's all a bit too cute to be unintentional. They are very very smart people. They knew what they were doing.
If you can lock down a test suite that ensures parity, then who cares what shape the lift ultimately looks like.
A full rewrite in different language that fails to be idiomatic is a step backward operationally, even if you stand to gain on issues the new language just eats for free
"postgres is so stable I will never trust a rewrite."
"covering 100% of postgres regression suite doesn't guarantee you have replicated every behavior."
Folks who are okay with LLMs think the regression test suite is the spec and is the guarantee of stability. How else can it be? If you are depending on some behavior not covered in the regression tests, how do you know the next minor release won't break you?
Folks who are against seem to imagine a platonic ideal of PG which conveniently is the original PG implementation by tautological definition. So no rewrite can ever meet their bar.
> Folks who are okay with LLMs think the regression test suite is the spec and is the guarantee of stability. How else can it be? If you are depending on some behavior not covered in the regression tests, how do you know the next minor release won't break you?
I think this deserves a real response.
First, an analogy. I drive along a cliff with no guardrail. How do I not drive off the cliff? By knowing how to drive. Sometimes people mess up and drive off the cliff
In practice people are operating Postgres as a machine, more than an abstract spec. Minor releases exist, but the changes are made by people operating the machine and who have a fear of making the machine break.
There are also performance characteristics that are part of an informal spec. While you can definitely write regression tests on performance, theres loads of value in stability of internals because people who have problems look into the machine and discuss it.
The internals might change, but there’s a lot of friction. So… you can have a lot of informal knowledge about.
If everyone working on a software stack is bathing in this informal knowledge, then the decision making is based on that. Things like what is meant to be in a minor or major release is understood. And people make those judgement calls.
After all, even if you have regression tests if you’re making changes you’ll need to write new tests! How do you know your new tests are right? That the new behavior is right?
PG is the entire machine. Fortunately we have version numbers, migration strategies, etc. But “here’s a new binary that passes the test suite and… maybe changes everything not covered by tests maybe doesn’t”. Why bother suffering when there are totally reasonable gradual rewrite strategies?
And of course… every bug in the world… got through despite a test suite! What software out there doesn’t have bugs?
And if the behavioral difference in the rewrite does affect people… I guess that’s something right? “Oh this isn’t a bug because it wasn’t covered in regression tests” is not that tenable.
If you are saying the PG regression suite doesn't cover these perf tests - that is fair. I consider perf to be part of the "regression framework" generally.
>> How do you know your new tests are right? That the new behavior is right?
This is a more generic question in the LLM world. Reliable verifiers is what drives LLM loops. If you don't have these, you have no idea if you are actually making progress or you just generated code that returns 42 for every question. You needs something to actually ground the LLM output against. For existing features, the reliable verification is the existing regression/perf suites. For new features, the regression/perf suites should expand to fit. There are ways to go at this that range from ad-hoc (line/branch coverage) to fully formalized (verification-aware languages like Dafny).
I think what folks want, but aren't quite able to articulate, is an ongoing community and effort that indicate a project will be healthy and maintained. We want to be able to rely upon the software that we are choosing to use.
Regardless of the technical choices, whether Rust is better or worse, whatever -- pgrust popped into existence thanks to one person driving an LLM through 7000 commits in ~2 weeks. It produced something that passes the regression tests. Even as an LLM-sceptic, I think that's amazing.
From that point, though, it appears to have been completely abandoned. There hasn't been a commit in a month, other than a brief tweak and a note that an as-yet unpublished version that's even betterer is in the works. IDK. I don't think we've acclimated to the shock of the change LLMs create, but if the outcome is a forest of exciting new projects that have a bus factor of 1 and little to no collaboration, I think that's a disservice to this profession.
I am not saying anything about the viability of that particular project; just that one argument that was repeatedly made in that thread which I think is frankly nuts.
> If you are depending on some behavior not covered in the regression tests, how do you know the next minor release won't break you?
Decades of intrinsic knowledge. Which a rewrite lacks.
imho the issue is the language used. AI rewrites are cheap and cheap exercises require a great deal of scrutiny and proof of correctness. Simply using regressions test lacks the intrinsic knowledge of a decades old codebase stuck in developers minds.
Claiming a rewrite is better because it passes all tests is a flex, a new version requires a boatload of evidence for people to accept it as an improvement and not just "passes tests, written in rust via LLM so it must be better". Run it in production for a year in a sufficiently large system and you might be somewhere.
>> Decades of intrinsic knowledge. Which a rewrite lacks.
You mean the ones encoded in the regression suite? I think your argument is valid in many medium-to-faang firms where the application is going to have encoded business logic that isn't explicitly tested for. If anything, projects like PG are the exact opposite: no business context and regression suites that test every possible scenario due to the accumulation of bug fixes and context over many years.
>> Run it in production for a year in a sufficiently large system and you might be somewhere.
How do you know every release of PG doesn't break in the setting of "a year in a sufficiently large system"?
> no business context and regression suites that test every possible scenario due to the accumulation of bug fixes and context over many years.
Spend time enough with a codebase and you’ll know stuff about its behavior that is not encoded in a test suite. Especially when you need to adjust an integration tests due to the modification of an invariant in a dependency.
> How do you know every release of PG doesn't break in the setting of "a year in a sufficiently large system"?
Because the postgres team is professional and will take care of publishing a changelog for what has been modified since the last version.
Indeed as much I dislike the approach Bun took, at least the port appears to be working. TS7 is going to cause problems for downstream users because Go is the wrong language to use for something that has to run in WASM.
First, yes, the demand to be able to code natively in a browser is, I have reason to suspect, very large. It's just difficult to measure demand when nobody has ever offered a really compelling product. In engineering terms it's like getting a full-scale reading. The real level could be 1% above a full-scale reading, or the real level could be 100x higher than the full-scale reading.
Secondly, WASM isn't the right target for the browser anyway, JS and the DOM have to be what you consider "native", for the most rigorous UI projects at least (which building an IDE is). If you want to build a cross-platform UI product that doesn't require installation and has Emacs-like levels of extensibility, JS is the end of the line in terms of language selection. There are no other candidates.
> If you want to build a cross-platform UI product that doesn't require installation and has Emacs-like levels of extensibility, JS is the end of the line in terms of language selection. There are no other candidates.
calibre (with python+Qt) begs to differ. And I believe VLC runs on every current platforms. There's also Code::Blocks and Blender. Cross-platform UI is not rocket-science.
All great examples, but ones that do require installation. Their website is just where you download the product, I'm talking about making the website the product.
It's not just typechecking, the typescript library is also the reference parser for TypeScript and reference emit. Emitting JS from TypeScript is non-trivial and non-local.
It's not just in browsers, you might want to run the typescript library on the edge or in some restricted environment where JS/WASM is OK but native code is not.
You may want to use the typescript library as a dependency in your own package. TypeScript becoming non-pure JS means that your library also becomes non-pure JS.
NodeJS can strip types internally without a straight TS dependency. I don’t think this matters, TS was a huge bottleneck for many build pipelines because it never parallelized well
Type stripping is not the same as emit, it only gets you a subset of TypeScript. Fine if you're running your own code, not fine if you want to run arbitrary TypeScript.
Didn't WASM got a GC proposal that Go and other managed languages can use it? So it might be an issue in most browsers right now, but soon it might not.
> For me this outputs Bun v1.4.0 (macOS arm64). The most recent release of Bun on GitHub is currently v1.3.14 from May 12th, so that v1.4.0 version number in Claude supports them shipping a preview of a not-yet-released Bun version.
And so, the FOSS project "Bun" silently dies in darkness and is now something completely else. I'm glad I still had "Investigate if Bun is worth it" on my TODO list and hadn't yet gotten to it.
What is the governance structure for Bun by the way? Couldn't find any documents/explanations about how it's supposed to work. I'm guessing it's essentially just "Anthropic decides what gets done and accepted" today?
It’s made absolutely no negative difference, as we’ve seen in the real world in the last 60 days since the merge.
I feel weird having to defend reality; reality being that it was merged nearly 2 months ago and tons of people have had their pitchforks out without a shred of actual evidence that this made bun worse in any measurable way. But they still insist it was a mistake.
I’ve never met Jared or the bun team but I don’t understand all the personal attacks, I just feel the need to correct the facts. Literally who cares what language a JS toolset is written in?
It’s not like they ported JavaScriptCore (the actual JS runtime) to rust even. All that stuff is largely untouched.
>It’s made absolutely no negative difference, as we’ve seen in the real world in the last 60 days since the merge.
The rust code is not yet in a stable release, and CC only switched to it in the latest version, so there's not been 60 days of widespread battle testing yet, so i don't see how we could possibly say it will have no negative difference. It hasn't, because nobody is using it yet. It still might.
>Literally who cares what language a JS toolset is written in?
I don't care what language it's in, but i do care how it is written and maintained. I'm not going to trust my projects to a runtime that was written by an LLM in two weeks with practically no human review
>Literally who cares what language a JS toolset is written in?
Maybe you're being coy by asking a rhetorical question you already know the answer to but I'll answer as if you asked sincerely...
There are 2 different groups interacting with software products:
(1) end-users : this is where the "Who cares what language it's written in?!?" is usually applicable. E.g. The finance guys using MS Excel don't care whether it's written in assembly, BASIC, or C Language.
(2) code contributors and/or programming language enthusiasts who see other projects as "validation" of the whatever language they've invested in: these people definitely care.
For all the decades that computer languages have been debated, Group (2) will always discuss projects language choices. E.g. reddit.com switching from Lisp to Python, the Linux kernel fiercely debating future Rust contributions , the Typescript compiler switching from Javascript to Go, Bun switching from Zig to Rust, etc.
People try to lecture others in Group 2 about "don't make a programming language your identity" ... but people are human and they can't look at all the above language choices as totally detached observers. They like to talk about it!
If one is a Zig coder that contributed to the previous Bun Zig codebase, we can't expect them to be neutral observers.
I think you're missing group 3, which is the "assume bad faith and/or bad outcome from any possible change to anything, and especially changes to open source projects that can be interpreted as exogenous, e.g. from an acquirer, and especially if that acquirer is a gigantic commercial entity."
There are not nearly enough disenfranchised Bun-on-Zig contributors to make a dent in this conversation. There are lots of Group 3s in every similar convo, for any combination of technology, project, and acquirer you can name.
I think most of the naysayers are in group 3 because there’s a lot of anger but never a single link to a blog post or analysis done by anyone to demonstrate a regression. not one. There are some that analyzed the quality of the initial rust code and use of unsafe but Claude has been chewing through those as I understand.
Personally I chose not to disclose my findings in public to avoid this kind of outcome. Having a good laugh with others is not as important as keeping the result of this experiment undisturbed.
This also eliminates the chance of another round of marketing of LLM ability based on actual human contributions and I suggest everyone who is able to analyze the code to do the same - so that they cannot misattribute our ability to LLMs.
Afaik, under current US law (Thaler v. Perlmutter 2025^), "the Copyright Act of 1976 requires all eligible work to be authored in the first instance by a human being".
With regards to AI-generated code, this means the copyrightability (at all, not with regard to who owns it) turns on whether or not a human was substantially involved in its creation.
Existing decisions require evidence of pretty heavy and continued human guidance to qualify.+
To wit, autonomous agent created code (prompt -> machine churns for hours -> output) is explicitly not eligible for copyright.
Functionally, this is a double-edged sword.
On the one hand, it means anything coded with autonomous agents by Meta, Google, et al. can be legally reused if it leaks (because no one could hold copyright on it).
On the other hand, it leaves copy-left open source licenses in a weird place. If you convert open source (even MIT/BSD-style) code into something else with an autonomous coding agent... the result has no copyright (nor can ever in the US).
In this instance, Bun was MIT-licensed, no? Then it was shoved mostly-autonomously through an LLM for the port.
Now Bun-Rust is technically still MIT licensed, but if push came to shove it seems like US law's current position is that Bun-Rust would now have no copyright license (because the manner in which it was developed renders it ineligible for copyright).
That's on the copyright side.
On the infringing usage side (i.e. whether you were entitled to shove a copyrighted work into a coding agent to produce something)... that's still TBD.
Couldn't it be argued that Bun-Rust is still MIT licensed, because the old implementation was "in the first instance" authored by a human? All the machine did was translate it.
I think it's the "infringing usage" question that is more interesting. If the LLM trained on GPL-derived code, what does that mean for the end result?
"If the LLM trained on GPL-derived code, what does that mean for the end result?"
Either it means nothing at all, or it means that a substantial portion of the code produced at some of the world's most valuable companies over the last two and a half years is GPL.
Yeah you could argue that, but it's a messy argument. I'm wiling to imagine that they hadn't used AI to do the rewrite to Rust. It wouldn't have been all that hard to do with plain old syntax tree transformation (my expertise). The trickier question for me is the ownership at the boundary where prompts were turned into Zig code. That is not a process that could have been done with syntax tree transformation: creative freedom was given to the model as to how to do the work at that stage, and so that is the stage at which I'm least sure they could legally defend their claim to ownership.
I feel like that's a lot of LLM use in a nutshell: sure, there's a more surgical scalpel available, but isn't it so much easier just to fling prompts at a magic box?
> who cares what language a JS toolset is written in?
Anthropic, apparently, not the least because they blanket-closed all issues submitted before the rewrite. If the language were irrelevant, it shouldn’t matter for the existing unfixed issues.
> blanket-closed all issues submitted before the rewrite
You'll need a citation for that. While I'm still not sure whether Claude Code's issue tracker is worth much (Anthropic doesn't seem to engage with individual issues a while lot), it still has 5k+ open issues ranging back to March 2025. Bun also still has all of its Zig-timeline issues, all 5k+ of them. So what's this about?
imagine being the leadership of the one of most valuable US private companies in the world. then you have to make something called a "pull request" that gets "reviewed" by someone named "Jarred" to make improvements to your stuff. do you see how that is untenable?
the language is relevant for political not technical reasons. you could say, blanket closing the Issues, getting rid of this thing called Jarred from your stack, etc., is really an attack on the GitHub and the GitHub Agitator Lifestyles, which is why so many commenters on Hacker News actually care.
> It’s made absolutely no negative difference, as we’ve seen in the real world in the last 60 days since the merge.
This is even more interesting given that prewar Bun was not a well respected code base. This matters if the code was bad, were the tests bad / not comprehensive as well? If so, the translation to rust whose sole / primary target was test-passing will have a fair amount of undocumented bugs in it.
> poster child for Zig programming language actually being the prime example of How Not To Write Zig Code
Whole classes of bugs WERE fixed by moving to rust. wouldn’t that result in mass closures of classes of bugs that were no longer relevant in rust? What would you prefer?
Whole classes of bugs are fixed by safe rust. This is not safe rust. As a line-by-line translation with unsafe forced anywhere necessary to make it compile, this should result in no classes of bugs fixed by moving to rust.
I would prefer they confirm before closing. It's AI / bot anyway. Instead it's just mass keyword zig = close. The bug can still exist post-port. None of it got "fact-checked".
In fact a lot of "feature requests" like npm compatibility related or missing specs etc ALL also got closed for being "zig" because reproduction and suggested solution were of course zig.
this whole AI era has put the topic of "do we believe actual reality, or what we hoped/assumed/continue to insist would be reality" front and center. Every discussion is like this these days.
> What is the governance structure for Bun by the way? Couldn't find any documents/explanations about how it's supposed to work. I'm guessing it's essentially just "Anthropic decides what gets done and accepted" today?
And this is a valid question. You are not "defending reality" by refusing to listen to it.
In summary and based solely on my understanding:
- Jared misled people about the intentions of the migration. It's not the worst thing in the world, but it's certainly worthy of criticism.
- Jared has commented before about locking out human contributors from open source projects. Whether he was making a larger point is irrelevant as his comment stands on its own.
- Other Bun contributors, past and future, outside of those employed by Anthropic, did not and likely will not have equal access to the model Jared used for the rewrite.
Jared, working in the public Bun repository, used tooling not available to his community to experiment with a signficant migration. He dismissed all concerns and told people it's just a bit of fun, and that it shouldn't be taken seriously. Most of the controversy would have been avoided were the experiment done in private.
None of this is a big scandal but questions about the project are entirely justified.
Which was completely bonkers -- it happened completely in the open, people were just outraged that something like this happens without asking them and not on a schedule they perceive as adequate. Most of them haven't really grasped what was happening and why. Many still don't.
It wasn't out in the open. It was never announced or discussed ahead of time. It was just done because the company who purchased Bun wanted it done, and they only communicated it was happening once they started.
I don't consider the following comment to be good, honest, and open communication:
> There’s a very high chance all this code gets thrown out completely.
... and a few days later he decided that the code wouldn't get thrown out. That doesn't make the comment itself dishonest, he didn't have a crystal ball.
You can absolutely argue that the rewrite was not communicated clearly once they committed to it, but I don't think the comment you linked to there stands as evidence of poor communication at the time it was written.
Rust as a language is irrelevant to this discussion, the problem is that bun was vibe coded by a single dude without any open source community involvement. “bun the open source project” is basically dead at that point: don't expect any of the zig enthusiasts who had their code being forcibly rewritten in a language they don't like to follow Jared.
I agree, it's unfortunate the headlines seem to have become 'rewritten in Rust' (not a bad thing) and not 'vibecoded in a week without review' (a bad thing).
"Vibecoded" is not an accurate description of what actually happened. LLMs are extremely good at porting code from one language to another while preserving semantics. Which is why how everything turned out so well was not very surprising.
The Zig one uses raw pointers. These are bad and get out of hand quickly but at least don't have constraints like "you must never have two &mut on the same value". You may refer to c2rust to see how "semantics preserving transformation" without new UBs looks like.
Sorry, I did. And I did an internal sharing with respect to the blog post, on topics of how to (and not to) do software migration, how (not) to deal with unknown unknowns etc. We have several ongoing software (automated) migration projects so I did rather extensive research around it.
I do regret that I've also read the code though, otherwise I'd probably live a little happier with ignorance right now. Sadly as they don't know they don't know about the issues, there's no indication of those in the two public materials they have released.
Rust as a language is not relevant, but the Rust community still helped to popularize the idea that trashing a community by a rewrite is ok if it serves some "higher goal". This rewrite is just a striking example why this is problematic.
Reviewing is meaningless while they are still keeping the 10433 (sorry it has become 10503 since last week) unsafe blocks, most unsound and none encapsulated.
Any review would get to the simple conclusion that this should not be released before all the obvious bads are sorted out.
It isn't disabled, it has exclusions. Now that they have it, they can close the gaps. It was literally impossible to have ANY coverage before, now they are mostly, covered and have an avenue for remediation.
I don't understand why folk are having such a hard time understanding why you do large projects in multiple steps? 80/20 rule? Perfect is the enemy of good?
Was nobody here for moving billions of lines of JavaScript to Typescript? It starts with declarations, then turn on type checking gradually inside the codebase: piece by piece until done.
I like Rust and use it full-time professionally. Unsafe is not the same as unsound. Unsound means that the unsafe code is not maintaining the aliasing invariants on references required by the language, and thus undefined behavior can leak into safe code (that is, the safe code can be miscompiled).
Known unsound code should not be merged, let alone released to production. If you have good enough tests and run them under MIRI or ASAN, maybe you can get away with it for a time, but most Rust experts would not sign-off on such a project.
If somebody put a gun to my head and told me to make the best of such a codebase, I would try to figure out how to turn off the LLVM optimizations that assume the Rust references don't alias. With these optimizations this codebase is scarier than most C or C++ code.
I'm not a rust dev. But I've been once asked to take care of a TypeScript codebase and the thing was littered with so many casts to `any`, you're wondering why they bothered with TypeScript in the first place. Some people do choose tech on a vibe and not any real analysis.
My conclusion was formed in my two months long tracking of the repo activities. They have done absolutely nothing in that front. (Well, to be precise they tried to fix exactly one thing that was pointed out but that's it)
> must interface with C code that has no safe interface
Yeah so the sane first step is to create encapsulated, safe interface for them, especially in a project like this. Deno for instance have ~0.2x as many unsafes.
And mind you if you haven't read the code, the vast majority of unsafe blocks in bun are for raw pointer access to local (Rust) objects because their ownership was a mess both before and after the rewrite. Also funnily enough a lot of the access patterns are wrong (in the Rust sense), leading to hundreds of new undefined behaviors.
> be honest and reasonable
Well, well. Talking about dishonest and unreasonable behavior, why is bun releasing a new version before solving any of those glaring issues? I'd remind you the current new version is not an improvement compared to the previous one, both in terms of correctness and maintainability.
Another point of comparison is density of unsafe: the number of unsafe blocks per line of code and/or file. By this metric, Deno has a bit over half the unsafe (because the bun rewrite is significantly more lines of code).
> I'd remind you the current new version is not an improvement compared to the previous one, both in terms of correctness and maintainability.
Except, you know, multiple real companies saying that it is and using it in production. And the fact it closed all known memory leaks. And that nobody has a really pointed to a single actual issue the new version introduced after two months of endless, ceaseless bitching.
I'm also fascinated by all these people upset at Jarred for harming the readability of a codebase they've literally never cared about before it become drama. Bun has almost exclusively been maintained by Oven employees since it's inception.
> Deno for instance have ~0.2x as many unsafes.
A project written ground-up in Rust idiomatically, with a smaller surface area, still has an unsafe footprint within an order of magnitude compared to this automated rewrite from an unsafe language with different practices and known bugs? That's not exactly the slam you think it is.
> nobody has really pointed to a single actual issue
I personally know 3 categories of newly introduced issues spanning the code base with 200+ occurrences, that leads to undefined behavior and memory issues. Not doing any contributions to the code is my conscious decision, which includes not pointing to the specific problems in public.
Is the idea that a code base reset makes something stop being open source? Or that the number of people doing the reset matters?
I don't see why either of those would be true. The project isn't dead just because it's in a different language now, and for liveness purposes it doesn't matter how it got to that different language.
I think the point is that an “open source project” is more than just the code and license, it’s also the community that builds and maintains it.
A fast rewrite of Bun in Rust has effectively alienated most of the people in the Bun community, so in that sense the “open source project” has died. It’s no longer a community project, it’s just become a personal project again.
Just so everyone know, Bun is and has always been owned by a YC funded org with full time employees. The overwhelming majority of commits came from them.
A reset is very different from not being open source any more. If losing most of the community would mark a project dead in open source terms, then every new project would be dead on arrival. And that would just be silly.
I am impartial on the matter, but I think one of the reasons Bun became a thing in the first place was because of Zig attracted a small but very active developer community. Switching from Zig to Rust effectively alienates that community.
I think the Zig people are really just worried that maybe Zig itself is a DOA language before it has even reached 1.0 because it doesn't offer enough over C for any serious use and their flagship project has now abandoned it.
You, by your own admission, haven't even written a single line of Zig despite having ~31 Zig projects on GitHub. I don't think your knowledge of the language is to be trusted in almost any capacity. This might seem harsh but I don't trust someone who's experience with a language amounts to slopping out 30+ repositories and not even engaging with the language normally.
I guess that since you haven't built the car you're driving, your opinions on it are null and void as well.
Anyone who actually believes that I can't have ANY sound opinion on Zig after 31 projects building with it should get their head examined for brain tumors. I mean, it's not like I have to deal with all the positive and negative effects of things written in it. It's not like I've had to solve problems in it that emerged when the LLM didn't do things correctly (and yes, I can tell when this is so, and not just when things are buggy). And it's not like I don't know (by heart, not by LLM) at least 15 other languages that I can draw on (C, for example, for which I not only got an A in a class at Cornell once, but was in fact the person with the highest score in a class of ~150 people... A perfect score, in fact) to form valid opinions in combination with how I see Zig working.
So please take your baseless skepticism and baseless assumptions and shove them up your ass, dude. I have work to do, and I'm far more capable of it now than I was, thanks to the LLM boost.
By my own admission I wrote ~100K loc in zig-head. Having a background in linux kernel development of all things I can tell you that Zig is so much better than C or Rust, that I think linux kernel rush to rust is misguided.
I haven't even stated whether I agree with the opinion that Zig is worth it, in fact I do think Zig is worth it for a large set of problems and I wrote Zig for years, I am stating simply that I would never trust anyone who's self-admitting that they don't even write the language they're arguing for when it comes to opinions on whether it's good or not. It's not really about whether Zig is good, it's about someone who doesn't even write the language and doesn't even know it, not having a valuable opinion on it.
Zig is a DOA language for other reasons though. The reason why Rust enthusiasts act so morally superior is because they are:
> Rob Pike, an unsafe guy, may insist that a small language and garbage collection are enough. But the typesafe visionary Grzegorz Wielbodłąński understands the deeper truth: every invalid state permitted by a compiler is a tiny act of civilizational sabotage.
There is no sense pretending anymore that languages with as many gotchas as C and Zig are "simple". Quite simply, they are not. The complexities lie in what's left unspoken, unaddressed, and of course undefined; failure to comprehend these completely can be catastrophic. Rust is so thoroughly and obviously the correct thing that using anything less correct should be taken as a sign of engineering incompetence.
> There is no sense pretending anymore that languages with as many gotchas as C and Zig are "simple". Quite simply, they are not. The complexities lie in what's left unspoken, unaddressed, and of course undefined; failure to comprehend these completely can be catastrophic.
This is where I’ve arrived too. After nearly 20 years of programming I feel done with leaving foot guns lying around. Languages that are full of them, but “fine” as long as you take extreme care are not interesting to me. I’ve started calling this “simple as long as you avoid all the foot guns” idea the sword juggling fallacy[0].
It’s too bad about Zig because it has many nice ideas, in particular allocators, that I hope Rust or some future language will adopt.
There are many things in life that are "fine" only when you take extreme care (knives, cars, industrial machinery,...). The thing is something like C has many usages and you can't just say "use Rust" and be done with it. Using Rust is not cost-free.
I'm not saying "never use C". The thing I dislike is the false dichotomy between "(Zig|C|Go) is simple unlike Rust, which is complex". A statement like that makes it sound like writing correct code in the former is easier when it's, in fact harder.
the thing is, as a pattern, footguns in zig are simple and easy to reason about (though they might be hard for an ADHD human to find). the compositional nature of rust sometimes makes footguns "hard to see" because they can be hidden behind layers of abstraction.
there is a potential future where an llm with unbounded patience would have an easy time literally walking through the zig code looking for one of the footguns might miss a footgun in rust because it's abstracted away. the ones in the stdlib should give you pause. what is hiding in some third party library's code?
Yes they stopped caring after C89, Plan 9 C compiler was a mix of C89 with extensions.
Still they are the authors, and withdrawing from WG14, going their own direction with Alef, Limbo, and finally Go, kind of proves the point they considered C done for its original purpose.
The post you linked to seems to jump to conclusions, to say the least. For example:
> One probable outcome of an unsafe-language-dominant world is full Andrew communism, which is precisely what Andrew “Smelley” Kelley proposes: abolish ICE and replace the market economy with a globally distributed network of community-maintained allocators.
> Rather than a commercial product, software becomes a “public good,” ultimately provided by the Zig Software Foundation as manually managed digital infrastructure.
Calling him "smelley"? Really? Pulling in the political views of the founder of a language and claiming that they inform his language design as part of a grand conspiracy against Rust/capitalism? Where are they getting all of this? Free, open-source compilers and related tooling (both of which Rust and Zig have) are already public goods managed by global communities of mostly volunteers
> This future strikes me as a dystopian hellscape, but I have never met an unsafe-language advocate who could explain how this ecosystem is supposed to sustain itself without unpaid maintainers, ideological volunteers, subsidized infrastructure, and endless donations to compiler projects that still cannot protect users from basic memory errors.
How is Rust any different than Zig in this respect? Both are projects largely run by nonprofits relying on communities to promote, maintain, and improve them.
Frankly, that entire "Institute for Type Safe Memetic Research" seems like either an elaborate satire or an account run by genuinely insane people who think type and memory safety are paramount societal issues.
> run by genuinely insane people who think type and memory safety are paramount societal issues
So. Rust evangelists ? :)
But yes, it is wild that people can honestly quote such drivel as evidence of the language and its philosophy being superior.
Each time I try to evaluate Rust, I do so on its own merits. Going online I am rapidly convinced that I don’t want to be in the same room as a large chunk of its userbase. Statements start to sound a bit like that one time I was dragged into a pentecostal meeting.
If you saw the "Institute for Typesafe Memetic Research" and thought, "This is the den of Rust evangelists!" I don't want to break your illusion, because it's much funnier this way. Especially since there are like two people that like Rust on Twitter, and I'm one of them.
> Frankly, that entire "Institute for Type Safe Memetic Research" seems like either an elaborate satire or an account run by genuinely insane people who think type and memory safety are paramount societal issues.
You've been had. Your entire rant means the bait worked.
If this were true the very small but active community of Zig contributors could just fork it and you could all return to the happy times of not using Bun anyway.
Bun became a thing because it provided some specific benefit to js ecosystem. Zig enabled the rapid development. The people who contributed were definitely helpful but they can still choose to help or not and new people will step up too
Why is that even a thing to object to? You're talking as if you placed stock in the bizarre idea that Anthropic would close source the project and start charging for it.
I wouldn’t use language as strong as OPs but it is against the spirit of FOSS for a corporate owner to use a private prerelease version of their open source software.
I think it’s valid to object to. If 1.4 is good enough to be used by Claude, why not us?
So you wouldn't, for example, after doing a complete ground-up rewrite, perhaps spend a few months dogfooding it to work out the worst bugs before unleashing it upon the public, thus maximizing your initial velocity by minimizing the blast radius and support requests and triage during this phase?
Yeah. One single project that they control. Not thousands of other people's projects breaking, I'm sure with a ton of HN outcry over releasing "this pile of vibe coded slop" upon the poor populace.
You could! You could not release a “pile of vibe coded slop” onto people’s machines. There don’t even appear to be any particular advantages to Claude upgrading early. If there are no one has been made aware of it.
The irony. A company building models and tooling to automatically produce code being attacked for using automatically produced code in the very tools that allow people to automatically produce code, presumably by somebody who wants to use their tools to automatically produce code, possibly because they believe that their approach at ensuring that automatically produced code is properly reviewed by a responsible human has to be more thorough than whatever that company does because of course they were going too fast and thus it can't be good
Have I? I believe I've merely chased them around their moving goalposts. When it's closed source, that's nefarious because "they're not sharing" and that's against the whole spirit of open source. When it's dogfooding with a reduced audience, it's "shoving vibe coded slop on people" (this information gleaned through magical knowledge). When that unfounded assertion is called, lo and behold: It's closed source, so bad bad bad! It's called a logical fallacy for a reason.
But more to your point: Do you believe in "guilty until proven innocent"? Do you believe that they're doing bad things with the bun code, and you can't be convinced otherwise in your judgment of them until they release the code?
More to the point, because you've been chasing them around goalposts, you've both accepted that the question at hand is unknowable precisely because the source isn't available.
> Do you believe in "guilty until proven innocent"? Do you believe that they're doing bad things with the bun code, and you can't be convinced otherwise in your judgment of them until they release the code?
Hell yes, and anyone who trusts one of the AI labs for anything important is insane.
Whether it's their initial mass piracy and then lying about it, dealmaking with the US government, or continually shifting opt-out lines on what they are and aren't training on, they haven't earned the trust to skip the "but verify" step.
Their economic incentives are too transparently aligned with ends at any costs.
You're running a closed source piece of software (claude code), running on an effectively closed source piece of software (bun), both of them updated daily by AI psychosis bros.
At this point, charging is the least of your issues.
It may be available to us, in the form of a git checkout of their public repository.
It's true that we don't know exactly which, and whether or not there are any other changes added on, but that is the case for every single release of Claude Code that has used bun.
It's probably not. I tried to extract the commit hash from the version of bun packaged in claude code. the commit hashes from previous versions resolve, whereas the commit hash for the current 1.4.0 isn't available.
from strings:
bun-v1.4.0
f6d0fcd24abd48061873c2f1a6fb2a67eee487b8
Upgraded.
Welcome to Bun's latest canary build!
This build does have a different way of identifying itself than earlier builds so it's possible this string isn't correct.
(In contrast, earlier builds that I have locally have commit IDs that can be found in the public repo). I don't think it's particularly damning for them to vendor a canary release, mind you.
> The most recent release of Bun on GitHub is currently v1.3.14 from May 12th, so that v1.4.0 version number in Claude supports them shipping a preview of a not-yet-released Bun version.
> And so, the FOSS project "Bun" silently dies
There’s no implication that it’s because of the switch to Rust.
> The objection isn’t to the language. It’s to Claude using a version of Bun that is not available to us.
I was responding to your GP comment. For weeks, it was uproar over the blanket AI move to Rust and now it’s this reason. That’s why I said the goalposts are being moved.
That seems illogical to me. We’re only allowed to have one objection to a project and once that’s used up we can’t air another? FWIW I don’t think people have forgotten the original objection either!
You can; it feels contrived and very social justice warrior/anti Anthropic (which on HN is in of itself almost a meme now). The main reason was because of the blanket AI move which I could understand.
I think your perception of events is pretty heavily affected by personal bias here. Objecting to a hasty AI rewrite of an entire runtime and objecting to violating the spirit of FOSS is “very social justice warrior”?
Please re read your original comment. AI rewrite is one thing and objecting to FOSS/non FOSS is a new argument, anti-Anthropic etc is moving the goal posts. The main argument was the blanket rewrite to Rust using Claude.
Now, /you/ are trying to move the goalposts into an entirely different argument.
Very likely it’s just anti Anthropic altogether.
Like I said, a meme.
Anthropic hasn’t done anything wrong but if they move a single inch then people will complain. Perhaps it is just a preview version?
Airing two entirely separate objections to a project is not “moving the goalposts”. The original objection still stands! You’re using a phrase you’ve heard in an inappropriate context.
I’m sorry but this is a nonsensical debate.
> Now, /you/ are trying to move the goalposts into an entirely different argument.
You said something and I responded to it. That’s invalid too now? There can only ever be one single objection in a conversation? I’m not permitted to react to the things said? Like I said, nonsense.
People are now saying poor communication because the Bun creator was not able to see the future and didn’t immediately flag his draft rewrite as the next big thing when he started working on it.
> For weeks, it was uproar over the blanket AI move to Rust and now it’s this reason. That’s why I said the goalposts are being moved.
I'm just one person though, and have no problem with a move to language X, using tool Y, who cares?
For "goalpost are being moved" to be valid here, you have to be able to point to someone saying one thing at one point, then same person putting a different target later. You're folding a huge group of people into one person, when that's not really accurate to do.
My overall larger point (maybe poorly stated) was that unless you're engaged specifically in a 1-on-1 conversation with someone, accusing a whole community of "moving the goalpost" makes no sense, there is a whole host of arguments and points being made in different directions all the time, by different individuals.
I see what you are saying. My comment is rooted in the fact that different people are foregrounding different objections to Anthropic/Bun, and taken together it looks like whatever launches, someone will find a reason to be upset
Already did, a few comments up. Happy to go through specific objections again if useful. This particular comment was about thread-level dynamics, not a verdict on any one objection’s merit.
An interesting tidbit is that large parts of the original Bun source code was a line-by-line port of esbuild from Go to Zig (mentioned here: https://bun.com/blog/bun-in-rust), tbh this lowered my respect for the project a bit (a line-by-line port simply isn't as interesting as original work), and it might also explain the subpar Zig code quality (a line-by-line port from Go to Zig simply won't result in idiomatic Zig). It also might explain why porting from Zig to Rust was done 'on a whim', the actual source code (and the idea of 'original work') never seemed to be all that important to the author (and I wouldn't be surprised if the project does more language-hopping in the future heh).
I read your link, written by Bun's author and totally get his thinking.
In the current world of cyber weaknesses everywhere, infrastructure must be solid and rust is a better choice than zig for something like bun.
In other words, bun is not a demo of zig programming that happens to do useful things. Bun does useful things, and must do them securely. That is its number one priority, language is secondary, inasmuch as it helps doing useful things securely.
I don't think you can claim your code is secure, or can claim anything at all about your code, if you haven't written the code and have no idea what's in there.
Rust protects against a rather small group of memory error, if and only if the unsafe sections are actually correct. And nobody knows if they are correct or not, plus there can be millions of logical errors that can be exploited.
See how many CVEs uutils has… quite a lot for a supposedly secure rewrite of GNU coreutils.
I don't think the GP had anything to do with the language change itself. More that it marks a clear point of Anthropic taking ownership and governance of the project in a less open direction.
My personal feelings about the matter is that having an LLM rewrite the entire thing as an experiment and then just going with it a few weeks later kills any incentive for a community to build up around it. It's a clear signal that every basic aspect of the runtime can change on a whim.
I don't care about meh Zig being rewritten to bad Rust if it does the same thing, but taking what is presented as" look at this funny experiment I did" and then taking that into production with barely any announcement is what kills off the interest to me.
Bun has been a great ad for whatever LLM they were using but the cool factor is gone now, and that's really what set it apart from basic NodeJS in my mind.
> taking that into production with barely any announcement is what kills off the interest to me.
Did Bun v1.4.0 release weeks ago and I missed it? I would call a formal release the point that it goes "into production", and I think dogfooding it via Claude Code is yet another form of testing Bun-in-Rust before the latter goes to casual users.
Which community specifically though? The overwhelming “user” community would be web developers and people writing JS/TS, right? Not zig/rust developers.
There were very many open pull requests from the community that were all invalidated overnight for something that same community was assured was merely an experiment.
The normal process would be "hey, this experiment is going well, we've made this plan, come help us shake out the new codebase for the switchover in X time." None of that happened. There wasn't even an announcement, just a silent commit that trashed hard work from hundreds of community members.
None of that is needed. Nobody benefits from all that time wasting bureaucracy/corpo speak. Bun is quick to deliver new features and bug fixes. With this change, the hope is that'll only get faster.
All those PRs can be fed thru Claude and converted to rust and then manual polish can be added.
Bun is riddled with bugs. That's what moving fast and breaking things gets you. It gets you famously bad codebases that are nightmares to work with and slow you down over time as your sins catch up with you. Vibecoding is not enough.
Are you interested in the discussion that was taking place before you popped in or are you just here to get outraged that something you clearly identify strongly with is getting criticism for making poor choices?
"Because the discussion was interesting" is why I care.
Developer community. "Open source" historically implied that an interested developer might hack on the code and submit their changes. But if the entire code-base is rewritten by the maintainer every year, then there's no developer community.
It's like a couple of languages I know where there's still one real owner, and there's no real review, and PRs are unlikely to be merged, even with review: They might be open source, but it's more a source visible thing, because you are never going to get a change in, and the language will change directions at the creator's lone whim. The best you can get at times is "I didn't like your PR, so I implemented the feature you tried to add completely different". Typical community killers.
The language an application is authored in does not matter to me, as a user. I care that it is widely-used (safety in numbers), that it works, and that it is fast.
It's cool that the Zig project exists, but I'm unlikely to ever use Zig so that’s sort of orthogonal to my interests.
> Why does changing to Rust kill the project? I don't understand the point here.
I'm concerned that the complete rewrite in an entirely different language is not a sound technical decision and instead is a ploy to shed copyright claims from past contributors.
Now, based on comments from this thread, the formerly FLOSS project is somehow granting special access to a corporation that apparently is invested in going way out of their way to push implementations that consume the complete rewrite before the world has access to it.
I for one won't be touching Bun. This doesn't pass the smell test. It feels like a bait-and-switch in progress.
> I'm concerned that the complete rewrite in an entirely different language is not a sound technical decision…
Even if this was a terrible technical decision, it is a good, maybe even unavoidable, business decision. And I don’t think moving to Rust was a bad technical decision at all, given Zig is unstable and constantly changing, and that it’s not memory safe, which is a big problem for something like a JS runtime!
The reason it’s a necessary business decision is that Bun is owned by an AI company and Zig has a policy to not accept AI assisted contributions, making it impossible for Anthropic to contribute to a language that is still evolving rapidly, not to mention the bad marketing of using a language that basically is hostile to your product.
I don't care about the language, but pre-releases the community don't get access to but released (Anthropic) applications do have access to, feels a bit too on the nose after the acquisition.
Ok, go ask those people what they think then, I feel no outrage over a project switching language or merging whatever. But when once-semi-transparent projects become more opaque after an acquisition, I'm starting to readjust anything to the project I had in mind.
That PR is the rust rewrite. That's some time in the past now. As of this comment, there is no tagged 1.4 release. This is the present. Anthropic is using apparently a version of Bun that is not publicly available. This is orthogonal to it being Rust-based, as all Bun releases now will be.
That commit (and main) still purports to be 1.3.14, the version numbers haven't changed. Does that not still suggest Anthropic is using something else?
Come on, "not publicly available"? You know how git works right? Each Claude release probably has the HEAD of main compiled as "1.4.0" until there is a real official release.
I do know how git works and in my experience, while the version number sometimes doesn't get bumped until just before a release is tagged, the version number comes from the codebase. If they're building something that says 1.4.0, then they have a codebase that disagrees with ours.
Where is the previous version referred to in the codebase? I'm guessing that would be the place to look for changes.
If you can't find an update at that place in the codebase saying 1.4.0 you can ask where it is. It seems after doing that and not receiving an answer would be the appropriate time to start making the claims that people are throwing around.
Anthropic changed nothing since I wrote published this post a few hours ago - I updated my post to mention Bun canary since it was a point of confusion here on Hacker News.
It's largely just what jarred is willing to accept this week afaik or not, and they did put the bun 1.4.0 version bump in the changelogs for claude code a while ago, over a month almost.
Though most will be forgiven to not reading it since well it's all AI anyways. I don't know how I feel about all this yet, maybe someday.. ooof
Maybe I’m taking crazy pills, but I’m still stuck on “why the hell does a TUI need to run in terminal React by way of JavaScript”
The fact that Anthropic felt the need to buy a runtime so they could make their TUI better speaks more to the quality of engineering than anything else IMO.
If rewrites are so easy, why not rewrite CC in a native language? Would’ve been a hell of a lot cheaper.
It largely works and it's a massive business success. This is the classic engineer asking the 'why this technology?' to what amounts to a business question.
They chose it early on, it works, and it makes obscene amounts of revenue. End of story. That doesn't mean it was the "greatest" choice, or has a perfect technical architecture.
Rewrites are never easy, even the bun rewrite. But a non-UI developer tool with a rigid API surface contract (and associated tests) will always be easier to trust after a rewrite than a partially tested UI tool with ambiguous functionality.
>It largely works and it's a massive business success. This is the classic engineer asking the 'why this technology?' to what amounts to a business question.
Your counter argument would be valid for a 2000 or a 2020 business decision about some tech stack.
But the whole point of their product is that it supposedly nullifies such "business" concerns around the use of technology, by making it cheap and fast to build whatever you like automatically.
That they wont, or worse, couldn't, speaks against that.
>2. Rewrites and/or writing something in a native app or program is harder and more time consuming
Why would it be harder and/or more time consuming rather than the opposite? It's like having full specs and a full test-suite to match against the result you want.
> I just don’t see how one can say that building things reliably good is easy now when the company providing these tools can’t even do it well.
I don't know how you can't see it, to me it's blindingly obvious: risk aversion.
Let's say the risk for a problem is 1%; hell, let's put it at 0.1% even. For a company at this scale even that amount of risk is too much.
I trust Opus/Fable to drive prod database migrations and backfills. I don't trust it with our financial ledger. I trust it with part of the infra. I don't trust it with backups. Etc.
You and others are arguing against a premise that nobody defended, namely "Claude can rewrite everything, for free and with zero mistakes". A bit of a straw man, don't you think?
And that's not even touching the fact that writing a GUI app is difficult for LLMs due to difficulties in it getting feedback and a "feel" whether it delivered what was asked (though I know people are working on it).
> I think I am willing to take it as an axiom that a native version of CC would be superior from a user perspective. Performance, etc.
How does that follow, and from where? I never once noticed any visual jank/lag in the TUI; not in iTerm2, not in Kitty, not in Alacritty, not in WezTerm and not in Ghostty. And even if we exclude those two, me and many other devs are quite fine with a TUI and don't miss a GUI program for everyday coding.
Not saying that our preference is superior -- but it'd be strange to blatantly claim: "for dev purposes, GUI > TUI/CLI".
Going to give a short reply to one point because I’m about to go to sleep (I try to make an effort to be honest as to why I’m not fully engaging with the entire comment) but re: strawman, I don’t think so. When Dario Amodei is saying SWEs will be replaced soon [0], I think it follows that then he believes Claude can write a native app as well as a native app dev.
> But the whole point of their product is that it supposedly nullifies such "business" concerns around the use of technology, by making it cheap and fast to build whatever you like automatically.
This is a spectrum, it's not just 0% vs 100%. Even Fable frakked up a few things really badly in my professional work (though to its credit after a very detailed 2h chat it self-corrected and fixed all the blunders).
I would also challenge "fast" -- Fable (and I assume Mythos) are wicked fast and efficient and even they can't compensate for f.ex. slow recompilations or test suite reruns or security scans, linters etc.
Reminder that the Bun's Zig-to-Rust rewrite took 11 days with dozens of agents working 24/7 and the author put the cost they'd pay (if they had to pay) at about $168k.
Billions of dollars of annual revenue go through Claude Code, and the people who work on it must be a lot of millions in headcount.
The time matters a fair bit, it's probably time someone can't spend breaking things in the name of new features, but if rewriting the stack had even a tiny impact on retention or driving higher usage, it would pay back that $168k.
It's going to take an order of magnitude longer though, delaying any of that revenue significantly. I'm sorry, but we're talking 11 days here. What does "maintainable" even mean with impossible time-scales like this now!?
True on the premise, remains to be seen if that's what's going to happen in practice.
In my work I have Fable/Opus add bespoke linters and tie them to verify/precommit tasks (including in CI) so nothing of the reworks and 15+ initiatives we have in flight ever regresses.
Some discipline will remove that worry of yours. It's not nice to immediately assume that the rewrite's orchestrator (Jarred) did not use discipline. He even outlined a few false starts.
You might be surprised. Runtimes can be easier to test than UI for AI, and the bun rewrite was almost line-for-line translation, whereas CC likely uses many more libraries that cannot be ported directly.
>Reminder that the Bun's Zig-to-Rust rewrite took 11 days with dozens of agents working 24/7 and the author put the cost they'd pay (if they had to pay) at about $168k.
For an entity like Anthropic that's not even the cost of a single developer for a year. It's closer to what they pay a chef on premises.
That the showstopper for a better Claude agent is that they'd need to pay $168k or event $1M or even $10M in costs, can't be used as an excuse.
Lets see what happens in the future. From my experience cost of maintaining this amount of shitty code explodes pretty quickly. We will see in a few years if SW development in all phases using agents is that much automated and easy as people now predict.
I didn't claim that the cost is the prohibiting factor at all. Obviously they gave Jarred free Fable access and to do as his pleases. The cost was an FYI tidbit and nothing more.
What I argued was that you seemed to have been arguing an extreme point i.e. LLMs can one-shot stuff in any PL and that it does not matter in what PL they'd rewrite Bun.
Well, I never said anything about one-shotting it.
What I said is, those AI companies push LLMs as the replacement of programmers, that can do everything code-wise, say their programmers "don't write code anymore" etc.
So how come they can't have the LLM write something better than "react for cli" for their flagship agent product?
My only half-decent guess: they deem it too big and risky and believe they'll lose revenue while working on it and ironing out remaining kinks.
Claude Code is likely not well-specified and it's a product of rapid iteration and now nobody really knows how the whole thing works. LLMs don't do well when requirements are muddy.
It has to have been purely a marketing move. There's no other way that acquiring a software product for millions and then completely rewriting it makes any sense.
Maybe it's one of the cases when techies call the shots?
I can understand people being more sold on Rust compared to Zig -- there are legitimate differences on the memory safety front and I can see how people will prefer one or the other.
Plus I believe Jarred (Bun's main dev) went out of his way to explain why he chose Rust over Zig in his blog post.
Of course the marketing angle might indeed be the explanation; not arguing against that, I simply followed with interest and Jarred seemed very reasonable to me.
The rewrite makes sense, it's all their dog food at that point. It's the acquisition that doesn't make sense. Why didn't Anthropic just rewrite it themselves?
> Reminder that the Bun's Zig-to-Rust rewrite took 11 days with dozens of agents working 24/7 and the author put the cost they'd pay (if they had to pay) at about $168k.
Does anybody really believe that it only took 11 days, one engineer and $168k in tokens?
> by making it cheap and fast to build whatever you like automatically.
Cheaper, but not free (if you don't buy into the marketing promises too much). The bigger the project, the bigger the cost, even with a discount.
At the same time, the early versions weren't very good and you can be sure that any rewrite will also need to be similarly iterated upon until it is also good enough and polished.
If you do that and don't spend enough effort on making it be something polished --> your competitors have a better product and you lose.
If you pause feature development to give enough effort to the initiative, you don't get to add new features quickly enough --> your competitors have a better product and you lose.
Maybe their priorities lay elsewhere, like how I've noticed that the desktop app version of Claude Code has gotten both faster (no 2-4 second lag when switching conversations), more stable and usable over time, to where I enjoy using the models because of it, not in spite of it (though not that they haven't had bumps along the way, like that one cache invalidation issue, or how people didn't like the auto accept timeout thing). I don't doubt that you can get pretty far with gradual patches and improvements, instead of only big rewrites.
Honestly it's really cool for me to see Kimi having their own CLI too, same with OpenCode, Pi, Hermes (well more of an agent than just a coding harness but you get the idea) - there's so many competing solutions out there, each good or bad in unique ways.
Just wish we'd see similarly many GUI solutions, for now OpenCode GUI seems like the one I've settled on (cross platform and supports most models), though it's not exactly ideal either (feels a bit barebones, especially in regards to sub-tasks and progress/plan tracking, even ZCode seems a bit better in that regard, it was actually surprisingly good after they pushed out some updates).
I don't think they bought them just for the claude-code gui harness as it is now. it's to have strategic control over some software runtime they can use to do other things related to verification, deployment, and end to end value delivery. Same reason other companies are buying up dev tools.
Yeah it was a little tongue-in-cheek--I think the estimate I saw was over $100M for bun, which would have been enough to pay Donald Knuth to rewrite Claude Code, let alone AI.
By the same argument, why does it matter from the technology stack side? It doesn't just nullify the business concerns - it largely nullifies the tech stack concerns. Your preference doesn't matter if you aren't touching the code and the product works for your user base.
> But the whole point of their product is that it supposedly nullifies such "business" concerns around the use of technology, by making it cheap and fast to build whatever you like automatically.
Eventually? I am sure they would agree. Currently it's you (and lots of people like you) who are doing the supposing, not Anthropic.
They succeeded in spite of their tech choices. Their model outshone it, which is an extremely rare thing to happen and not something they could've counted on. In any other timeline they could've/would've been hurt by their choices.
It's like "why did you go all in on buying scamcoin 3.0 as your investment strategy?" -- "I 5xed my money! End of story! It was fine!"
As much as an enthusiast dev like myself hates it -- this is innately true, way too often.
I am 46 y/o and still excited to code and solve problems with code and I still have trouble to admit to myself sometimes that people make dozens of millions with PHP and the tech hardly matters when you can throw bodies at the problem (and when that throwing of bodies at the problem actually solves it, of course).
> I still have trouble to admit to myself sometimes that people make dozens of millions with PHP
Or many billions. eg. Facebook was originally written in PHP.
As a 52 y/o who cares deeply about software development as an art I don't have trouble admitting that the tech hardly matters relative to the economics, that was obvious to me very early in my career.
I have just never really cared because there has always been a path where you can have a decent career being paid to work on and with good technology in spite of the fact that the technology wasn't important to the economics.
I do fear that the rapid adoption of LLMs will probably cause the path I took to narrow considerably. There will likely be less companies willing to pay people to work on elegant technology when they are all competing against endless code generation machines (and this is assuming software companies can exist at all in this future). But at my age that's more of a concern for younger people than me.
I hear you on the worry, I have the same (and probably so do most devs even).
But IMO the endless churning of code will slow down, if it has not already. Quantity does not equal quality as we know, it even erodes it. There are already consulting companies that are "vibe-code fixers".
I am also not sure it's about "elegant" code. What we might call elegant has multiple measurable axii f.ex. well-isolated effectful code layer so you can easily static-code-check it, domains and enforcement of boundaries between them, bespoke linting to enforce business processes and standing code discipline, and many others.
Apply this reasoning to any other industry. Yes the average person is not the judge of the quality of a doctor or engineer. That doesn’t invalidate it. You want a doctor who cares about medicine , not whatever will accomplish a business goal.
The choices were clearly (far) less important than having the best model and a good product that was way ahead of the competition.
However, that's not the same as the technology choices not mattering at all. As others have mentioned the product is buggy, and it appears Anthropic are struggling to continue to release new features within the existing architecture.
That's also not to say that Anthropic made bad choices - there's always going to be a tension between building quickly to capture the market now vs moving slower and building something more maintainable in the long-term.
Eh, the rendering of Claude Code is genuinely such a mess. I have quit claude code over it because when used as a terminal in PHPStorm it sometimes gets so bad that it becomes hard to use.
This isn't a minor nitpick, it's a pretty major UX issue.
Not saying it's like a massive business downside because I'm just one of a few users, maybe this affects their bottom line a little bit, but probably not by much.
Regardless, switching to pi has been a nice breath of fresh air. It just renders well and smoothly and handles terminal resizes well, which is especially important when used in a terminal window in PHPStorm.
Truthfully, the terminal in Jetbrains IDEs just isn't that great. It's gotten a lot better with their rewrites (yes, plural) of the last years, especially on Windows, but it can still be pretty dodgy.
It is rarely the case that technology choice is the make-or-break when it comes to whether a product is successful and achieves widespread adoption. Some choices are less ideal than others, but at the end of the day if you manage to make something that people want, the rest won't matter much.
What do you mean in spite of their tech choices? When have the tech choices ever been an issue in the lifespan of Claude Code? From where I sit, it seems like their tech choices enabled them to create an industry-defining product.
I mean people are using Claude Code because of their underlying LLM - they'll put up with Claude Code. There's no other real option to get Opus at a reasonably affordable price without CC.
Most people would choose to swim a lap through a pool of pee to get a billion dollars at the end. The pool of pee itself wasn't the once in a lifetime opportunity (for most).
I have been working all day every day in Claude. I loathe their bug-ridden UI. Every release is a new crop of bugs, sometimes the old ones get fixed, usually not.
Any kind of scrolling back, copying text, using their menu system - basically anything that isn’t typing characters has had/still has unaddressed bugs.
OpenAI shipped a competitive model and I’m over in Codex now. I have yet to hit a bug.
If you’re holding the SOTA crown, people will put up with your buggy mess. As soon as that crown slips your pile of trash becomes a huge liability.
So weird that the same exact people telling you that programming careers are now obsolete are the same group who haven't been able to fix screen flickering bugs for like a year...
The criticism didn't appear to me to be that the solution didn't work, just that many of the working solutions we are selecting are dangerously overcomplicated due to shortsighted decisionmaking. The benefits of throwing redundant stacks of abstraction atop each other in terms of time to market are questionable, and obviously absent in every other metric.
So, you have a vibe-coded TUI which happens to work, and then, as a workaround you vibe-translate its engine to make it more performant. Where does that leave you ? Basically, fully dependent on AI to fix whatever breaks. Workaround on a workaround is the way I see it, and it aligns with the AI design mentality in general. For a variety of usecases, this might still be a win in terms of overall cost. But, for software that is intended to be built to last, I dont see this approach working out.
That does seem to be the way many use it. I'd be very surprised if they didn't have to insert a rule to prevent opus from constantly asking why they didn't just use ncurses. I just asked sonnet for design options for a tui to onteract with llms to perform sw dev tasks. After describing the tui it immediately suggested ratatui and crossterm as the tech stack. I feel like they must have ignored even the advice of their own llm to come up with this solution.
Edit, the sonnet question shouldn't be taken as proof, it knows I'm a rust dev.
This reply makes no sense in this context, though. Sure, it exploded in popularity based on whatever random tech choices were made. But now, when apparently they're deciding there's a problem there, why unleash $150k of tokens to rewrite a JS runtime wrapper from Zig to a million lines of rust, rather than simply rewrite Claude Code itself to rust?
They probably should rewrite it in Rust, but also, I think the Bun guy wanted to rewrite it in Rust because he thinks Rust is a better choice for Bun, independent of Bun being used by Claude Code.
This speaks for the benefits of JavaScript runtimes like Bun and Node.js. JavaScript is a dynamically typed language which makes it a good choice for explorative programming. It is a Lisp in sheeps' clothing.
Programs which need more stability and performance than exploration are better done in statically typed languages like Rust. Therefore Bun is a platform for JavaScript programming, but itself is written in Zig or Rust.
Massive business success? I don't know the financials since they're not published, but google says the acquisition cost low hundreds of millions. So they could throw away the code and rewrite it.
This is the “eating yogurt with a hammer” argument. Yes, of course you can do that. Yes, the yogurt gets eaten. It’s just… you see someone eating yogurt with a hammer and it’s hard not to wonder wtf is going on.
...while proving their technology has finally reduced these questions down to what's best, instead of "how much effort will it take to be good enough".
If you have unlimited access to the magical development tool, then why would you not?
This is a confusing comment because it’s the exact argument you would present against rewriting Bun to Zig, but you are arguing for one and against the other.
> It largely works and it's a massive business success.
You can make anything work when you have enough money to buy and radically change the entire runtime you’re relying on.
One must suspect that if they did not have insane amounts of money to burn, they could have tried other approaches to fixing the problems. Maybe engineering, perhaps.
As an industry we are responsible for making our part good. So yes a business can succeed in spite of bad tech choices, but that doesn’t make it good tech.
For a company that solved coding and doesn't need any software engineers… why spend money to acquire a runtime rather than ask claude to rewrite it in assembly directly and be done with it?
Could it be that they aren't being entirely honest?
This is far less so in this case because this is thier hot path. Everything runs through it and tens of billions in revenue depends on it. It needs to be as fast and solid as possible
This is a useless post-hoc rationalization. "It worked out, so it doesn't matter". You're trying to galaxy brain yourself into ignoring the obvious conclusion.
The point is that if you were starting a new TUI LLM harness today, you would basically use CC's architectural decisions as a guide for what not to do.
No, it's because they wanted a unified pipeline in claude code, claude app, and their website. All of them use more or less the same claude features (claude code has artifacts, claude website has "Ask User a Question" tool, etc.).
Much less fragmented compared to "write the app 3 times in 3 different languages".
I think it makes sense that when you've outlawed competition for many/most users of your product's matching service that you would cheap out on it if you were maximally extractive and took no pride in your work, sure.
But the "coding is mostly solved" narrative kinda doesn't match right? If good, correct, high-performance software is like, free now? Wouldn't you want it to be slick as hell, really reliable, all that? Even a little breakage costs a lot of money at that scale and pricing, it would be better than a wash if you put the magic code thing on the case.
"Claude. Do all employee work. Make no mistake. Notify in slack when revenue is double."
I never knew that running an interactive program in my terminal would absolutely rinse my CPU and battery but that's what Claude, OpenCode and Ghostty have colluded to achieve. Even when the laptop is asleep overnight it's practically melting.
I'm sure there was some logical reason for shoehorning web technology into this stack given that we have a good 40 years or so of experience with interactive terminal programs that use curses/ncurses, alongside emacs, vim, almost the entirety of MS-DOS, and so on.
The fundamental problem with all Js based apps is how they are very single threaded.
With js you get 1 thread at 100% utilization. Power usage and heat scale non-linearly with cpu utilization and 100% utilization on a single threaded js app means you will have ui lag. Other languages like golang would split work across 8 threads and have 8 threads at 20% utilization and this would result in less power usage. Claude Code would have been better off performance wise being an electron app because it would be offloading rendering to the browser and gpu.
Also, the architecture of Open Code is actually a lot better here than Claude Code. ClaudeCode does everything, including rendering in a single thread and it's all in js. OpenCode has a zig based tui renderer it offloads that work onto.
But I will also say these coding agent tuis do get unfairly maligned because they launch subprocesses and those subprocesses tend to be expensive. If you are using Rust analyzer with claude code, it's rust analyzer that's causing the majority of your problems.
No, the fundamental problem of these apps is that they are, for no reason, pretending they need a high powered game engine rendering loop. They don't. It's a text printout of history with some hotkeys for mode switches and such. "rendering in a single thread" should never be an issue because it should never be "rendering". It needs to stream text to stdout. That's been a solved problem for 50 years and now it takes 2GB of memory to be done poorly with broken scrollback.
Drawing to the terminal / rendering / whatever, this is all arguing semantics and very uninteresting and not insightful.
> they need a high powered game engine rendering loop
Don't believe the bs on twitter. Claude code source was leaked, there is no high powered game engine rendering loop.
> It needs to stream text to stdout
These apps are doing real work taking text that is streaming in and doing syntax highlighting, calculating diffs, and rendering markdown. If the work was split across threads they would not use anywhere close to as much power and there would not be a slow ui.
If you think this is actually nothing, prove it. Put the code up on github that shows taking a constant random stream of markdown, code, and diffs and displays it in the terminal can be done cheaply on a single thread.
The reason the computer gets hot and uses more power is because the cpu is getting close to 100% utilization.
> These apps are doing real work taking text that is streaming in and doing syntax highlighting, calculating diffs, and rendering markdown.
The first argument is that these are expensive operations. They are not. And the second argument is the assumption that these are desirable things for an agent system to be doing. That's a personal preference but, personally, I don't want them and would appreciate a way to disable all of that to reduce CPU use.
The argument is that doing it all on a single thread will result in high cpu utilization and that is what makes the power usage spike and the pc feel hot. Thats it.
A lot of people go “js is bad” reflexively and they are right for the wrong reasons. Its not because js (specifically v8) is slow. I have many websites and web based apps open and none fuck up my laptop as hard as claude code.
Early 2000s tech could absolutely handle LLM agents as a client. They output like 1-2kbps and even dial up modems would have plenty of capacity for other traffic.
The UI itself requires laughably simple tech. The idea that a markdown renderer that can produce HTML at 50MB/s would use much CPU to process incoming hundreds of bytes per second is insane. CPU should be idle even if doing that constantly. Nevermind that between turns it has nothing to do whatsoever and should use zero CPU at all.
My Turbo Pascal programs could calculate and print to the screen faster than could be read, on a 486. With DOS however.
I picked the P90 because I remember running Linux ~1.0 and/or NT on it, with real multitasking and services etc. Those soaked up many of the cycles.
Another story, around Y2k/Win2k was asked to write a C program to record all the files/sizes on the C: in to file. Then something would be installed, my program run again, and the results diffed. Despite thousands of files the program was done before the enter key came back up. Boss told me that he thought the program was cheating.
That’s just how fast modern computers are these days, I said. When running C code anyway. That perf is still available today, compare astral’s uv to slow competitors. Just takes some investment, though probably less when boosted by VC bionics.
"The most amazing achievement of the computer software industry is its continuing cancellation of the steady and staggering gains made by the computer hardware industry."
The heck? It does all that rendering for a tiny fraction of the total amount of time that the TUI is running. The streaming is IO bound, there’s no way that it’s outputting nearly enough text to tax the CPU that much.
> If you think this is actually nothing, prove it. Put the code up on github that shows taking a constant random stream of markdown, code, and diffs and displays it in the terminal can be done cheaply on a single thread.
Put up the code and prove it. We already know exactly how fast golang is in comparison to nodejs on basic numeric computations, it's roughly 40 to 50% faster.
That’s not really a big issue. In major OS like the BSD, SMP implementation are not that old. If we can have a full OS running in single core mode, we can have an application being performant too. I’m currently running OpenBSD on 4 cores and it’s basically 99% idle.
It's basically idle because it's not doing anything. If you are streaming in markdown and code and then doing syntax highlighting on this code in real time, then rendering it on the screen you are doing actual work.
It's also all cpu bound work. The majority of the stuff on your screen is being rendered by the gpu.
> If you are streaming in markdown and code and then doing syntax highlighting on this code in real time, then rendering it on the screen you are doing actual work.
You are really, really not. Not at LLM inference speeds at least. Frontier models output maybe 200 bytes per second on the fast end. I guarantee you that idle BSD box is still processing more than 200 bytes of whatever at any point in time. Streaming 200 bytes of LLM output through syntax highlighting, markdown rendering, and diff formatting, will still leave the box basically idle if done correctly. Claude Code has not done it correctly.
Of course I have. If I see ghostty constantly consuming the most energy and helping reduce my battery life to barely 2 or 3 hours, the first thing I'm going to do is switch terminal to see if I can improve that situation. The built in terminal and WezTerm have been fine and I've had much more reasonable battery life since.
This does not even speak to it pegging my CPU and keeping the fans running on full blast even when the laptop is supposed to be idle overnight.
This seems a suspicious. How do you measure the CPU load of Ghostty? Is the measure/reporting method just attributing the cpu load of the commands/programs you're running in Ghostty to Ghostty?
You could test this by running "yes > /dev/null" in Ghostty. In Activity Monitor on my Macbook it shows `yes` using 100% and Ghostty using 0.5% of cpu.
If you're looking for a non-ghostty recommendation (not that I have anything against ghostty) I use alacritty + zellij and it works fantastic. It doesn't seem to impact battery, I certainly get good battery usage on both my work and home laptops.
I've messed around with pretty much all the fancy new terms to varying extents. Ghostty, wezterm, alacritty, etc. And I'm all in favour of people innovating in this space again. But at the end of the day, I always end up back with xterm. It's reasonably lightweight, runs and is packaged absolutely everywhere, I never have to muck about with termcap files and/or $TERM on remote hosts, and I've never had it break, crash, or exhibit any kind of bug or strange behaviour in over a decade of using it. The only TUI that has some quirks in xterm is Emacs, but Emacs has weird quirks in every term I've tried to run it in, and different quirks in every case somehow, so I just chalk that up to Emacs being weird. I'm sure xterm has some bugs buried in it still, but I bet all of them are in codepaths that are almost never reached nowadays, or at least are extremely niche. It does lack some features like ligature fonts(I just decided not to care), sixels and similar graphics things(again, don't really care) and panes/tabs/yadda yadda(tmux or screen or whatever you like can do all of that anyway).
Never had to dig through the xterm bug tracker to figure something out. I don't even know what version I'm running, or even what the versioning scheme looks like. I haven't changed the configuration since the first time I set it up. It just works.
Same. I really want to file a proper bug report for this but I haven't been able to really dig into the details and the last thing I want is a "ghostty is a cpu hog" kind of report without useful info on how to debug that.
> why the hell does a TUI need to run in terminal React by way of JavaScript
Because React is the only UI framework that takes the problem seriously. Everything else is stuck in the dark ages.
How HN gets this so badly backwards I'll never understand. Everyone on this site talks a big game about "there shouldn't be so many competing tech stacks, why can't everyone work together on one framework that does things right", and then as soon as that framework actually appears this site hates it more than anything.
I recently saw a blog post [1] about a famous Haskel shop moving away from Haskell to Python because the iteration speed with LLMs was just that much better. There is so much React in training data, TS compile times are minimal compared to Rust and similar.
I suspect user facing/fast moving code (UX layer) will move to dynamic systems with fast iteration times. Infra layer will move towards safe systems level environments like Rust. I'm not sure where Java/C# lands in all of this - it's kind of the middle ground between these two worlds but the tradeoffs change drastically with LLMs - my gut feeling says that TS/Python is good enough for UX work and Rust is better for systems work so it gets less popular going forward.
That blog post doesn’t make sense to me at all. The author is going from full modern Haskell (since he mentioned Servant and Beam, you could tell almost every file uses dozens of GHC extensions beyond what Haskell2010 gives you) to Python with dynamic types. He could instead rewrite the Haskell to use less modern type system features and get so much faster compilation speed.
Also GHC has an interpreter. It powers the REPL. No need to compile everything if you’re just experimenting. I do find that in the Haskell world the REPL is criminally underused compared to Python.
And the rest of your comment doesn’t make sense; this shop is rewriting their infra (not UI) from Haskell to Python.
Why would rewriting Claude code, an app which probably has 30-40 (I might be significantly underestimating) extremely active contributors be easier than rewriting Bun, which has fewer contributors and almost certainly also less lines of code?
Probably because it consumes the same APIs originally developed for a web app and the same front end engineers likely created Claude Code. People assume Anthropic set out to create Code as a product and went through a normal design phase. I think it’s more likely it started as an internal tool or someone’s side project and blew up as a product when they released it to the public.
>I have never once heard a lab or professional say “x model can do anything”
Yeah, they "merely" say that they're about to break the singularity in a couple of years, that it's too capable to be safe to release, that it's going to take 50% (or all, depening on the day and audience) of programmers out of work, that it's smarter than Nobel prize winners, that their programmers don't write anything themselves anymore, and things to that effect.
It’s hyperbolic and intended to generalize the sentiment I perceive from others.
Dario Amodei said in January that he expected software engineers to be replaced [0], so I suppose the quote should be extended to “can do anything… a software engineer can do”
And I think we can all agree that SWE is on the more complex end of all white collar jobs. So, my thinking is that if SWE can hypothetically be replaced, so can many other jobs. Hence, the claim the models can “do anything” intending to capture the majority of white collar work.
This, of course, is if you take their claim at face value - which I certainly do not.
Pointless nitpicking that completely missed my point. Software developers are not the hardest to replace, so your presumption that everything else should be easier is wrong.
I'm doubtful that it has fewer lines of code, but even so, it is almost certainly less tricky and simpler code. You could also rewrite it in a higher level and more forgiving language than Rust (e.g. Go) and get huge improvements. The improvements would probably be much bigger than the improvements they have achieved at the JavaScript runtime level.
Yknow, I really didn't mind Claude Code that badly, but subjectively speaking I really do like Codex more after using it for a couple weeks. Feels a bit snappier and lighter weight. I know with OpenAI you can actually use third party tools with the subscription so there's less of a draw to using Codex, but I still find myself preferring it now.
Is this because Codex is written in Rust and not JS? I dunno. I think it's more just "lighter" in general, or it certainly feels that way. It's probably possible to make something with a similar feel in JS, just perhaps not with the big honking mess they've created.
Codex appears to be a mildly complex, somewhat-but-not-outrageously-sloppy Rust program (yes, I’ve poked around at its source — thank you OpenAI for making it more or less open source). It has lots of features, mostly related all the fancy web features of Codex.
Claude Code seems to be an insanely complex program will all manner of cutesy features and telemetry features. The net result is approximately the same as Codex, but it’s pretty common in software engineering to find a simple thing and a complex thing that do more or less the same thing.
As a counter argument - I assume that Anthropic is using AI to write Claude Code.
I've read and heard in videos that Javascript is a pretty good language for AI to write code in. Apparently this is because there is so much training data out there. Also Javascript avoids problems of multi threading and memory management that can mess up the AI in other "more performant" languages.
So maybe Javascript is not the worst choice for writing software fast with AI
I feel like a year ago JavaScript and Python were the best languages for coding agents to use because of their heavier presence in the training data, but I'm not sure that's true any more now.
The latest frontier models are competent at Rust and Swift and all manner of other less widely used languages.
The more important factor is how good they language's compiler is at kicking out actionable error messages, since one-shot code generation isn't as important once you have a coding agent loop.
Sometimes I think that if we are willing to burn tokens and rely on compilers in a loop we should be using languages that can catch as many errors as possible at compile time.
Like Ada or Ocaml or Haskell or something.
Or even require like MC / DC testing or MISRA C verification.
Or even some of the languages that apply Hoare checks, like Ada SPARK or FRAMA-C or VALE or whatever.
I don't have the budget to test how that would work but it seems interesting.
There was a post recently from a guy who used Haskell with AI agents. If I remember correctly he said the type checking did catch errors. The problem was the compiler was very slow, which slowed down the feedback loop and output. I think he switched to Python.
> If rewrites are so easy, why not rewrite CC in a native language? Would’ve been a hell of a lot cheaper.
It was unpleasantly surprised when I learned the hard way that LLMs are not much better at translating than writing from scratch.
The more you look into how they work, the more you see that it doesn't really give them a huge advantage, if the classes are big enough. You can tell them to break each function up and translate them one-by-one, but the errors compound, you can't test most of it until you have a lot done, and in the end, it really isn't much faster (and sometimes it seems to be a lot slower) then just telling them to start over from scratch.
The downside is... If you have a system that already works, you don't want to start from scratch and test everything all over again...
I don’t doubt his expertise, I just am not convinced it’s the right tool.
To me it comes back to the premise I hear a lot from AI hype men (of which I do not subscribe but it’s worth clarifying that I find great value in using it for code) that the code doesn’t matter anymore. I just don’t know how to square that claim with the idea that we’re limited still by JS/TS being easier to use or approachable despite inferior TUI toolsets.
I think Moore's Law and related have made programming sloppy. AI is building on that. There was a time where accounting for memory, footprint, stability, and speed mattered. Your point shows we are well passed that aside from certain areas.
Heck, a buddy and I once chatted about the likelihood of k8s running as the control plane in a prototype autonomous vehicle.
top/btop/htop on the mac are always fun to run and see what's up.
I'm confused as well, could someone who knows how TUIs work explain what's the point of React-style diffing in this context? I thought you need to clean and full redraw if anything changs anyways?
> I thought you need to clean and full redraw if anything changs anyways?
Unless you use an ancient teletype, you don't have to redraw everything. That would make any interactive applications way too slow/flickery.
You can move the cursor arbitrarily in the terminal and start overwriting characters from there. So you need to track state to know what is "dirty" and needs refreshing. Occasionally you issue a full redraw to catch missed artifacts left behind or when the terminal is resized (SIGWINCH).
Cause it works, most users are fine with it, people don't migrate off it because of the codebase, and easier to maintain if the dev team is familiar with code flow.
This is close to the same "why Spotify is a chromium embed?" question. Because it works, and users are ok with it.
JavaScript is very fast and easy for UI rendering. If it works for web apps it’d also work for the terminal. Sure it’s bloated but it’s fine. The dev velocity of JavaScripts is orders better than rust.
Otherwise an idle TUI wouldn't halve my laptop's battery life. Maybe that's an exaggeration but not that much, based on looking at wakeups in powertop.
"I'm using technology I know that will get us there" is not the same as treating every problem as a nail. It's making a practical choice that probably also had time constraints and other factors we don't know.
It's hell to maintain for not much gain (for a use case like this at least). As much as it's become a meme, JS and web tech in general has become extremely portable and stable.
I also don't think Anthropic bought bun to make their TUI better. They could have forked it, they bought bun because it incidentally was excellent for the way agents prefer to work and they wanted to capture that audience.
I don't think it's that kind of maintenance like code.you need to test cross compiling and running on different platforms. I guess js acts like how the jvm is
it is kinda mystifying bc from what i understand their engineering ethos is very much "if it's not working, just regenerate it" (which i completely understand).
i got annoyed by this especially the memory use and non portability aspect of bun so I had claude (lol) and kiro cook up my own agent. it runs on linux, openbsd and even on omnios and esp32. it's just a personal project so there are probably rough edges, but I am using it on my clockworkpi uconsole daily now. https://github.com/mischief/clm
Probably because claude suggested some kind of wack react based setup early on (because react dominates the training data) and it's be blasphemy worthy of termination for the Anthropic employees to question the sacred pronouncements of the llm.
If you think that way I would recommend just keeping away from these topics. It is just useless arguing and speculating about things don’t matter.
I have been trying to keep away in the last couple weeks and it was all win for me. I still come down here sometimes when I am stressed with real work since it is a strong addiction to see “how terrible the plebs are doing”.
If you are relying on live updates to change state in a dynamic language then you are not doing it "surgically", unless there is some other definition that means hitting it softly with a large rock.
Couldn't they have rewritten Claude Code in Rust directly? No more need for a JS runtime, better performance, etc... If their agents can do Zig to Rust, why not JS to Rust?
Well, yeah, it's just good marketing and Bun ultimately doesn't matter anyway, not to the wider ecosystem and especially not to Anthropic. The only purpose Bun had for Anthropic was as a way of getting attention, so that's what they used it for.
In isolation, yes, that does seem like it would have been the better decision for Claude Code, but it also would have severely diminished the value of their Bun/oven.sh acquisition.
Claude Code isn't the only user of Bun (it's probably not even the only user of it internally at Anthropic), and this way they get to keep the Javascript runtime (and other tooling) that their coding models may one day, if not already, prefer to use when given the opportunity. For those kind of apps, you'll probably also eventually find that--what do you know!--Anthropic also has their own cloud offering (instead of Bun being the one to build one) that specializes in running and managing those applications for you. Even if all they get is a community of developers that choose to use Bun over other options, that gives them power and seats at tables they wouldn't have if they just rewrote Claude Code in Rust.
People widely report very high memory and CPU usage.
Not all of the memory usage is the fault of Bun/JS. Some of it is likely memory leaks (holding on to data it shouldn't). However, some of the blame does go to using JS. In Rust you can tightly pack your data if you want to, but in JS you can't have nested structs for example. Every object referencing another object is two separate chunks of memory, each with a header, and a pointer from one object to the other. GCs also use more memory. The overhead adds up.
Building a CLI program in JS is a bad choice, and nobody should be defending this decision. Especially since Claude Code is very much able to write Rust code, and they've shown it can port code. Just port Claude Code to Rust directly.
Why is ecosystem of tools and plugins a bottle neck when they literally own Claude models and as per their boss, code is so cheap that anything us just an English sentence away?
For their work they extensively test using humans with deep expertise
But while marketing they say just vibe code bruh
And here they can't even rewrite CC in rust? Why not! Use 1000000 agents!! Write it in platform specific binary! SAAS is dead, that's what he claimed. So what's stopping him from writing the harness in Rust or C than ReactJS?
> The "General Labor Substitute": He rejects the idea that his employment forecasts are "doom marketing". Instead, he asserts that AI will act as a general substitute for human labor, noting that most software engineering could be entirely automated within 1 to 2 years
When someone says all Software engg could be automated within 1yr they don't mean 'oh use our agents and keep human in loop'
They mean 'AI superior than humans fire all humans and all SWEs will be jobless'
I am not going to reply to you going forwards as I can't speak with someone who lives in a different universe
Maybe I'm taking crazy pills, but I swore there have been very similar comments I've seen as the current top post by weakfish:
> Maybe I’m taking crazy pills, but I’m still stuck on “why the hell does a TUI need to run in terminal React by way of JavaScript”
> The fact that Anthropic felt the need to buy a runtime so they could make their TUI better speaks more to the quality of engineering than anything else IMO.
> If rewrites are so easy, why not rewrite CC in a native language? Would’ve been a hell of a lot cheaper.
It turns out, there's some similar sentiments in the last year ish:
Maybe because the 1st thing any experienced technical person would think about? It's like rebuilding and optimizing the racing track to make F1 run faster.
Perhaps. The thing I was trying to highlight more is comments (particularly disapproving ones) about the intersection of JavaScript (especially React, apparently), TUIs, and LLMs.
I just thought it was interesting. I'm a fan of TUIs, both positive and negative about JavaScript (the modern language is quite nice, given you avoid the historical warts, in my opinion - the ecosystem is unfortunate), and I think the best description for how I feel about LLMs is that I'm bearish. Also Simon is a fantastically prolific and intelligent person though, even though LLMs are not my cup of tea.
https://news.ycombinator.com/item?id=48960912 is a recent comment by someone I also respect related to how LLMs recreate human-like content (Widgets, really), making actual human-created content feel fake.
Sometimes it sure does feel like ELIZA is the main news source these days.
I have ~24 years of experience coding and the LAST thing I think about when opening claude code is "why is this written in react".
Tell you what I sometimes think about though: The fact it has clickable links and complex formatting rules for markdown, the most interactive and highest-quality clickable interface I've ever seen in a terminal, and somehow manages to work. That actually blows my mind.
THEN, I'm reminded that it's written in React, and I think "Huh, guess that does make it a ton easier than using ncurses or something."
Okay and as someone who would rather just straight up use cursor than claude code, I'd rather have my software not crash out on me every 5 minutes. What sort of self respecting dev purposely uses broken software? Even opencode (use it on nonwork computers) is fully better at this point.
It's not disingenuous, claude code has over 5k issues that are ignore plus thousands of more that were just silent closed.
This is a product by a company worth supposedly $1trillion and they can't even make one of their starship products not shit the bad within 5 minutes? These are the same engineers telling us for the last 3 years that coding is solved?
Like it's pathetic, and it's pathetic you're falling for it too. Have some standards, good grief.
You’ve been writing code for 24 years and you don’t know that clickable links are a terminal emulator feature and not a Claude Code feature? Or that “markdown formatting” is just ansi escape codes, and possible with things other than React that don’t bring so many downsides?
It sounds like you completely missed the point I was making: that actually implementing such a highly dynamic TUI application normally requires a significant amount of state tracking and it is significantly easier to write such apps using a functional, descriptive UI framework instead of something like ncurses.
Take it from someone who, in those 24 years, has written UIs in jquery, react and ncurses (and yeah I've tried out Ink and it's great).
"all the downsides that come with that" yeah well, while you're stuck implementing your app in the Best Possible Library, millions of people are happy using claude code and it's crazy useful.
There are fantastic TUI frameworks for Rust, like Ratatui[0] (there are a lot more options, this is an example). You can write beautiful TUIs in native languages, without ncurses or C or C++.
Go has such frameworks, same with C# (which you can AOT compile) and so on. You're not stuck between javascript and C.
Yes I also used Bubbletea. I don’t know about ratatui but honestly I think the hate for react is very blind. It’s not like CC is shipping an embedded web browser. It’s a framework on top of an embedded language that has seen a crazy amount of optimisation.
CC is not even that complex of a TUI. It’s certainly not as complex as many of the GUI programs I use daily. And yet it’s by far the buggiest and worst performing. I don’t understand the desire to make excuses for this. The reason people use it is because it’s the only way they can afford to use Opus and Fable. If Anthropic let people use their subs with other harnesses their market share would plummet.
If they could migrate an entire runtime to Rust why can’t they migrate CC? It’s not as if React is the only way to do declarative UI.
I don't want to edit this to change the narrative, but I wanted to clarify that I'm not not a fan of all of the technologies or people related to this. As far as compan{y,ies} go, though, well..
It's because rewrites are almost always a bad decision. Best case, it's a naive decision made by people who don't know better, worst case it kills the product (who here uses netscape?).
So, from the start, people will be skeptical of a "we rewrote xyz in Rust" because it rarely works out. But there's a lot more to this, in fact it's a little bit loaded with "tech bro" ideas:
- Rewriting in Rust
- Rewriting using AI
- Making terminal apps in JS
- Zig (a lot of people's dear language) is involved somehow
This attracts every single skeptical developer. The only thing missing is maybe blockchain, if that was still cool. It just hits all the "what? why?" spots.
I was already writing a comment, when I realized that what I wanted to write had already been said by the top comment. I suppose that's why comments read so similarly.
All the emotion of speculations aside, how it runs? It boots faster yeah, but what about RAM and CPU usage? Weird dead loop or dead locks?
If it run as good as before or even better, then that's kinda impressive.
I'm a developer so I really don't like it when AI might took my job, but if everyone on this planet could create a software for themselves exactly as how they wanted with just a few simple demands, that will change the world for the better.
Think of it as a democratization of technology. You don't want Microsoft stealing your data? Just ask a AI to write an OS for you. You don't want Google to listen to what you're saying? Just ask a AI to design a phone for you. If one day the AI ended up doing that, it will be the ultimate technology self-sufficient. In front of that, your job security is insignificant.
It is also why keeping the tech open source is that much important. Otherwise, it's still the same old shit again and again, and, you lose your job too.
It's not even about requirements. It's about responsibility. Someone has to take responsibility for the code and the product. Someone has to hotfix a bug that's costing millions of dollars an hour and someone has to be blamed for a bug that's consting millions of dollars an hour.
Not really. The secret of our society is it wouldn't work if people with a controlling interest in things ever faced personal responsibility. Who got blamed for the Iraq war? How much did that cost? The theory is if you tried to blame someone then some future president wouldn't be able to declare war. You don't know how the law works apparently. Corporate law is pretty much the same. The economy doesn't boom if CEOs can actually be blamed for things. You don't blame a "someone" that's what incorporation does. If some code does a booboo just put a $ amount on it, withdraw the funds and move on. The media will focus on the humans because of the drama, but they are largely irrelevant. It doesn't come out of their pockets. A human is already window dressing in this status quo. A LLM has no reason to do the sorts of things that violate such legal protections, be it of a president (none really apply) or a CEO (good luck getting a CEO to take personal responsibility for anything short of outright fraud). If it suddenly goes haywire the law already has a concept of vis major.
The secret is individual humans are already largely irrelevant to our society. That's how we got here. The trend will only continue.
That's why it matters for people to hold the control of the tech, not companies, as I've already mentioned quite clearly.
LLM is here to stay, keep denying the fact won't work. What does is to make the tech so abundant, it flushes the bad actors, such as for-profit AIs, completely out. It's either this, or get crushed by for-profit AIs, pick one.
Anecdotal, but I’ve been getting segfaults in Claude Code. I run inside Kitty tabs, and the entire tab becomes unusable when this happens. No response to inputs at all from that point.
When this happens, a link shows up to report the issue. It’s not clickable (likely due to the segfault), and perhaps more important: it’s encoded, so you can’t see what you would be sending in your report.
Something similar has been happening to me with Ghostty, but there is no error message or link and it only happens when Claude uses it's interactive questions interface.
It becomes completely unresponsive to any input except scrolling. I can't select options or even cancel out.
Same experience I have with bun in general. As an idea, it's the absolute best js runtime by a very large margin, but in terms of stability it's terrible and segfaults 20x as much as node (I base that number on newrelic telemetry)
What makes you think it's a segfault? Does your shell print "Segmentation fault"? If so, you should be back at your shell and you should be able to recover the tab by typing 'reset' + enter (even if you can't see anything as you're typing it).
If nothing prints "Segmentation fault", this just sounds like a hang
I just had this happen today. It was indeed a segfault.
From what I could tell it looked like it was in JS code that had been JIT compiled. I haven't attempted to troubleshoot further beyond setting all my future Claude Code instances to pipe their stderr to disk so that I don't lose the stack trace next time.
I run Ghostty and Claude Code on a work macbook and I haven't seen this yet.
I actually used to have issues with run away memory leaks causing my computer to hang which often required a reboot to recover from. I haven't experienced that in a couple of weeks now. Too early to say just yet but I think its definitely possible that the rust port fixed a bunch of memory leaks that have tangibly improved the experience atleast for me.
Segfaults were a thing with the Zig version. Purely based on the fact it's a line by line translation of the Zig code to unsafe Rust, all the Zig code that caused segfaults is going to also cause segfaults in the Rust version. The Rust code won't fix it until they get to the point of refactoring it into idiomatic and memory safe Rust.
As with all transpile ports, the true test will be how well it can be extended and maintained over time. Historically working with the output of a transpile is not pleasant and requires heavy rework to get it to the point where you can be comfortable enough to extend it.
The existing community is now either going to need to learn Rust or new Rust developers are going to have to join the project and they may not invested enough to refactor the transpiled output when they could work on something else like Boa.
historically we didn’t have LLMs which don’t mind “unpleasant[ness]” and “heavy rework”.
This is I think a preview of the future of software development. LLMs are having the same effect as compilers, frameworks, etc - they are making new kinds of software development feasible which were not previously so.
> historically we didn’t have LLMs which don’t mind “unpleasant[ness]” and “heavy rework”.
I'm not quite as optimistic. "Unpleasantness" might sound like subjective disgust, but it often relates to objective criteria like complexity, that increases the surface area open to bugs in a real way. Similarly, if reworking has a non-0 chance of bugs, its gonna have some form of risk, and a major one will of course be higher.
LLMs may be capable of a lot, and they miggt change what projects people can take on, but they definitely don't write bug free code.
The bun rewrite/transpile did use some neat ideas like lots of testing and per-file translations, so hopefully they have more in their toolbox than "LLMs hopefully won't be affected by complexity or write bugs"
That's a stated goal, so nope. But releasing it before any cleanups is another story.
I'd also like to inform you that
- the current success metrics solely consist of their advertisement, my eyes looking at the code strongly suggest otherwise
- the Bun team lacks knowledge to actually make it more idiomatic: none of the Bun team has written any Rust and relying on model knowledge is already proven insufficient.
The release decision itself is presumably driven by that tbh. It's only LGTM from there when nobody knows how to review unsafe Rust.
> the Bun team lacks knowledge to actually make it more idiomatic: none of the Bun team has written any Rust
Do you know how silly this sounds? Good engineers can work in any language. At the top companies (of which Anthropic is certainly one) they don’t have “C++ engineers” and “rust engineers” they just have engineers.
Given that they are investing their time into actually learning the language before diving into this mess. No, unsafe Rust isn't supposed to be something you can handle without prior knowledge.
Jarred was even asking in public how to use traits without runtime overhead during the rewrite. And the blog post phrased it like a normal problem to encounter while doing a million lines port... That's two months after the initial rewrite so you can guess if they learned.
Yeah I don’t understand this port at all other than as a big marketing stunt.
It would have made far more sense, for reliability, efficiency, cost, etc., every metric really, to use or write a source to source translator that preserves as much structure from the original code as possible. Typically if you do a rewrite there are lessons learned from the existing code base that you want to take into account when doing the rewrite; using a bunch of agents to do the porting file-by-file buys you none of that. In either case the code will be an unidiomatic translation, just with LLMs you get an added source of indeterminism and a huge bill at the end of the month.
This comment inspired me to take a look at the trend of "unsafe" in the Bun code over time since the rewrite PR first landed - here are the commits where that number changed by at least 10:
The original code was one giant unsafe block with almost no tangible way to find or debug all the subtle memory bugs and leaks they had.
Now it's smaller, faster and has fewer bugs. Also its every potential memory issue is neatly annotated by an unsafe block so you can go and refactor them out one by one with confidence.
All this seems like a pretty huge improvement to me. Why is this an abomination in your eyes?
Nope, this is demonstrably false because Rust has its own invariants around its types and the codebase is violating a lot of them.
> every potential memory issue is neatly annotated by an unsafe block
"Potential memory issue" can originate in unsafe blocks and safe code that are able to alternate the input condition of these unsafe blocks. Guess what? That still counts towards 100% in this code base, hence the abomination remark.
> refactor them out one by one
Not as easy as it sounds. They are like threads in a yarn ball, if there are one or two ends visible it's easier to sort them out. The actual situation is more like we have tens of thousands of ends (all the raw pointer code that comes with every shared object), to fix them it's basically a requirement to unwind the whole thing (rewrite all the callees and reorder the data flow as needed, redesigning all the APIs during that).
It's too early to declare it as anything remotely close to a win, optimistically saying.
> Nope, this is demonstrably false because Rust has its own invariants around its types and the codebase is violating a lot of them.
I'm not sure I'm following what you're saying here. In the rewrite blog post it has been stated that the Rust port landed in a place where it passes 100% of the existing test suite and does so without some of the known memory leaks of the Zig version that they were aware of and didn't know how to address.
Sure, there's no guarantee that the port didn't introduce new bugs and most likely it did, but the 1.4 version has not been released yet, so I don't think a direct comparison of a long-time "stable" version and the just-landed full rewrite is meaningfully helpful.
> "Potential memory issue" can originate in unsafe blocks and safe code that are able to alternate the input condition of these unsafe blocks. Guess what? That still counts towards 100% in this code base, hence the abomination remark.
But that just means that once you get rid of the unsafe block, you're pretty much guaranteed by the Rust compiler to be memory-safe. This means that all your potential memory landmines are annotated in the code and once you disarm them all, you're memory-safe.
I don't understand how what you're saying contradicts any of my statements.
> Not as easy as it sounds. They are like threads in a yarn ball, if there are one or two ends visible it's easier to sort them out.
Still easier than the Zig version, where all the same things you've mentioned apply, but also there's no visible indication of progress and issues are unmarked and could be pretty much anywhere.
> It's too early to declare it as anything remotely close to a win, optimistically saying.
Based on the rewrite blog post it's pretty clear that the Rust version is outperforming the Zig version by pretty much every measurable metric at this point.
I think the backlash is mostly focused on the ideological opposition to fully AI-authored 1MLOC+ PR approach they took.
They can't mention what they don't know. And that's the exact reason I'm against this: doing a port without being able to tell what is correct is asking for a disaster, obviously.
I've checked their posts and blogs for a few times, and I'm quite sure they don't know any of these to write about them.
> the 1.4 version has not been released yet
Let's hope the repeated delays (it was scheduled for last week) are not for quality issues, otherwise I'll only be half correct. It appears that all the MIRI errors are not stopping them though. (They have a script to run it but most probably it just fails and they don't care. Personally I'm not executing any of bun's code to avoid summoning nasal demons, so I actually don't know for sure)
> get rid of the unsafe block
Would be possible if they are not disregarding everything else going for numbers. E.g. they are actively increasing the unsafe surface by rewriting some code in SIMD C++ (https://github.com/oven-sh/bun/pull/33032). As if no Rust solutions already exist.
> Still easier than the Zig version
Well, this is true but only realizable if they know how to deal with the new problems emerging during the process. My current conclusion is that they don't.
For someone who is not a rust dev, would you mind giving me an example of this:
"Nope, this is demonstrably false because Rust has its own invariants around its types and the codebase is violating a lot of them."
Aw I feel quite sorry for using the word "demonstrable" while not intending to demonstrate anything, in order to avoid any contributions to the project. I apologize for that.
That being said I've found a case that doesn't do much harm even if it's fixed, and is technically not my contribution. You may take a look at that:
But code is not mathematics, so incorrect code is not worthless, it’s just worth less.
It’ll most likely still do 99% of the things people need it to do, there’ll be a an issue created for that broken 1%, and eventually it’ll be iterated upon and fixed.
Unless you’re working on a security boundary of course, there you should treat it like maths.
who claimed that? Are you suggesting that the rewrite did not introduce any new bugs? The correct answer is, by the way, that no one knows since it's millions of lines of code no one has properly read.
> smaller, faster
I thought this has already been debunked. You could just write better zig and make it smaller, faster (and have fewer bugs!)
Oh good, the vibe coded prompt injection vector that casually accesses things in my home directory without permission is running on a vibe coded prerelease runtime using lots unsafe rust. What could go wrong?
Incidentally, Claude Code has been very buggy for me lately (much more so than before). Lots of TUI rendering issues causing, e.g., the conversation history to be garbled etc.
I've been (grudgingly) using Claude since February.
When I started, I discovered to my shock that it was by far the worst TUI I had ever touched. Rendering glitches, keyboard input screwups, and just all-around jankiness.
Despite that awful baseline, I have to agree that it's gotten noticably worse in the past week or so.
It's started mangling my terminal sessions somehow, so that not all characters I input are visible in the UI.
Backgrounding it, doing a 'reset', then re-foregrounding seems to fix it.
Of course when I asked it to diagnose the problem, it assured me that Claude has no such big and it must be something else I'm running.
All I'm running is tmux and Claude, though, and the behavior surfaced while I was running Claude.
So, yeah - if they just recently updated Claude to use the Rust rewrite, this increased crappiness might actually be due to that. It does seem to at least roughly correlate.
Every time I resize my window now, the output is completely garbled. I often have to ask it to repeat itself just so I can see what it just said. This isn’t a new thing, but it feels like it’s gotten worse. This is on Windows
I'm far from being anti-AI, but these guys take it way too far IMO. It's straight-up AI slop. Like a real engineer still needs to be in the loop and drive the tool.
Why even write Claude code in JavaScript at that point, assuming they write the application logic in node and also include the interpreter in the application?
Probably because the team lead is a web developer, and whatever he says goes. Companies are typically very hierarchical, even if they like to claim otherwise.
a terminal app now has a supply chain long enough to include a runtime acquisition. somewhere between "rewrote it in Rust" and "ship it" someone said "or we could just buy the company"
The port of Bun, which has >5000 open github issues, is used in Claude Code, which has >11000 open github issues. Do people use Bun in things that are expected to work reliably? Have any such projects tried the upgrade yet?
To be fair, https://github.com/python/cpython has over 5k open github issues, and that's still generally considered fairly reliably technology even if a lot of HN users seem to hate it.
It's not a great way of inferring software quality, but I think the numbers for both Bun and Claude Code are pretty bad.
cpython has ~7,000 open issues, but ~70,000 closed ones, a 1:10 ratio. Bun's ratio is above 1:2.5, while for Claude Code it's slightly over 1:6.
Much more importantly, though, Bun's oldest issue is from Sep 2021, while Claude Code's is Feb 2025. cpython's oldest issue dates from June 2000 (presumably migrated from an older tracker). Claude Code has very nearly the same total number of issues (open + closed) as cpython at around 77,000, but Claude Code has done it in a year an a half whereas cpython has taken 26 years to get there.
It's a good comparison to pick, as it can't be explained by popularity. For all the real-world use Claude Code sees, it's nowhere near what cpython sees, even over the year and a half in question. Bun, meanwhile, is hitting these numbers while not even being the mainstream choice for what it does (node still holds that crown afaik).
Did Bun mass-close issues that predated the rewrite? It doesn't look like they did, as the oldest open issue is from 2021 and there are many from 2022, but maybe they did something that killed most of the old issues.
Their (public) project management is horrible, you can find fixed issues unclosed and unfixed issues closed. Not really surprising when that part of the work is completely taken over by LLM agents though.
Yeah I'm also wondering what the point of Bun is when Deno already exists. Especially since it added Node compatibility. Genuine question, why should anyone use Bun if they're already using Deno?
I'm stupid and clearly too stupid to google too. Is bun simply a better nodejs? Assuming it true that all of Claude code is now written by AI, why would AI care about using bun over node?
They’re just wildly successful terrible engineers who can describe problems well and have unlimited token budgets. If they were paying for their own token use, the software would be better, they simply don’t have financial incentive to be more performant.
A dirty secret of AI data centers are that they’re only getting 40-60% efficiency out of their GPU clusters and because the moneygun go brrrrr they just buy more.
You wonder why they’re so afraid of the Chinese competition… they can’t afford to be as wasteful
I thought it was interesting. I didn't write this with Hacker News in mind.
(I was actually half way through writing about something related, when I thought it would be interesting to see if I could prove that I had the Rust version of Bun on my laptop already.)
> "only covering AI" - don't miss my wildlife photography!
The "ai" tagged posts (2,100+) significantly outnumber "sighting" posts by orders of magnitude. Even searching HN, this post is the very first mention of it.
Perhaps that is why everyone here (except you) overlooks that or why we don't see much more of those sightings posts here either.
Yeah, wildlife photography is a new hobby - it used to be every few months, now it's several times a week.
I would be very surprised if one of my sightings posts made it to Hacker News. Maybe if I manage to snap a photo of an actual pelican perched on a bicycle some time.
None of them get any influence on my content. That would hurt my credibility, and my credibility is the reason my site is worth sponsoring in the first place.
Honestly, if OpenAI or Anthropic offered to sponsor I'd probably turn them down. The optics of taking sponsorship from companies that I frequently write about are not great.
Fair, that rules out "Anthropic pays you directly."
But look at your own disclosure page [0]: OpenAI paid you for your time at a GPT-5 preview, and you regularly get early access, embargoed previews, and free API credits from OpenAI, Anthropic, Gemini, and Mistral. So "I've made no money from Anthropic" is narrower than it sounds, access and preferential treatment are compensation too, even if cash didn't directly change hands.
Same goes for the sponsor list. Microsoft is OpenAI's investor and infrastructure (or was anyways, I've got no clue what the status of that is these days), Amazon and Google are both major Anthropic investors, and most of that list runs on Azure, AWS, or GCP, or sells tools built on these labs' models. Taking a Microsoft sponsorship isn't really separate from an OpenAI one, it's just a single hop removed. The entire software ecosystem and all the players in it are entangled in this bubble.
I'm not accusing you of consciously hyping any of them. Your posts are high quality even when I disagree with the contents of them. You often list downsides too, prompt injection, security, slop issues but the throughline still repeats: this is inevitable, get on board. Product-market fit found, November 2025 as the inflection point. That kinda framing shows up again and again throughout all your posts.
It's refreshing that you're upfront about the previews and credits and all that jazz, but surely you understand why some people stay skeptical even with that disclosed as it confirms the access exists.
Whether you realize it or not, I think they are indeed paying you in some sense, which is part of why I'm skeptical when your posts consistently land at the top of HN. Not because the writing isn't good, but because I think the same incentive shaping the coverage probably shapes some of that reach too.
Your comment here is fair, and it's why I take my disclosures seriously.
Nobody is unbiased, no matter how hard they might try. I like to get my information from sources where I understand their motivations, so my approach is to try to make my motivations as clear as possible.
(That's why I spend an unreasonable amount of energy arguing with people on Hacker News who call me a shill!)
Is anyone else failing to understand all the internet drama surrounding this?
The rewrite may work out on a technical level or it may not. Let's wait and see. The Bun project did not swear a blood oath to use Zig forever, and it's ultimately their choice to switch to a different programming language.
Beyond that, people seem to be incredibly emotionally involved with this, for reasons that entirely escape me.
I am getting into the frontend dev and one thing that I don't understand is why people use bun in the first place? It's not much better preforming, it's not much safer, it's still not 100% compliant. Some tests show it's actually slower than node. Why bother switching, then?
Stdlib includes yaml, sqlite etc so you need to pull in fewer deps, so you can avoid the left-pad/is-even node_modules explosion problem to a greater extent
I love bun - although disliked how Jarred did the conversion.
Project-wise, nothing has changed.
Bun was always great because of the fantastic dx - it was just really easy to use , with stuff like out of the box typescript (unreal that it took so long for node, and it's behind a super long flag, wtf...). And it didnt have the weirdness of deno, it maintained backwards compatability with node api, and it just worked.
But it was never stable. You'd have to be fool to believe that a single project could stably do everything bun covers. It's always been an insane project. It was built on top of zig, a langauge that hasn't reached 1.0, and is constantly changing, and throw in how he was rewriting his own custom zig stuff. Like c'mon, let's apply some common sense here.
For me, little has changed. I am still going to use bun as a nice dev tool, and use node for production.
Anthropic bought Bun, so they kinda, sorta had to make this work. I am sure the cost at $145,000 in Claude time will get some attention.
I am curious how this will work going forward from FOSS perspective. Will humans be allowed to modify the generated code? Only the .md prompts for the agents? Or what?
you know what i hate? i hate that each update, to codex or claude code, it seems like they're always trying to "hide stuff" , reminds me of the 80s and 90s when tech assumes normal people are too stupid to see 'raw' stuff like terminal commands being run, its always been like that, less so now, but i get so mad when its doing stuff, and i can't see if its deleting files or just screwing something up. btw this is totally free tool buttonscli.com that is a full UI terminal app but its got a button for agent control. You click that, paste into claude code or w/e/any agent, and it'll use that for the terminal commands instead of the built in one so you can see everything (and it can open 10 tabs if it wants, you see them all)
pi runs in TypeScript and I like it, the target language of the tool, for me, matters only such that I can extend it. I like writing extensions, plugins, things, in TypeScript so I'm cool with that!
Claude Code is closed source, doesn't let me extend it beyond hooks, and these I write in bash anyways.
That all said, why should I bother about this change? Feels like a nothing burger to me, as an end user. This should matter more for those that are internal to Claude Code and Bun developing it.
I despise this era we live in. Pushing rewrites like this upon millions of users, when the Bun rewrite has countless known issues and is likely a security nightmare. Every time I ‘brew outdated’ and I see a wall of updates I die a little inside knowing that most of this code has not been verified or even looked at. Yet we hear about massive supply chain attacks pretty much every week now and we’re still full steam ahead on this vibe coded nightmare. God help us. Claude Code in particular updates sometimes multiple times per day. Like I’m sorry but there is no way all this nonsense is safe.
It is absolutely amazing to me that this ai rewrite work so well, maybe claude is not really that much of a complicated tool to stress the bun runtime but still...
It works well because they had tests, they could compare before and after. Likelihood of issues especially if you transpile to a safer language should be minimal.
Yeah, I noticed. I had Claude write a quick JS script for me a few days ago, it then tried to use Bun to run it. When it couldn't find it, it tried to install it with `sudo pacman`. I had to fucking tell it to use Node instead.
Honestly, I initially thought rewriting an entire codebase with AI would be a huge mistake. After reading this, I'm starting to think I was wrong.
If projects like Bun can be substantially rewritten and shipped to millions of users, it suggests we're entering a very different phase of software development.
Today's AI-generated rewrites may not produce code that humans would consider high quality or maintainable. But I'm beginning to wonder whether that will even matter in a few months. If AI is the primary consumer, maintainer, and refactorer of code, human readability becomes far less important than correctness, performance, and the ability to iterate.
This feels like a shift where software may no longer exist as a long-lived artifact in its current form. Instead of writing and maintaining applications for years, we may generate, adapt, and discard them continuously for each use case.
Some of what you’re saying is likely true but quality is something that will never be optional. There is quantitative data suggest that LLMs perform better on higher quality code base which makes sense. Code that is well organized and coherent will make better use of the context window.
Software refactoring and tech debt is absolutely where LLMs will shine as is evidenced by the Bun rewrite.
> But I'm beginning to wonder whether that will even matter in a few months.
At that point, even Bun itself doesn't matter. All intermediate tools don't matter if LLMs can reliably write something large.
The problem is that LLM is not quite there yet. The rewrite was only possible because they mostly stick to 1-to-1 translation resulting in non-idiomatic Rust code. So, what from there? I don't think they can really build up a sane codebase from that state. They only shot themselves with a bigger gun.
> The rewrite was only possible because they mostly stick to 1-to-1 translation resulting in non-idiomatic Rust code.
That’s patently false, just read Jarred’s own blog post describing how that was the first stage only, they went through many more to get the amount of non idiomatic, unsafe Rust code to an acceptable level.
Somebody checked[1], and they discovered that the "stages" past the first had minimal impact on the unsafe blocks count. That's just one metric, but it makes me doubt your claim that there was/is a lot of work put into making the translated code idiomatic Rust.
We'll develop faster and better tech. We'll find resources to feed that. Use that to build better. Access better resources. We'll mine asteroids. We'll harness much more from the sun. The factory must grow.
Is that before or after the earths atmosphere acidifies for humans and our bodies can’t hold enough phosphorus or calcium for basic metabolic tasks? You have until 2050:
these doom and gloom reports also said half the land will be under water by now and average temperature will be 40c. Didn't happen.
Earth is in a cooler period and it will get very warm. These crappy climate change activists will not get anything done but to hold us back. We need more power, more tech, and more abundance of things. We will need to engineer our way out of real climate change.
> Honestly, I initially thought rewriting an entire codebase with AI would be a huge mistake. After reading this, I'm starting to think I was wrong.
> If projects like Bun can be substantially rewritten and shipped to millions of users, it suggests we're entering a very different phase of software development.
exactly. this wasn't a technical project. this was a marketing stunt that worked on you.
It was already written in a very performant language so no significant performance improvements should be expected.
The benefit of a rust rewrite is memory safety improvements, but currently they've just rewritten zig to unsafe rust so they don't have that either yet
I don't think their motivation was primarily user-visible stuff. They backed themselves into a corner by forking Zig, and also were fed up with fixing memory errors.
You wouldn't notice either of those if you were a user, unless you happened to hit one of those bugs.
The blog claims rust chosen mainly to address memory issues, which rust is a better language for. So, success would simply be less new memory errors / easier to patch old ones.
Claude installer/updater had a high memory usage problem (Gigabytes of resident memory used during a fresh installation of Clade with it's native install.sh script, or during a claude update). This was reported as early as December 2025, see https://github.com/anthropics/claude-code/issues/12327#issue....
While everyone here in this forum kept arguing (and fighting and yelling at each other) whether tis moral/right/secure/cheap for ppl to rewrite and ship a major software package with LLMs/agents, one of the main drivers behind AI actually did it, without consulting your opinion, and most same everyone actually slurped this decision without paying a a notice.
Boring is good, but this boring is super massive major thing that happened, and precisely because security is still intact.
I've been using Claude Code daily for a fairly large FastAPI project and didn't notice anything unusual around that timeframe. If this really was the Rust runtime underneath, "boring is good" seems like the right outcome.
I'm looking at this situation strictly as 'What's possible today'. If a 1M lines code rewrite from one language to another goes into production in 1 month, that's a very strong signal that the models are now insanely capable.
My anxiety before merging a 2K lines PR is greatly reduced after 3 frontier models (Fable, 5.6 and kimi K3) finds no issues in it.
Just 6 months ago (Opus 4.6) this was not true, a big PR would have countless number of issues.
Aside from the human drama, the message to all of us is - these things are ready for whatever your imagination can throw at them.
I think that's exactly what Anthropic wanted to communicate.
Drilling into the original article where Jarred explained the reasoning behind the change, It's pretty clear that under zig the team was doing things by hand that are automatic in rust.
Humans and agents share one thing: they are both non-deterministic. He talks about the issue of tracking memory lifecycles manually in zig so it can be explicitly freed. As expected, this leads to a long list of bugs where people missed things.
Rust does this automatically. It removes an entire class of errors from his backlog. From an engineering management perspective, this looks like a pretty good trade.
The bonus here is that compiler errors are exactly the kind of deterministic guardrail you need to put around coding agents. Claude works really well if you give it a way to test for correctness and "make it compile" is a pretty good target.
There's a general version of this: the artifact you expose plus the test you run on it. Deterministic tests turn stochastic output into a hard guarantee. Wrote it up here if useful: https://michael.roth.rocks/blog/verification-surface/
Zig (like C) is simply not a good language to use if you're going to do many small allocations with uncorrelated lifetimes. To write robust Zig (or C) code, you must manage lifetimes yourself, for example by grouping allocations on an arena or by having fixed buffers of "things".
You can just do that, and then Zig is really no less robust than Rust. But if you want to do "managed language" style allocation patterns (like what llms generally prefer), it doesn't make sense to use it.
Grouped and arena allocations work really well in Zig. For awhile, we tried to use this pattern almost everywhere in Bun but it gets really tricky when there’s some GC-managed memory and you want to free things incrementally to reduce RSS. Also, using arenas for arrays that grow wastes memory a lot since it keeps every previous version around (mimalloc arenas are slightly better for this)
Grouped allocations works especially well in parsers & ASTs where the lifetime is very bounded. Since the Rust rewrite, we still use arenas for Bun’s parsers and the bundler but not a ton elsewhere.
> using arenas for arrays that grow wastes memory a lot since it keeps every previous version around
Not if you use segmented arrays
https://danielchasehooper.com/posts/segment_array/
Zig is always _less_ robust than rust. Even if you have a single allocation you can always forget to free it.
> You can just do that, and then Zig is really no less robust than Rust.
If you just don't write bugs, then yes all languages are equally robust, including assembly.
Zig, like C, is simply not a robust language. I don't know why this feels like something contentious? It's clearly not intended to be robust?
Zig is intended to be as robust as it can be as long as it doesn’t implicitly add code (no destructors that run code you didn’t explicitly call), or increase compiler complexity and compilation time.
I don’t think it makes sense to say Zig is or isn’t intended to be robust in general. Like, we don’t say Rust isn’t robust since it doesn’t add dependent types and general purpose static verification that can do more general proofs. It’s focused on eliminating one class of memory bugs in particular, exactly the class of bugs that are the biggest challenge for software like Bun, and other software with complex lifetimes (it originated from Mozilla and Rust is perfect for browsers)
Zig is intended to be robust for software like TigerBeetle, or the Zig compiler itself, where memory lifetimes are simple.
I’d say the focus on built in tests, fuzzing, debug memory allocators and safe mode shows that Zig is absolutely intended to be robust, within the scope of what the language aims to be. Far more than C itself or most of its popular compilers ever did.
A casual read of TigerBeetle's practices makes it clear they're doing some very unusual things, both in their memory allocation strategy and in their testing/verification.
Despite TigerBeetle being one of the highest-profile remaining Zig projects, I actually don't think they're representative of the average Zig project at all.
Static memory allocation is idiomatic in high-performance software. You do the same in C++ if you care about performance and reliability.
It is quite representative of an embedded software project. TigerBeetle is not what we usually call embedded software, but it is built like it: static memory allocation, a self-contained executable, and a strong focus on determinism are typical in that field, especially for critical software.
And I think embedded software is a field where Zig will be at its best. The only thing it is missing is maturity. When project lifetimes are measured in decades and changing a single byte can cost millions, no one in his right mind will pick a language that is still in development. Things will become interesting when it reaches 1.0.
Can you elaborate on the unusual part?
All necessary memory is allocated at initialization. The application is not allowed any allocations during it's normal runtime. This is how it avoid memory bugs.
Not a lot of people write programs this way.
Static memory allocation is widely used in quite a bit of embedded software, particularly safety critical stuff. There it's often latency related since you don't want hangs while memory is allocated.
I've even seen it on some simulation software's core that was written in the 80s originally; at the time memory was much more constrained so allocating upfront meant you could check upfront whether the simulation could actually run or not vs crashing out part way through.
A lot of people write software like this when predictable latency is a hard requirement.
I was just learning yesterday that's exactly what GTA did on PS2, which I thought was interesting. (Not to belittle your point, just giving an example)
I do this in Unity because allocations/GC cause hitches. it's pretty normal thing to do there's even the built in pooling libraries so you can pre-allocate 10,000 gameobjects when the game starts. I haven't played with ECS/DOTS yet but I assume it does something similar.
I do. The only thing I need dynamic allocations for is queues of asynchronous events, and that's just because I'm too lazy to calculate an upper bound for how many there may be.
This is standard practice in the games industry.
> Like, we don’t say Rust isn’t robust since it doesn’t add dependent types and general purpose static verification that can do more general proofs.
Give it a few years! I've noticed an explosion in interest in formal verification recently, especially since nowadays the bar to entry is so low: just ask your LLM agent to give it a go.
Realistically much of the most reliable software in the world was written in C. Robustness is more so a function of coding style and engineering practice than it is of the programming language chosen.
Of course you could argue that on average, most programmers are not going to have the right practices and skill, so on average you should prefer Rust. But that's unrelated to the argument I was making, and in any case not a very interesting point in my opinion.
Conversely, most of the high impact bugs are also written in C and C++, because they rely on "coding style and engineering practice" to be correct. Rust raises the floor on this by a lot.
Adding that with a principled approach, I don't even see much of an issue with doing manual creates and deletes in a object-graph type app, with many unstructured lifetimes. Sometimes that might just be required, and then the complexity is just there either way. Having to cleanups manually or not doesn't change anything about that. It's a bit more cumbersome to get everything right when doing it manually -- sure.
The problem is mostly people graduating from school thinking that somehow there is only stack and heap, and malloc/free is how you do heap. That view completely ignores that the essence of programming systems is mostly to understand the machine, and then doing conceptual and architectural work on a solution (and also on a problem). The act of writing actual code is then mostly just translating those concepts into the digital world verbatim.
Above poster is talking about thinking in terms of grouped lifetimes and bulk allocations/deallocations, which is better for performance, and makes Rust borrow checking and other RAII style features pointless as they don't add any safety benefits. This video completely changed the way I think, and I subsequently moved on from Rust: https://www.youtube.com/watch?v=xt1KNDmOYqA
the buffer managemnt is just different pattern and style of code thats more low level. when you care about performance and cpu cache, you have to make sure that actual physical memory gets computed at same time as other memory near it so there is less latency.
the primary motivation isn't latency but complexity. People do in some applications free or allocate collectively because they have interrupt times in mind, but most of the time when you manually manage memory the issue is mental overhead, so people gravitate towards models they can keep in their head.
Allocating in large chunks is often not very performant which is why people came up with tools like the borrow checker, you often want to allocate and deallocate dynamically on a need-basis but that's exactly where bugs occur.
> Zig, like C, is simply not a robust language
"Extraordinary claims require extraordinary evidence" -- Carl Sagan
> You can just do that, and then Zig is really no less robust than Rust.
That's just it, using Zig required more rigorous engineering than the Bun team were capable of.
People tried to "just do that" (write their programs in a memory safe way) in C and other languages with manual memory management for decades, and we have countless vulnerabilities that prove this simply doesn't work. That's why newer languages, with the notable exception of Zig, prefer more advanced memory management methods.
> People tried to "just do that" (write their programs in a memory safe way) in C and other languages with manual memory management for decades, and we have countless vulnerabilities that prove this simply doesn't work.
Who are these "people" you speak of? It's possible to write software in low level languages that don't have these problems. Not a "non-zero" it might be possible, it can be done thoughtfully, and the popular notion it can't be done is backed only by incomplete anecdotes.
Should everything be written in low-level languages? No, that would be absurd. Is it a simple fact of life that not every person/team/organisation is capable of meeting certain standards of rigour? Yes. That's not to say anyone in the Bun team could not become sufficiently competent in the future. For whatever reason, current experience, incentives, and personal motivations did not make for a conducive environment to make Bun watertight in Zig.
Yes, it's possible. It's also possible for experienced pilots to fly an airliner completely manually for the full duration of a transatlantic flight without crashing. Still, over the last decades, autopilots and other assistance systems with ever more sophisticated features have been developed, and I would argue that without this technology crashes would be much more frequent than they are today. Same goes for memory management: you can do it manually, and it might work out most of the time, but if the programming language is helping you with it, the likelihood of memory safety issues decreases drastically. And the problem with avoiding these issues only by "meeting certain standards of rigour" is that you might only find out that you have failed to meet them years later, when you learn that your software has a vulnerability.
> Same goes for memory management: you can do it manually, and it might work out most of the time, but if the programming language is helping you with it, the likelihood of memory safety issues decreases drastically. And the problem with avoiding these issues only by "meeting certain standards of rigour" is that you might only find out that you have failed to meet them years later, when you learn that your software has a vulnerability.
Zig does help you. Array slices, explicit nullability of pointers, defer errdefer, explicit allocators, built-in leak detection, bounds checks, overflow detection, the list goes on. If you need to play around on that side of the fence, Zig gives you a lot to make sure you don't mess it up. If we were talking about C I'd give you your flowers, but we're not. The most common issues and vulnerabilities that crop in C from manually managing memory are strongly mitigated by a quarter of that list.
Just people like the linux kernel, all major browsers, most of our popular webservers, etc and basically all non-trivial software projects written in C.
The good news here is that we have more than just anecdotes to support this, we have empirical evidence.
That's like saying that they should have used assembler but they just weren't capable of it. It's personal insult dressed up as a nonsensical technical argument.
Similar in style to Zig's guy public insulting
It matters what software you're writing. When it's a JavaScript runtime, it's not as if you can get away with preallocating all the memory you'll need like some games used to do.
So it's reducible to a simple matter of inferiority vs superiority?
Is engineering capability the issue, or time pressure/constraint?
I think the main issue is that Bun relies heavily on existing C++ libraries like JavascriptCore, and these require RAII and ref-counting semantics from C++ that are closer to Rust than Zig.
You could write a JS engine with Zig-like idioms (arena allocation, static initialization), but that would require re-writing the whole JS engine from the ground-up (though I would definitely be interested in it if someone actually tries to do it!)
> You could write a JS engine with Zig-like idioms (arena allocation, static initialization)
Could you actually? That seems like a bad fit for a JS engine to me. Predictable memory requirements are great when you can have them, perhaps you can avoid complexity then, but for a JS engine?
> You could write a JS engine with Zig-like idioms (arena allocation, static initialization)
Arena allocators & static initializers are not novel. You'll find them in high performance C++ projects as well, such as LLVM or JavaScriptCore. But arena allocators have the quite significant limitation that they only help when everything being allocated in them have approximately the same lifetime. So they don't help when you need to allocate memory to provide the native implementation of a JavaScript object, for example (eg, FFI).
Why not using Swift?
Swift is very weak outside Apple ecosystem, compared to Rust. Not sure nowadays, but Swift used to have breaking changes each major release, that's a non go for a big project.
But Swift has a stable ABI which neither Zig nor Rust could provide.
How important is stable ABI for projects like Bun? I think it only matters if you are building a shared library.
only on macOS. On other platforms ABI is not stable.
Andreas Kling talked about it. It boils down to C++ interop sucks (no surprise for lang made by Apple), ecosystem is tiny, Rust works well enough with LLMs.
https://youtu.be/DbHjKi_jASY
He just wanted to use LLMs for coding, and not enough training data on Swift code exists for his use case. Admitting to that would be rather silly, so here we have this sentiment now exist rent free in people's brains.
The C++ interop of Swift is perfectly fine, to such a degree that FoundationDB is now using it effectively alongside its C++ origins.
Swift is one of the few toolchains that actually has some kind of builtin C++ interop, alongside Objective-C++, D, .NET (via C++/CLI), Carbon (eventually).
This reads like cope because you're re-inventing RAII from first principles.
I cannot take this seriously as tutorials on robust Zig Allocation Pools will store a deinit method for each item within the pool, so when the pool deinits, all internal objects can be deinit'd.
That is just RAII & dtors from first principles, except with extra overhead of manually storing fat pointers yourself (and the bugs that come with this). Instead of using a language with builtin guarantees & optimizations around handling this so your object pools don't need to carry around a bunch of function pointers. C++ has aggressive de-virtualization passes so at runtime a lot of the 'complex object hierarchies' can be flattened to purely static function calls.
This is a general problem with destructors, you can't "batch delete" objects. To free a lot of stuff you're required to go pointer by pointer through the tree to clean up each object. To get real performance gains from pools you can't have per-object/subobject custom cleanup code.
Not necessarily. Drop semantics are just syntactic sugar, and can thus be aggressively inlined or auto vectorized by the compiler.
I've argued elsewhere some things that are wrong with RAII and C++ objects in general.
Here I would just like to mention that if you have to rely on "de-virtualization" passes, you're in a miserable situation architecturally. If you have code where the overhead of virtual function calls might be too much to pay, don't do virtual functions then. End of story.
To deconstruct a pool of objects, I don't see what should ever be wrong with a function pointer. The overhead of loading the function pointer will get divided by the number of objects being deconstructed. Care to explain what's the issue here?
> I don't see what should ever be wrong with a function pointer. [...]Care to explain what's the issue here?
1. You're writing code you don't have to
2. That adds runtime overhead
3. That when you screw up has non-trivial security & resource management side effects
This is objectively indefeasible in nearly any vaguely professional context.
1. No, you're not writing code you don't have to. It's not different to implementing this as non-virtual methods, in fact I'd argue doing simple functions is more straightforward.
2. And the code being compiled is abstract & generic, it won't be instantiated for every type and bloat the executable or instruction cache.
3. Security concerns: With C++ virtual methods every object carries a mutable pointer too (to a vtable containing function pointers). What resource management side effects please?
Re #3: vtable pointers aren't mutable...?
Of course they are. The pointers to the vtable are part of the object. They aren't mutable fields as per the language, but for security concerns it doesn't matter what the language thinks. Being part of the object, the vtable pointer has to live in a writeable memory mapping (like stack / heap).
Clang pointer authentication makes any type of vtable attack impossible in C++.
Fair enough, this is an extension though and I suppose you could use it with manually constructed vtables as well?
Then I don't understand your argument. If you're just saying what could go wrong with heap corruption, then your vtable complaint also applies to storing function pointers in arena allocators in Zig? Zig doesn't have anything special here?
I thought that this was just an initial translation to unsafe rust in which they haven't actually gained any of those benefits yet, although presumably they can go there quickly now.
> Rust does this automatically.
A garbage collected language does this automatically. Rust still requires thinking about and tracking memory lifecycles, but the borrow checker will complain and keep you from doing it wrong. That's why LLMs like Rust. It gives immediate feedback on what to fix. By-default constant reference parameters helps prevent major performance problems.
You're getting confused between lifetimes (the static analysis that prevents use after free and similar errors) and lifecycles (more commonly discussed under the heading of ownership) which determines when objects (and thus memory) are allocated and deallocated.
Ownership is automatic. You don't have to explicitly drop things when they go out of scope. (although the responsibility for that is split between the compiler and the library code).
Lifetimes are not automatic, but also have no effect on memory allocation. They are purely a static analysis path and you can make a functioning rust compiler that completely ignores lifetimes.
> You're getting confused between lifetimes (the static analysis that prevents use after free and similar errors) and lifecycles (more commonly discussed under the heading of ownership) which determines when objects (and thus memory) are allocated and deallocated. Ownership is
That's a semantic distinction which does not matter in the point OP is making. And contrasting rust static approach to general GC.
It’s my understanding that bun was ported to unsafe rust, so even these gains would require additional effort on the team’s part, right?
Unsafe Rust doesn't automagically disable typesystem (& borrow checker, but lifetime are a sort of types).
Once raw pointer is turned into a T, &T or &mut T, the borrow checker is on.
Yeah but if you have tried writing unsafe Rust, you notice that you are obligating yourself to write code that is much stricter than C.
E.g. in C you can write code and say "don't call it outside the situation that this function was written for" and then blame [0] future users of the API.
In Rust you need to actually make sure that your code works, i.e. your safe interface is not unsafe.
[0] The blame game is not a technical solution to a technical problem...
True, but unsafe let's you conjure up any lifetime you want, or any lifetime necessary to satisfy the lifetime requirements in safe code. If you generously sprinkle pointer dereferences in unsafe code, you effectively disable the protection provided by the borrow checker – including in safe code – until you've checked and verified the correctness of all unsafe blocks.
> True, but unsafe let's you conjure up any lifetime you want
The only thing unsafe does is let you have an unbounded lifetime. As I said, it doesn't check those:
https://doc.rust-lang.org/nomicon/unbounded-lifetimes.html> if you generously sprinkle pointer dereferences in unsafe code, you effectively disable the protection provided by the borrow checker
You don't disable anything. You wrote a "trust me compiler" block, and compiler trusted you.
Rust won't ever protect from all possible problems, just the ones the compiler handles.
> You don't disable anything. You wrote a "trust me compiler" block, and compiler trusted you.
That’s the same thing.
What's the point of using Rust in the first place when you disable the compiler feature that protects you the most?
Well, Rust has things like miri that can help you write your unsafe code and it's just a command line invocation away.
Obviously you should try to avoid writing unsafe Rust to begin with.
Mu. Invalid question. Rust doesn't disable compiler features. It gives you extra set of footguns when you ask for it.
As for the actual unloaded question, "What's the point of unsafe in Rust?" it is to contain and make it easier to identify sources of UB.
The whole point of the rust rewrite is that bun is now thought to rely on rust’s memory safety features, but that assumption doesn’t hold if everything’s inside an unsafe block.
Only ~4% of code is inside an unsafe block, so the idea is that for new code/contributions, the chance of introducing a new memory-safety bug is an order of magnitude lower.
Maybe in the future the unsafe code will go down to 1%, bringing that to two orders of magnitude.
Of course, only time will tell if that is true or not, but from experience I’d be willing to bet it is.
> The only thing unsafe does is let you have an unbounded lifetime.
No, you're wrong: You can create any lifetime. Proof:
This will take a reference and return it with any lifetime specified by the caller.> You don't disable anything.
I said "effectively disable". For example:
fn trust_me_bro<'a>(x: mut u32) -> &'a mut u32 { unsafe { &mut x } }
After the call to trust_me_bro, two aliasing, mutable references exist simultaneously. This would usually be prevented by the borrow checker, but the unsafe code has effectively disabled it.> Proof:
You just listed examples of unbounded lifetimes.
> I said "effectively disable". For example:
Not sure what you meant by this example since it doesn't compile. It seems the borrow checker caught your mischief. So much for effectively disabling stuff :P
You haven't effectively disabled anything; you just (tried to) wrote unsound code that washes one mutable ref as another. This stuff is allowed provided shared refs are never accessed at the same time (for example, panicking upon reading reference_b).
What you probably meant is https://play.rust-lang.org/?version=stable&mode=debug&editio...
But you know what? If you're dabbling in unsafe, you have this big button called Tools in the playground. Choose Miri, then run your code; it will display large Undefined behavior. It even highlights the `trust_me_bro` function.
Hell, run this with UBSAN, ASAN, and other C tools. They will probably catch any such behavior.
> You just listed examples of unbounded lifetimes.
You're just splitting hairs and trying to weasel around the fact that yes, you really can create any lifetime you want using unsafe.
> Not sure what you meant by this example since it doesn't compile.
That's because the crappy HN formatting ate some of the characters. Here's the original version:
https://play.rust-lang.org/?version=stable&mode=debug&editio...
> What you probably meant is […]
If you know what I meant, then what's up with your snarky comment about "So much for effectively disabling stuff"? In your playground link, you did effectively disable the borrow checker in safe parts of the code. Next thing you're moving the goalpost, now it's not about external, static analysis tools: "run this with UBSAN, ASAN, and other C tools". I don't think you're arguing in good faith here. Goodbye.
Borrow-checking the dereference of a stale pointer won't be worth much, though.
Sure; but I bet raw pointers are used very infrequently in the new codebase. The code was ported from zig to rust. I bet a lot of pointers became rust references in the process.
That’s my whole point! It’s ported to unsafe rust, not default rust.
The point of compiler-based checking would be that you know for sure. If you have to bet, all bets are off.
You don't need to rehash the same old argument. Runtime memory management is forgiving but also inferior in a lot of ways to compiled stuff that works with memory deterministically.
Garbage collection is a method to make programming easier, not to make the resulting program better.
> Rust does this automatically. It removes an entire class of errors from his backlog.
Even with the huge amount of "unsafe" rust currently in bun? https://news.ycombinator.com/item?id=48967630
As opposed to every commit abd line of code being unsafe? They use a lot of C/C++ libraries with their own code so unsafe isn't even a a problem in most places they use it.
You think it’ll all stay there?
Of course they’ll iterate and remove the unsafe bits which were necessary for the transition
Except the transition was never necessary. Yet another Anthropic marketing effort so they could claim a shallow victory [0].
[0] https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...
Creator of language has opinions on big project moving off language.
News at 11.
Fun fact, unsafe does not let you turn off the borrow checker in Rust: https://steveklabnik.com/writing/you-can-t-turn-off-the-borr...
"Fun fact", it lets you largely circumvent the borrow checker by creating arbitrary lifetimes: https://news.ycombinator.com/item?id=48974824
People are so funny about rust.
“Safe rust isn’t expressive enough!” -> then use unsafe rust.
“Unsafe rust lets you do anything! Even crazy things!” -> then use safe rust. Or just don’t write crazy code?
Does bun actually do anything insane like that in its unsafe blocks? Or are you just fear mongering?
Please try to interpret comments in the context of the discussion, not floating freely in a vacuum. The context of the discussion is the Bun port's excessive use of unreviewed unsafe blocks. unsafe in Rust can easily be misused to create Undefined Behavior, which renders any safety guarantees otherwise ensured by Rust's borrow checker invalid.
> Does bun actually do anything insane like that in its unsafe blocks?
Who knows? At 10k unreviewed uses of unsafe, I'd guess there are quite a few incorrect ones. LLMs don't produce perfect code (neither do humans), so there's a high probability that at least some of those create UB.
> Does bun actually do anything insane like that in its unsafe blocks?
How would anyone even know, it's vibe coded.
i found the same thing with Rust, verification steps are really helpful for speed and correctnesss
Good thing there are tons of languages that do that out of the box, and which are frankly quite fast.
I seem to recall this Rust rewrite is all "unsafe" meaning it really doesn't automatically eliminate those issues.
Relevant passage from Jarred's post:
"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 expect this number to go down over time as we refactor from a faithful Zig port (which had no greppable unsafe keyword) to idiomatic Rust, but we are going to continue using C & C++ libraries like JavaScriptCore so it will always have more unsafe than pure Rust projects."
Relative "number of unsafe keywords" or "lines inside unsafe blocks" isn't a good metric.
It's unsafe to call a C library that gives you a raw pointer, that can be a single line. It's unsafe to use that pointer, that could be a second single line. Carrying that pointer around, the data structures it's in, that's all safe, and doesn't implicate lifetime checking at all, so Rust will let you do silly things with the actual lifetime.
A better metric would be absolute unsafe keywords (because each carries a need to review), or "code in a module that uses unsafe anywhere" vs total code, because module boundaries isolate unsafe.
Yeah, one needs to understand that "unsafe" does not mark which parts of the code are actually unsafe, it simply marks parts where the compiler ignores parts of its rule set. But the implications can crop up anywhere, there is no guarantee that a resulting use-after-free or similar can only happen inside the unsafe blocks.
In short, if you use an unsafe block, then potentially any part of your code is unsafe.
Right, so if I understand correctly, to make the code fully safe, it can be impossible? Because you have underlying dependencies which are unsafe. The best you can do is make the handling of the unsafe as safe and as restricted as possible. But I can imagine some of these are way more difficult than others, and in programming the last 10% can be the last 90% of the work. Alas in terms of perceptions, the argument works well.
> In short, if you use an unsafe block, then potentially any part of your code is unsafe.
The way I think about it is that the unsafe keyword is a promise that you’re going to maintain the safety invariants yourself, manually. The program is memory correct if it correctly maintains a certain set of invariants. Unsafe punts responsibility over those invariants to the programmer. If you use unsafe and mess up, the program may be in an invalid state. Yes - it might crash, anywhere. But the bug is still almost always in an unsafe block.
It’s often possible to make fully safe wrappers around unsafe code which maintains all those invariants manually. (Either statically or dynamically.). A lot of the rust standard library does this. For example, Vec, Box and slice all use unsafe code internally to create safe APIs.
> it simply marks parts where the compiler ignores parts of its rule set
This is a common misconception, in a literal interpretation. It doesn't invalidate your point, but since people get the wrong impression: unsafe doesn't turn off any of the checks the Rust compiler does.
It allows you to perform 5 additional operations, and that's it. Using those operations wrong is what breaks the safety promises of the language. As an example, you could dereference a raw pointer and tell the Rust compiler it lives forever, when it's really a pointer to an object that's about to be freed.
Why not porting JavaScriptCore?
what is surprising about it? The way porting works has alway been first doing a faithful pass before going back to address impedance mismatches case by case. You would do that even when porting things manually, let alone in a super risky completely automated bulk migration.
> He talks about the issue of tracking memory lifecycles manually in zig so it can be explicitly freed. As expected, this leads to a long list of bugs where people missed things.
Yes, and again the "you're holding it wrong" people or "you are not a good enough developer" people will try to do juggling with a chainsaw and lose a couple of fingers in the process
Claude Code's endorsement (and real-world testing) speaks louder than internet discussions that are at this point 30 years old (and probably more)
LLMs catch memory bugs quite easily in my experience.
All of this is just a (succesful) marketing stunt by Anthropic.
> "make it compile" is a pretty good target.
But only as far as "make it compile" is a good predictor of runtime behavior. In C++ for instance, I can "make it compile" and it still crashes at runtime or does other undesirable things.
Rust is the clear winner of LLM era, you can't say otherwise.
Bah.
Personally my take on the entire affair is quite negative, whatever Jarred or Simonw says about it.
I think Bun owned by Anthropic and the entire rewrite with AI is not the real point (even if it's quite interesting, though).
My take is that Jarred, and Bun,didn't demonstrate a serious, adult approach, from "this is my branch, you are overreacting" message to just proceeding with a 1mil+ PR merged in less than month.
The communication is the issue, and it was handled very badly, in a way that impacted trust and divisions.
Was it so difficult to adopt the approach that the TS team adopted for 7.0?
There was a recent post on here with a Claude Code issue I and others responses to. Specifically, the person from Anthropic who caused the issue replied on HackerNews. In it, he claimed he was the sole contributor and reviewer of the code into production, that he would “do better” in the future. Commenters were confused how a company like Anthropic could allow something like this occur and for an engineer to publicly admit a complete failure and negligence of build processes.
It’s clear seeing your post here a couple days later what’s going on. It’s deliberate. I can only speculate on their reasons why but it seems to be an intentional form of disrespect on the engineering culture. “Your norms, your work, your principles” mean nothing. We can spend money and invalidate your life’s work. We don’t need your consent or support. That’s my personal guess at a surface level.
Serious adults?
They are in extremely short supply right now.
It’s a mix of serious-wanna be, quasi religious, quasi-technical people running the show right now.
I am so happy to I got to read about the 90s-2000s tech culture, and experienced the post-2008 startup culture.
Just about 10 years ago people were really serious, but chill-looking. Somehow that got flipped.
Sometimes being unserious is actually very serious. See current US administration.
Mario Zechner's talk "Building Pi in a World of Slop" is a good listen, on the topic of adults in a "world of slop". https://www.youtube.com/watch?v=RjfbvDXpFls
The wig-vs-grok periodic cycle.
I guess the point is none of it matters, CC users didn't notice or don't care except an exceptionally small minority.
The lowest of the bars
But the only one that matters?
Seems like this is delivering business value.
I don't know, I feel as though Bun went about it much more maturely than zig at any point in the process, from the initial attempted zig compiler commit by the Bun team to the Zig dev team member response to the Bun Rust blog post. Also, I think that fallout over this whole event will definitely favor Bun versus Zig.
It's a weird way to frame the event. Yeah, Andrew (Zig)'s responses were astonishingly immature, but it doesn't matter. Even if Andrew literally ate baby seals for breakfast and kicked puppies as a hobby, it wouldn't make Bun look better. You'd notice that the parent comment didn't even mention zig at all.
Saying Bun's communication was an issue here is clutching pearls. There is no evidence that Bun ever acted in bad faith, Jared definitely seemed to initally think it was just a trial, until he realized that it was actually something feasible. He isn't clairvoyant; there is no way he would have known it was going to be successful when he initially made the post.
Bun isn't Bun, it's a (notionally) trillion dollar AI company famous for ruthlessness and engineering controversy for marketing purposes. Zig just happens to be a language led by someone with an AI-skeptic philosophy. Are you saying I should just believe that their strategically deniable negative insinuations about Zig are not bad faith?
Sorry, but I'm calling bullshit. I know there's no absolute smoking gun here, but it's all a bit too cute to be unintentional. They are very very smart people. They knew what they were doing.
This is the exact reason I stopped using Bun for new projects.
Terrible project governance.
TS 7 is a good example of what a responsible team that cares about their users should have done.
Haha TS7 is the next biggest example of, "Let's just do a line by line port to another language instead of seriously examining our architecture"
This is the correct approach (I dare to say the only correct approach) when porting to another language. You can examining the architecture later.
If you can lock down a test suite that ensures parity, then who cares what shape the lift ultimately looks like.
A full rewrite in different language that fails to be idiomatic is a step backward operationally, even if you stand to gain on issues the new language just eats for free
I like your fair-mindedness but for folks who are anti-LLM-anything, your argument is not the point.
Evidence: see the amount of nonsense in the postgres rewritten in Rust story - https://news.ycombinator.com/item?id=48841676 where there are two contradictory claims made:
"postgres is so stable I will never trust a rewrite."
"covering 100% of postgres regression suite doesn't guarantee you have replicated every behavior."
Folks who are okay with LLMs think the regression test suite is the spec and is the guarantee of stability. How else can it be? If you are depending on some behavior not covered in the regression tests, how do you know the next minor release won't break you?
Folks who are against seem to imagine a platonic ideal of PG which conveniently is the original PG implementation by tautological definition. So no rewrite can ever meet their bar.
> Folks who are okay with LLMs think the regression test suite is the spec and is the guarantee of stability. How else can it be? If you are depending on some behavior not covered in the regression tests, how do you know the next minor release won't break you?
I think this deserves a real response.
First, an analogy. I drive along a cliff with no guardrail. How do I not drive off the cliff? By knowing how to drive. Sometimes people mess up and drive off the cliff
In practice people are operating Postgres as a machine, more than an abstract spec. Minor releases exist, but the changes are made by people operating the machine and who have a fear of making the machine break.
There are also performance characteristics that are part of an informal spec. While you can definitely write regression tests on performance, theres loads of value in stability of internals because people who have problems look into the machine and discuss it.
The internals might change, but there’s a lot of friction. So… you can have a lot of informal knowledge about.
If everyone working on a software stack is bathing in this informal knowledge, then the decision making is based on that. Things like what is meant to be in a minor or major release is understood. And people make those judgement calls.
After all, even if you have regression tests if you’re making changes you’ll need to write new tests! How do you know your new tests are right? That the new behavior is right?
PG is the entire machine. Fortunately we have version numbers, migration strategies, etc. But “here’s a new binary that passes the test suite and… maybe changes everything not covered by tests maybe doesn’t”. Why bother suffering when there are totally reasonable gradual rewrite strategies?
And of course… every bug in the world… got through despite a test suite! What software out there doesn’t have bugs?
And if the behavioral difference in the rewrite does affect people… I guess that’s something right? “Oh this isn’t a bug because it wasn’t covered in regression tests” is not that tenable.
>> There are also performance characteristics that are part of an informal spec.
They are not informal AFAIK - https://github.com/PGPerfFarm. A lot of these heavy duty OS projects have explicit Perf testing/nighlites (see Lucene's at https://benchmarks.mikemccandless.com/)
If you are saying the PG regression suite doesn't cover these perf tests - that is fair. I consider perf to be part of the "regression framework" generally.
>> How do you know your new tests are right? That the new behavior is right?
This is a more generic question in the LLM world. Reliable verifiers is what drives LLM loops. If you don't have these, you have no idea if you are actually making progress or you just generated code that returns 42 for every question. You needs something to actually ground the LLM output against. For existing features, the reliable verification is the existing regression/perf suites. For new features, the regression/perf suites should expand to fit. There are ways to go at this that range from ad-hoc (line/branch coverage) to fully formalized (verification-aware languages like Dafny).
I think what folks want, but aren't quite able to articulate, is an ongoing community and effort that indicate a project will be healthy and maintained. We want to be able to rely upon the software that we are choosing to use.
Regardless of the technical choices, whether Rust is better or worse, whatever -- pgrust popped into existence thanks to one person driving an LLM through 7000 commits in ~2 weeks. It produced something that passes the regression tests. Even as an LLM-sceptic, I think that's amazing.
From that point, though, it appears to have been completely abandoned. There hasn't been a commit in a month, other than a brief tweak and a note that an as-yet unpublished version that's even betterer is in the works. IDK. I don't think we've acclimated to the shock of the change LLMs create, but if the outcome is a forest of exciting new projects that have a bus factor of 1 and little to no collaboration, I think that's a disservice to this profession.
I am not saying anything about the viability of that particular project; just that one argument that was repeatedly made in that thread which I think is frankly nuts.
> If you are depending on some behavior not covered in the regression tests, how do you know the next minor release won't break you?
Decades of intrinsic knowledge. Which a rewrite lacks.
imho the issue is the language used. AI rewrites are cheap and cheap exercises require a great deal of scrutiny and proof of correctness. Simply using regressions test lacks the intrinsic knowledge of a decades old codebase stuck in developers minds.
Claiming a rewrite is better because it passes all tests is a flex, a new version requires a boatload of evidence for people to accept it as an improvement and not just "passes tests, written in rust via LLM so it must be better". Run it in production for a year in a sufficiently large system and you might be somewhere.
>> Decades of intrinsic knowledge. Which a rewrite lacks.
You mean the ones encoded in the regression suite? I think your argument is valid in many medium-to-faang firms where the application is going to have encoded business logic that isn't explicitly tested for. If anything, projects like PG are the exact opposite: no business context and regression suites that test every possible scenario due to the accumulation of bug fixes and context over many years.
>> Run it in production for a year in a sufficiently large system and you might be somewhere.
How do you know every release of PG doesn't break in the setting of "a year in a sufficiently large system"?
> no business context and regression suites that test every possible scenario due to the accumulation of bug fixes and context over many years.
Spend time enough with a codebase and you’ll know stuff about its behavior that is not encoded in a test suite. Especially when you need to adjust an integration tests due to the modification of an invariant in a dependency.
> How do you know every release of PG doesn't break in the setting of "a year in a sufficiently large system"?
Because the postgres team is professional and will take care of publishing a changelog for what has been modified since the last version.
Indeed as much I dislike the approach Bun took, at least the port appears to be working. TS7 is going to cause problems for downstream users because Go is the wrong language to use for something that has to run in WASM.
> TS7 is going to cause problems for downstream users because Go is the wrong language to use for something that has to run in WASM.
Is there a huge need to run that typechecking on browsers?
First, yes, the demand to be able to code natively in a browser is, I have reason to suspect, very large. It's just difficult to measure demand when nobody has ever offered a really compelling product. In engineering terms it's like getting a full-scale reading. The real level could be 1% above a full-scale reading, or the real level could be 100x higher than the full-scale reading.
Secondly, WASM isn't the right target for the browser anyway, JS and the DOM have to be what you consider "native", for the most rigorous UI projects at least (which building an IDE is). If you want to build a cross-platform UI product that doesn't require installation and has Emacs-like levels of extensibility, JS is the end of the line in terms of language selection. There are no other candidates.
> If you want to build a cross-platform UI product that doesn't require installation and has Emacs-like levels of extensibility, JS is the end of the line in terms of language selection. There are no other candidates.
calibre (with python+Qt) begs to differ. And I believe VLC runs on every current platforms. There's also Code::Blocks and Blender. Cross-platform UI is not rocket-science.
All great examples, but ones that do require installation. Their website is just where you download the product, I'm talking about making the website the product.
Yes, in the Monaco editor (https://microsoft.github.io/monaco-editor/).
It's not just typechecking, the typescript library is also the reference parser for TypeScript and reference emit. Emitting JS from TypeScript is non-trivial and non-local.
It's not just in browsers, you might want to run the typescript library on the edge or in some restricted environment where JS/WASM is OK but native code is not.
You may want to use the typescript library as a dependency in your own package. TypeScript becoming non-pure JS means that your library also becomes non-pure JS.
NodeJS can strip types internally without a straight TS dependency. I don’t think this matters, TS was a huge bottleneck for many build pipelines because it never parallelized well
Type stripping is not the same as emit, it only gets you a subset of TypeScript. Fine if you're running your own code, not fine if you want to run arbitrary TypeScript.
I think running a typechecker on its target platforms has huge benefits.
It is incredibly useful
Didn't WASM got a GC proposal that Go and other managed languages can use it? So it might be an issue in most browsers right now, but soon it might not.
It really does seem like they should have been able to do an incremental rewrite with FFI. Could have easily done it with AI too.
Yes, they probably don't know C ABI.
There's literally nothing stopping anyone from continuing the Zig version if they want to
You mean except the bugs in the zig version and any future CVEs?
> For me this outputs Bun v1.4.0 (macOS arm64). The most recent release of Bun on GitHub is currently v1.3.14 from May 12th, so that v1.4.0 version number in Claude supports them shipping a preview of a not-yet-released Bun version.
And so, the FOSS project "Bun" silently dies in darkness and is now something completely else. I'm glad I still had "Investigate if Bun is worth it" on my TODO list and hadn't yet gotten to it.
What is the governance structure for Bun by the way? Couldn't find any documents/explanations about how it's supposed to work. I'm guessing it's essentially just "Anthropic decides what gets done and accepted" today?
Why does changing to Rust kill the project? I don't understand the point here.
It’s made absolutely no negative difference, as we’ve seen in the real world in the last 60 days since the merge.
I feel weird having to defend reality; reality being that it was merged nearly 2 months ago and tons of people have had their pitchforks out without a shred of actual evidence that this made bun worse in any measurable way. But they still insist it was a mistake.
I’ve never met Jared or the bun team but I don’t understand all the personal attacks, I just feel the need to correct the facts. Literally who cares what language a JS toolset is written in?
It’s not like they ported JavaScriptCore (the actual JS runtime) to rust even. All that stuff is largely untouched.
>It’s made absolutely no negative difference, as we’ve seen in the real world in the last 60 days since the merge.
The rust code is not yet in a stable release, and CC only switched to it in the latest version, so there's not been 60 days of widespread battle testing yet, so i don't see how we could possibly say it will have no negative difference. It hasn't, because nobody is using it yet. It still might.
>Literally who cares what language a JS toolset is written in?
I don't care what language it's in, but i do care how it is written and maintained. I'm not going to trust my projects to a runtime that was written by an LLM in two weeks with practically no human review
>Literally who cares what language a JS toolset is written in?
Maybe you're being coy by asking a rhetorical question you already know the answer to but I'll answer as if you asked sincerely...
There are 2 different groups interacting with software products:
(1) end-users : this is where the "Who cares what language it's written in?!?" is usually applicable. E.g. The finance guys using MS Excel don't care whether it's written in assembly, BASIC, or C Language.
(2) code contributors and/or programming language enthusiasts who see other projects as "validation" of the whatever language they've invested in: these people definitely care.
For all the decades that computer languages have been debated, Group (2) will always discuss projects language choices. E.g. reddit.com switching from Lisp to Python, the Linux kernel fiercely debating future Rust contributions , the Typescript compiler switching from Javascript to Go, Bun switching from Zig to Rust, etc.
People try to lecture others in Group 2 about "don't make a programming language your identity" ... but people are human and they can't look at all the above language choices as totally detached observers. They like to talk about it!
If one is a Zig coder that contributed to the previous Bun Zig codebase, we can't expect them to be neutral observers.
I think you're missing group 3, which is the "assume bad faith and/or bad outcome from any possible change to anything, and especially changes to open source projects that can be interpreted as exogenous, e.g. from an acquirer, and especially if that acquirer is a gigantic commercial entity."
There are not nearly enough disenfranchised Bun-on-Zig contributors to make a dent in this conversation. There are lots of Group 3s in every similar convo, for any combination of technology, project, and acquirer you can name.
I think most of the naysayers are in group 3 because there’s a lot of anger but never a single link to a blog post or analysis done by anyone to demonstrate a regression. not one. There are some that analyzed the quality of the initial rust code and use of unsafe but Claude has been chewing through those as I understand.
I thought that too but it looks like the usage of unsafe hasn't been trending down over time: https://news.ycombinator.com/item?id=48966569#48967630
https://github.com/oven-sh/bun/issues/30719#issuecomment-446...
Personally I chose not to disclose my findings in public to avoid this kind of outcome. Having a good laugh with others is not as important as keeping the result of this experiment undisturbed.
This also eliminates the chance of another round of marketing of LLM ability based on actual human contributions and I suggest everyone who is able to analyze the code to do the same - so that they cannot misattribute our ability to LLMs.
It was a PR issue more than anything else. It is also a proxy for Pro AI and Anti AI sentiment.
And for most part I don't think it was communicated well apart from the last blog post.
What about Group x.
You just AI generated 1 millions lines of code claiming it's for safety. Who exactly is to make any kind of security guarantees about this?
What was your safety guarantee pre-rewrite? If CVE scanners and aggregators is your answer, then well, this applies to post-rewrite as well.
Don't forget the group asking really dumb pointless questions like "who legally owns the rewritten code"
Afaik, under current US law (Thaler v. Perlmutter 2025^), "the Copyright Act of 1976 requires all eligible work to be authored in the first instance by a human being".
With regards to AI-generated code, this means the copyrightability (at all, not with regard to who owns it) turns on whether or not a human was substantially involved in its creation.
Existing decisions require evidence of pretty heavy and continued human guidance to qualify.+
To wit, autonomous agent created code (prompt -> machine churns for hours -> output) is explicitly not eligible for copyright.
Functionally, this is a double-edged sword.
On the one hand, it means anything coded with autonomous agents by Meta, Google, et al. can be legally reused if it leaks (because no one could hold copyright on it).
On the other hand, it leaves copy-left open source licenses in a weird place. If you convert open source (even MIT/BSD-style) code into something else with an autonomous coding agent... the result has no copyright (nor can ever in the US).
In this instance, Bun was MIT-licensed, no? Then it was shoved mostly-autonomously through an LLM for the port.
Now Bun-Rust is technically still MIT licensed, but if push came to shove it seems like US law's current position is that Bun-Rust would now have no copyright license (because the manner in which it was developed renders it ineligible for copyright).
That's on the copyright side.
On the infringing usage side (i.e. whether you were entitled to shove a copyrighted work into a coding agent to produce something)... that's still TBD.
^ https://media.cadc.uscourts.gov/opinions/docs/2025/03/23-523...
+ https://garrettham.com/ai-generated-works-copyright/
Couldn't it be argued that Bun-Rust is still MIT licensed, because the old implementation was "in the first instance" authored by a human? All the machine did was translate it.
I think it's the "infringing usage" question that is more interesting. If the LLM trained on GPL-derived code, what does that mean for the end result?
"If the LLM trained on GPL-derived code, what does that mean for the end result?"
Either it means nothing at all, or it means that a substantial portion of the code produced at some of the world's most valuable companies over the last two and a half years is GPL.
Yeah you could argue that, but it's a messy argument. I'm wiling to imagine that they hadn't used AI to do the rewrite to Rust. It wouldn't have been all that hard to do with plain old syntax tree transformation (my expertise). The trickier question for me is the ownership at the boundary where prompts were turned into Zig code. That is not a process that could have been done with syntax tree transformation: creative freedom was given to the model as to how to do the work at that stage, and so that is the stage at which I'm least sure they could legally defend their claim to ownership.
I feel like that's a lot of LLM use in a nutshell: sure, there's a more surgical scalpel available, but isn't it so much easier just to fling prompts at a magic box?
> who cares what language a JS toolset is written in?
Anthropic, apparently, not the least because they blanket-closed all issues submitted before the rewrite. If the language were irrelevant, it shouldn’t matter for the existing unfixed issues.
> blanket-closed all issues submitted before the rewrite
You'll need a citation for that. While I'm still not sure whether Claude Code's issue tracker is worth much (Anthropic doesn't seem to engage with individual issues a while lot), it still has 5k+ open issues ranging back to March 2025. Bun also still has all of its Zig-timeline issues, all 5k+ of them. So what's this about?
imagine being the leadership of the one of most valuable US private companies in the world. then you have to make something called a "pull request" that gets "reviewed" by someone named "Jarred" to make improvements to your stuff. do you see how that is untenable?
the language is relevant for political not technical reasons. you could say, blanket closing the Issues, getting rid of this thing called Jarred from your stack, etc., is really an attack on the GitHub and the GitHub Agitator Lifestyles, which is why so many commenters on Hacker News actually care.
> It’s made absolutely no negative difference, as we’ve seen in the real world in the last 60 days since the merge.
This is even more interesting given that prewar Bun was not a well respected code base. This matters if the code was bad, were the tests bad / not comprehensive as well? If so, the translation to rust whose sole / primary target was test-passing will have a fair amount of undocumented bugs in it.
> poster child for Zig programming language actually being the prime example of How Not To Write Zig Code
https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...
Did he say this opinion before the rewrite, or when he was taking tens of thousands of Bun's money per month?
> that this made bun worse in any measurable way
Issues on GitHub was mass closed claiming zig is no longer relevant without fixing the real issues.
Whole classes of bugs WERE fixed by moving to rust. wouldn’t that result in mass closures of classes of bugs that were no longer relevant in rust? What would you prefer?
Whole classes of bugs are fixed by safe rust. This is not safe rust. As a line-by-line translation with unsafe forced anywhere necessary to make it compile, this should result in no classes of bugs fixed by moving to rust.
I would prefer they confirm before closing. It's AI / bot anyway. Instead it's just mass keyword zig = close. The bug can still exist post-port. None of it got "fact-checked".
In fact a lot of "feature requests" like npm compatibility related or missing specs etc ALL also got closed for being "zig" because reproduction and suggested solution were of course zig.
Again doesn't mean it got "auto fixed".
this whole AI era has put the topic of "do we believe actual reality, or what we hoped/assumed/continue to insist would be reality" front and center. Every discussion is like this these days.
The crux is:
> What is the governance structure for Bun by the way? Couldn't find any documents/explanations about how it's supposed to work. I'm guessing it's essentially just "Anthropic decides what gets done and accepted" today?
And this is a valid question. You are not "defending reality" by refusing to listen to it.
In summary and based solely on my understanding:
- Jared misled people about the intentions of the migration. It's not the worst thing in the world, but it's certainly worthy of criticism.
- Jared has commented before about locking out human contributors from open source projects. Whether he was making a larger point is irrelevant as his comment stands on its own.
- Other Bun contributors, past and future, outside of those employed by Anthropic, did not and likely will not have equal access to the model Jared used for the rewrite.
Jared, working in the public Bun repository, used tooling not available to his community to experiment with a signficant migration. He dismissed all concerns and told people it's just a bit of fun, and that it shouldn't be taken seriously. Most of the controversy would have been avoided were the experiment done in private.
None of this is a big scandal but questions about the project are entirely justified.
> I'm guessing it's essentially just "Anthropic decides what gets done and accepted" today?
Similar to the Claude Code 60s timeout incident [1] it could just be "Jarade decides what gets done and accepted"
[1]: https://news.ycombinator.com/item?id=48949942
Sometimes the questions aren't justified, though, like when someone else’s project is someone else’s project.
It seems like when some folks see “open source” they think the project maintainers owe them something.
An open source MIT license of the source code is very different from being the original copyright holder.
The outrage was more how the rewrite was communicated and defended, which was objectively poor.
Which was completely bonkers -- it happened completely in the open, people were just outraged that something like this happens without asking them and not on a schedule they perceive as adequate. Most of them haven't really grasped what was happening and why. Many still don't.
> it happened completely in the open
You don't create PRs like this when you're working "completely in the open"
https://web.archive.org/web/20260509235415/https://github.co...You don't test CI before you publish stuff?
I give the PR a proper title on creation. I don't see any reason to create a PR with a title of "test ci" and then rename it later to:
It wasn't out in the open. It was never announced or discussed ahead of time. It was just done because the company who purchased Bun wanted it done, and they only communicated it was happening once they started.
I don't consider the following comment to be good, honest, and open communication:
https://news.ycombinator.com/item?id=48016880#48019226
What was dishonest about that comment?
> There’s a very high chance all this code gets thrown out completely.
... and a few days later he decided that the code wouldn't get thrown out. That doesn't make the comment itself dishonest, he didn't have a crystal ball.
You can absolutely argue that the rewrite was not communicated clearly once they committed to it, but I don't think the comment you linked to there stands as evidence of poor communication at the time it was written.
He knew he wasn't going to throw out the code when he made that comment.
I think he didn't know. We are at an impasse.
Except that it hasn’t yet hit the real world, the live release is still 1.13.4, the last Zig version. Anthropic does not operate in the real world.
The canary build has been Rust for over a month, available to anyone. In that time it has been used in production for Claude Code and Prisma Compute.
We found the Rust based canary version to solve a number of memory leaks that we were struggling with in the Zig based 1.3. One of our engineers wrote up the details here: https://www.prisma.io/blog/bun-rust-rewrite-prisma-compute
Not sure why this purely factual post got downvoted. Upvoted it.
Rust as a language is irrelevant to this discussion, the problem is that bun was vibe coded by a single dude without any open source community involvement. “bun the open source project” is basically dead at that point: don't expect any of the zig enthusiasts who had their code being forcibly rewritten in a language they don't like to follow Jared.
“bun the JavaScript runtime ” is not dead though.
I agree, it's unfortunate the headlines seem to have become 'rewritten in Rust' (not a bad thing) and not 'vibecoded in a week without review' (a bad thing).
"Vibecoded" is not an accurate description of what actually happened. LLMs are extremely good at porting code from one language to another while preserving semantics. Which is why how everything turned out so well was not very surprising.
"Preserving semantics" by casting pointers to aliasing refs in Rust, ignoring lints and errors in the process.
Can't help laughing at this point.
I don't know, did the prior vibe-coded Zig code not ever have pointers aliased to data? Might be preserving semantics too well, if anything.
The Zig one uses raw pointers. These are bad and get out of hand quickly but at least don't have constraints like "you must never have two &mut on the same value". You may refer to c2rust to see how "semantics preserving transformation" without new UBs looks like.
You didn't read the blog post at all did you? Clearly you have zero clue what you are talking about.
Sorry, I did. And I did an internal sharing with respect to the blog post, on topics of how to (and not to) do software migration, how (not) to deal with unknown unknowns etc. We have several ongoing software (automated) migration projects so I did rather extensive research around it.
I do regret that I've also read the code though, otherwise I'd probably live a little happier with ignorance right now. Sadly as they don't know they don't know about the issues, there's no indication of those in the two public materials they have released.
Rust as a language is not relevant, but the Rust community still helped to popularize the idea that trashing a community by a rewrite is ok if it serves some "higher goal". This rewrite is just a striking example why this is problematic.
Surely a lot of review has happened in the last two months?
Reviewing is meaningless while they are still keeping the 10433 (sorry it has become 10503 since last week) unsafe blocks, most unsound and none encapsulated.
Any review would get to the simple conclusion that this should not be released before all the obvious bads are sorted out.
This feels like such an absurd, bad faith take I keep hearing.
In Zig, every single memory operation is unsafe.
And Bun must interface with C code that has no safe interface, necessitating a ton of boundary-level unsafe behaviors.
There's too much, sure, but can we at least be honest and reasonable?
What's the point of rewriting it to Rust if you're going to, on purpose, disable the most prominent benefits of using Rust?
It isn't disabled, it has exclusions. Now that they have it, they can close the gaps. It was literally impossible to have ANY coverage before, now they are mostly, covered and have an avenue for remediation.
I don't understand why folk are having such a hard time understanding why you do large projects in multiple steps? 80/20 rule? Perfect is the enemy of good?
Was nobody here for moving billions of lines of JavaScript to Typescript? It starts with declarations, then turn on type checking gradually inside the codebase: piece by piece until done.
I like Rust and use it full-time professionally. Unsafe is not the same as unsound. Unsound means that the unsafe code is not maintaining the aliasing invariants on references required by the language, and thus undefined behavior can leak into safe code (that is, the safe code can be miscompiled).
Known unsound code should not be merged, let alone released to production. If you have good enough tests and run them under MIRI or ASAN, maybe you can get away with it for a time, but most Rust experts would not sign-off on such a project.
If somebody put a gun to my head and told me to make the best of such a codebase, I would try to figure out how to turn off the LLVM optimizations that assume the Rust references don't alias. With these optimizations this codebase is scarier than most C or C++ code.
I'm not a rust dev. But I've been once asked to take care of a TypeScript codebase and the thing was littered with so many casts to `any`, you're wondering why they bothered with TypeScript in the first place. Some people do choose tech on a vibe and not any real analysis.
My conclusion was formed in my two months long tracking of the repo activities. They have done absolutely nothing in that front. (Well, to be precise they tried to fix exactly one thing that was pointed out but that's it)
> must interface with C code that has no safe interface
Yeah so the sane first step is to create encapsulated, safe interface for them, especially in a project like this. Deno for instance have ~0.2x as many unsafes.
And mind you if you haven't read the code, the vast majority of unsafe blocks in bun are for raw pointer access to local (Rust) objects because their ownership was a mess both before and after the rewrite. Also funnily enough a lot of the access patterns are wrong (in the Rust sense), leading to hundreds of new undefined behaviors.
> be honest and reasonable
Well, well. Talking about dishonest and unreasonable behavior, why is bun releasing a new version before solving any of those glaring issues? I'd remind you the current new version is not an improvement compared to the previous one, both in terms of correctness and maintainability.
> Deno for instance have ~0.2x as many unsafes.
Another point of comparison is density of unsafe: the number of unsafe blocks per line of code and/or file. By this metric, Deno has a bit over half the unsafe (because the bun rewrite is significantly more lines of code).
> I'd remind you the current new version is not an improvement compared to the previous one, both in terms of correctness and maintainability.
Except, you know, multiple real companies saying that it is and using it in production. And the fact it closed all known memory leaks. And that nobody has a really pointed to a single actual issue the new version introduced after two months of endless, ceaseless bitching.
I'm also fascinated by all these people upset at Jarred for harming the readability of a codebase they've literally never cared about before it become drama. Bun has almost exclusively been maintained by Oven employees since it's inception.
> Deno for instance have ~0.2x as many unsafes.
A project written ground-up in Rust idiomatically, with a smaller surface area, still has an unsafe footprint within an order of magnitude compared to this automated rewrite from an unsafe language with different practices and known bugs? That's not exactly the slam you think it is.
> nobody has really pointed to a single actual issue
I personally know 3 categories of newly introduced issues spanning the code base with 200+ occurrences, that leads to undefined behavior and memory issues. Not doing any contributions to the code is my conscious decision, which includes not pointing to the specific problems in public.
It's nice to hear that people are doing the same.
Is the idea that a code base reset makes something stop being open source? Or that the number of people doing the reset matters?
I don't see why either of those would be true. The project isn't dead just because it's in a different language now, and for liveness purposes it doesn't matter how it got to that different language.
I think the point is that an “open source project” is more than just the code and license, it’s also the community that builds and maintains it.
A fast rewrite of Bun in Rust has effectively alienated most of the people in the Bun community, so in that sense the “open source project” has died. It’s no longer a community project, it’s just become a personal project again.
Just so everyone know, Bun is and has always been owned by a YC funded org with full time employees. The overwhelming majority of commits came from them.
A reset is very different from not being open source any more. If losing most of the community would mark a project dead in open source terms, then every new project would be dead on arrival. And that would just be silly.
> bun was vibe coded by a single dude without any open source community involvement.
I think even this is largely beside the point. The acquisition of any project by Big Capital (whether tech or VC) is usually a killing blow.
That's just like your opinion...? More power to Jared (and anyone else) if they can "vibe code" useful projects like bun.
I am impartial on the matter, but I think one of the reasons Bun became a thing in the first place was because of Zig attracted a small but very active developer community. Switching from Zig to Rust effectively alienates that community.
I think the Zig people are really just worried that maybe Zig itself is a DOA language before it has even reached 1.0 because it doesn't offer enough over C for any serious use and their flagship project has now abandoned it.
Anyone actually using it knows it is better. The C interop is so good that there is no use-case where C is the better option IMHO
You, by your own admission, haven't even written a single line of Zig despite having ~31 Zig projects on GitHub. I don't think your knowledge of the language is to be trusted in almost any capacity. This might seem harsh but I don't trust someone who's experience with a language amounts to slopping out 30+ repositories and not even engaging with the language normally.
I guess that since you haven't built the car you're driving, your opinions on it are null and void as well.
Anyone who actually believes that I can't have ANY sound opinion on Zig after 31 projects building with it should get their head examined for brain tumors. I mean, it's not like I have to deal with all the positive and negative effects of things written in it. It's not like I've had to solve problems in it that emerged when the LLM didn't do things correctly (and yes, I can tell when this is so, and not just when things are buggy). And it's not like I don't know (by heart, not by LLM) at least 15 other languages that I can draw on (C, for example, for which I not only got an A in a class at Cornell once, but was in fact the person with the highest score in a class of ~150 people... A perfect score, in fact) to form valid opinions in combination with how I see Zig working.
So please take your baseless skepticism and baseless assumptions and shove them up your ass, dude. I have work to do, and I'm far more capable of it now than I was, thanks to the LLM boost.
By my own admission I wrote ~100K loc in zig-head. Having a background in linux kernel development of all things I can tell you that Zig is so much better than C or Rust, that I think linux kernel rush to rust is misguided.
I haven't even stated whether I agree with the opinion that Zig is worth it, in fact I do think Zig is worth it for a large set of problems and I wrote Zig for years, I am stating simply that I would never trust anyone who's self-admitting that they don't even write the language they're arguing for when it comes to opinions on whether it's good or not. It's not really about whether Zig is good, it's about someone who doesn't even write the language and doesn't even know it, not having a valuable opinion on it.
Same. In fact I think going to Zig, possibly on the way to Rust, would have been a far more pragmatic route.
But I guess my opinion is null and void since I "slop-code"
Industry standards, existing team knowledge, use after free story is the same as C already has.
Bun was the flagship product of zig? In reality or in YC land
Zig is a DOA language for other reasons though. The reason why Rust enthusiasts act so morally superior is because they are:
> Rob Pike, an unsafe guy, may insist that a small language and garbage collection are enough. But the typesafe visionary Grzegorz Wielbodłąński understands the deeper truth: every invalid state permitted by a compiler is a tiny act of civilizational sabotage.
https://x.com/typememetics/status/2078572052680790237
There is no sense pretending anymore that languages with as many gotchas as C and Zig are "simple". Quite simply, they are not. The complexities lie in what's left unspoken, unaddressed, and of course undefined; failure to comprehend these completely can be catastrophic. Rust is so thoroughly and obviously the correct thing that using anything less correct should be taken as a sign of engineering incompetence.
> There is no sense pretending anymore that languages with as many gotchas as C and Zig are "simple". Quite simply, they are not. The complexities lie in what's left unspoken, unaddressed, and of course undefined; failure to comprehend these completely can be catastrophic.
This is where I’ve arrived too. After nearly 20 years of programming I feel done with leaving foot guns lying around. Languages that are full of them, but “fine” as long as you take extreme care are not interesting to me. I’ve started calling this “simple as long as you avoid all the foot guns” idea the sword juggling fallacy[0].
It’s too bad about Zig because it has many nice ideas, in particular allocators, that I hope Rust or some future language will adopt.
0: https://hugotunius.se/2026/06/15/the-sword-juggling-fallacy....
yeah rust has no footguns. just dont try to mix clone with iter.
Of course Rust has a few footguns too, that's not my point.
There are many things in life that are "fine" only when you take extreme care (knives, cars, industrial machinery,...). The thing is something like C has many usages and you can't just say "use Rust" and be done with it. Using Rust is not cost-free.
I'm not saying "never use C". The thing I dislike is the false dichotomy between "(Zig|C|Go) is simple unlike Rust, which is complex". A statement like that makes it sound like writing correct code in the former is easier when it's, in fact harder.
the thing is, as a pattern, footguns in zig are simple and easy to reason about (though they might be hard for an ADHD human to find). the compositional nature of rust sometimes makes footguns "hard to see" because they can be hidden behind layers of abstraction.
there is a potential future where an llm with unbounded patience would have an easy time literally walking through the zig code looking for one of the footguns might miss a footgun in rust because it's abstracted away. the ones in the stdlib should give you pause. what is hiding in some third party library's code?
There is more to it even, the UNIX and C founders arrived to Go, before retirement, after a few other interactions.
AT&T was the one doing the Cyclone research.
And then we have a bunch of folks assuming they know better about C that its own authors?
> And then we have a bunch of folks assuming they know better about C that its own authors?
Barthes aside, C's changed a lot in the years since they left.
Yes they stopped caring after C89, Plan 9 C compiler was a mix of C89 with extensions.
Still they are the authors, and withdrawing from WG14, going their own direction with Alef, Limbo, and finally Go, kind of proves the point they considered C done for its original purpose.
> kind of proves the point
I don't think it proves anything other than the wanted to work on something else.
It is a bit of presumptuous for one to assume to know better about something than the original authors.
Something was designed in a certain way, accomplished its goal of writing portable UNIX, and then design by committee took over.
The authors, with their experience moved on, the committee and the audience doubled down on the flaws.
The post you linked to seems to jump to conclusions, to say the least. For example:
> One probable outcome of an unsafe-language-dominant world is full Andrew communism, which is precisely what Andrew “Smelley” Kelley proposes: abolish ICE and replace the market economy with a globally distributed network of community-maintained allocators.
> Rather than a commercial product, software becomes a “public good,” ultimately provided by the Zig Software Foundation as manually managed digital infrastructure.
Calling him "smelley"? Really? Pulling in the political views of the founder of a language and claiming that they inform his language design as part of a grand conspiracy against Rust/capitalism? Where are they getting all of this? Free, open-source compilers and related tooling (both of which Rust and Zig have) are already public goods managed by global communities of mostly volunteers
> This future strikes me as a dystopian hellscape, but I have never met an unsafe-language advocate who could explain how this ecosystem is supposed to sustain itself without unpaid maintainers, ideological volunteers, subsidized infrastructure, and endless donations to compiler projects that still cannot protect users from basic memory errors.
How is Rust any different than Zig in this respect? Both are projects largely run by nonprofits relying on communities to promote, maintain, and improve them.
Frankly, that entire "Institute for Type Safe Memetic Research" seems like either an elaborate satire or an account run by genuinely insane people who think type and memory safety are paramount societal issues.
> run by genuinely insane people who think type and memory safety are paramount societal issues
So. Rust evangelists ? :)
But yes, it is wild that people can honestly quote such drivel as evidence of the language and its philosophy being superior.
Each time I try to evaluate Rust, I do so on its own merits. Going online I am rapidly convinced that I don’t want to be in the same room as a large chunk of its userbase. Statements start to sound a bit like that one time I was dragged into a pentecostal meeting.
If you saw the "Institute for Typesafe Memetic Research" and thought, "This is the den of Rust evangelists!" I don't want to break your illusion, because it's much funnier this way. Especially since there are like two people that like Rust on Twitter, and I'm one of them.
BTW did you hear about this:
https://babylonbee.com/news/democrats-say-they-are-perfectly...
OR
https://www.youtube.com/watch?v=bXEddCLW3SM
> Calling him "smelley"?
Turnabout is fair play.
> Frankly, that entire "Institute for Type Safe Memetic Research" seems like either an elaborate satire or an account run by genuinely insane people who think type and memory safety are paramount societal issues.
You've been had. Your entire rant means the bait worked.
You didn't just quote The Institute of Typesafe Memetic Research as proof of anything...
It's a shitposting, hyperbolic bait account. As funny as calling Andrew Kelley Smelley, it's not meant to be taken as gospel.
If this were true the very small but active community of Zig contributors could just fork it and you could all return to the happy times of not using Bun anyway.
Bun became a thing because it provided some specific benefit to js ecosystem. Zig enabled the rapid development. The people who contributed were definitely helpful but they can still choose to help or not and new people will step up too
> new people will step up too
Or they will not… how could you possibly know.
Emphasis on the FOSS project. The v1.4 mentioned is not (yet?) open source, Claude Code is essentially using a proprietary fork, was GP's point.
It's a canary releasing directly from main: https://github.com/oven-sh/bun
We have run it in production for a month: https://www.prisma.io/blog/bun-rust-rewrite-prisma-compute
You can install it now we with bun upgrade —-canary it something along those lines.
I think you’re missing a word or two.
Based on comments elsethread, I think what was meant is: You can install it now with “bun upgrade --canary”, or something along those lines.
However, people also report that the canary version doesn’t identify itself as version 1.4.
It does.
It's extremely obvious what they meant, even if it/or wasn't a common phone autocorrect typo.
And GP is full of shit as the main branch is the v1.4.0. it is not "released" yet as it is not finished. It is available as canary version.
So Anthropic ships with unfinished version of bun.
Doesn’t sound like responsible software deployment
They can ship with whatever they want as long as it works.
Given the permissions Claude Code gets on many systems they should be more professional.
They are basically testing the rust port on user machines.
Who come that since the rise of AI all principles of software development are thrown over board?
Bun is now mainly the runtime for claude code. All changes will go in to make claude code better.
It's not about making the dev experience better than node, that use-case is now secondary.
The objection isn’t to the language. It’s to Claude using a version of Bun that is not available to us. We don’t know what’s actually in it.
Why is that even a thing to object to? You're talking as if you placed stock in the bizarre idea that Anthropic would close source the project and start charging for it.
Stay your pitchforks.
I wouldn’t use language as strong as OPs but it is against the spirit of FOSS for a corporate owner to use a private prerelease version of their open source software.
I think it’s valid to object to. If 1.4 is good enough to be used by Claude, why not us?
So you wouldn't, for example, after doing a complete ground-up rewrite, perhaps spend a few months dogfooding it to work out the worst bugs before unleashing it upon the public, thus maximizing your initial velocity by minimizing the blast radius and support requests and triage during this phase?
It's Anthropic. I am pretty sure they spent time dogfooding it to Mythos or an even more advanced model.
That might even be the reason why they switched to rust.
Don't worry too much.
> before unleashing it upon the public
…but they have? Claude users are public, no? If they were dogfooding internally I’d agree with you.
Yeah. One single project that they control. Not thousands of other people's projects breaking, I'm sure with a ton of HN outcry over releasing "this pile of vibe coded slop" upon the poor populace.
You just can't win.
> you just can’t win
You could! You could not release a “pile of vibe coded slop” onto people’s machines. There don’t even appear to be any particular advantages to Claude upgrading early. If there are no one has been made aware of it.
The irony. A company building models and tooling to automatically produce code being attacked for using automatically produced code in the very tools that allow people to automatically produce code, presumably by somebody who wants to use their tools to automatically produce code, possibly because they believe that their approach at ensuring that automatically produced code is properly reviewed by a responsible human has to be more thorough than whatever that company does because of course they were going too fast and thus it can't be good
How do you know it's vibe coded slop? Have you seen the source code?
> How do you know it's vibe coded slop? Have you seen the source code?
I believe you've just made your opponent's point for them.
Have I? I believe I've merely chased them around their moving goalposts. When it's closed source, that's nefarious because "they're not sharing" and that's against the whole spirit of open source. When it's dogfooding with a reduced audience, it's "shoving vibe coded slop on people" (this information gleaned through magical knowledge). When that unfounded assertion is called, lo and behold: It's closed source, so bad bad bad! It's called a logical fallacy for a reason.
But more to your point: Do you believe in "guilty until proven innocent"? Do you believe that they're doing bad things with the bun code, and you can't be convinced otherwise in your judgment of them until they release the code?
More to the point, because you've been chasing them around goalposts, you've both accepted that the question at hand is unknowable precisely because the source isn't available.
> Do you believe in "guilty until proven innocent"? Do you believe that they're doing bad things with the bun code, and you can't be convinced otherwise in your judgment of them until they release the code?
Hell yes, and anyone who trusts one of the AI labs for anything important is insane.
Whether it's their initial mass piracy and then lying about it, dealmaking with the US government, or continually shifting opt-out lines on what they are and aren't training on, they haven't earned the trust to skip the "but verify" step.
Their economic incentives are too transparently aligned with ends at any costs.
You're running a closed source piece of software (claude code), running on an effectively closed source piece of software (bun), both of them updated daily by AI psychosis bros.
At this point, charging is the least of your issues.
It may be available to us, in the form of a git checkout of their public repository.
It's true that we don't know exactly which, and whether or not there are any other changes added on, but that is the case for every single release of Claude Code that has used bun.
It's probably not. I tried to extract the commit hash from the version of bun packaged in claude code. the commit hashes from previous versions resolve, whereas the commit hash for the current 1.4.0 isn't available.
from strings:
This build does have a different way of identifying itself than earlier builds so it's possible this string isn't correct.(In contrast, earlier builds that I have locally have commit IDs that can be found in the public repo). I don't think it's particularly damning for them to vendor a canary release, mind you.
That is also true of the rest of their codebase, no?
Moving the goalposts?
No? I think OP’s comment was very clear:
> The most recent release of Bun on GitHub is currently v1.3.14 from May 12th, so that v1.4.0 version number in Claude supports them shipping a preview of a not-yet-released Bun version.
> And so, the FOSS project "Bun" silently dies
There’s no implication that it’s because of the switch to Rust.
> The objection isn’t to the language. It’s to Claude using a version of Bun that is not available to us.
I was responding to your GP comment. For weeks, it was uproar over the blanket AI move to Rust and now it’s this reason. That’s why I said the goalposts are being moved.
That seems illogical to me. We’re only allowed to have one objection to a project and once that’s used up we can’t air another? FWIW I don’t think people have forgotten the original objection either!
You can; it feels contrived and very social justice warrior/anti Anthropic (which on HN is in of itself almost a meme now). The main reason was because of the blanket AI move which I could understand.
I think your perception of events is pretty heavily affected by personal bias here. Objecting to a hasty AI rewrite of an entire runtime and objecting to violating the spirit of FOSS is “very social justice warrior”?
What?
Please re read your original comment. AI rewrite is one thing and objecting to FOSS/non FOSS is a new argument, anti-Anthropic etc is moving the goal posts. The main argument was the blanket rewrite to Rust using Claude.
Now, /you/ are trying to move the goalposts into an entirely different argument.
Very likely it’s just anti Anthropic altogether.
Like I said, a meme.
Anthropic hasn’t done anything wrong but if they move a single inch then people will complain. Perhaps it is just a preview version?
Airing two entirely separate objections to a project is not “moving the goalposts”. The original objection still stands! You’re using a phrase you’ve heard in an inappropriate context.
I’m sorry but this is a nonsensical debate.
> Now, /you/ are trying to move the goalposts into an entirely different argument.
You said something and I responded to it. That’s invalid too now? There can only ever be one single objection in a conversation? I’m not permitted to react to the things said? Like I said, nonsense.
People are now saying poor communication because the Bun creator was not able to see the future and didn’t immediately flag his draft rewrite as the next big thing when he started working on it.
> For weeks, it was uproar over the blanket AI move to Rust and now it’s this reason. That’s why I said the goalposts are being moved.
I'm just one person though, and have no problem with a move to language X, using tool Y, who cares?
For "goalpost are being moved" to be valid here, you have to be able to point to someone saying one thing at one point, then same person putting a different target later. You're folding a huge group of people into one person, when that's not really accurate to do.
https://news.ycombinator.com/item?id=48843352
https://news.ycombinator.com/item?id=48837877
Your point being? None of my comments in either of those state that I'm upset about it moving from Zig to Rust?
I wasn’t referring to you and rather the general sentiment. Hence, goal posts have been moved again comment.
My overall larger point (maybe poorly stated) was that unless you're engaged specifically in a 1-on-1 conversation with someone, accusing a whole community of "moving the goalpost" makes no sense, there is a whole host of arguments and points being made in different directions all the time, by different individuals.
I see what you are saying. My comment is rooted in the fact that different people are foregrounding different objections to Anthropic/Bun, and taken together it looks like whatever launches, someone will find a reason to be upset
Maybe you should consider the objections by their merit rather than just being angry someone dares to criticise anthropic?
Already did, a few comments up. Happy to go through specific objections again if useful. This particular comment was about thread-level dynamics, not a verdict on any one objection’s merit.
Yeah same, according to one of the Zig team members, the original source code wasn't all that anyway.
But this is HN, a subsection of which places a high importance on what language something is written in, moreso than what it does (feels like).
An interesting tidbit is that large parts of the original Bun source code was a line-by-line port of esbuild from Go to Zig (mentioned here: https://bun.com/blog/bun-in-rust), tbh this lowered my respect for the project a bit (a line-by-line port simply isn't as interesting as original work), and it might also explain the subpar Zig code quality (a line-by-line port from Go to Zig simply won't result in idiomatic Zig). It also might explain why porting from Zig to Rust was done 'on a whim', the actual source code (and the idea of 'original work') never seemed to be all that important to the author (and I wouldn't be surprised if the project does more language-hopping in the future heh).
I read your link, written by Bun's author and totally get his thinking.
In the current world of cyber weaknesses everywhere, infrastructure must be solid and rust is a better choice than zig for something like bun.
In other words, bun is not a demo of zig programming that happens to do useful things. Bun does useful things, and must do them securely. That is its number one priority, language is secondary, inasmuch as it helps doing useful things securely.
Are you really "doing things securely" when you use as many unsafe blocks as the Rust port of Bun does?
I don't think you can claim your code is secure, or can claim anything at all about your code, if you haven't written the code and have no idea what's in there.
Rust protects against a rather small group of memory error, if and only if the unsafe sections are actually correct. And nobody knows if they are correct or not, plus there can be millions of logical errors that can be exploited.
See how many CVEs uutils has… quite a lot for a supposedly secure rewrite of GNU coreutils.
I don't think the GP had anything to do with the language change itself. More that it marks a clear point of Anthropic taking ownership and governance of the project in a less open direction.
Definitely, it was a possible reason why Zig actually matters in the industry.
Now it is a Deno clone, both without anything enticing over node.js.
As an open source - community driven project? Have you looked at the repo on github?
Theres thousands of PRs from claude agents or whatever.
Yeah really feels like a worthwhile place to contribute lol.
> As an open source - community driven project? Have you looked at the repo on github?
FOSS as in FOSS - Free and Open Source Software. Has nothing to do with if it's community driven or not, I'm strictly talking about FOSS.
I didn't read OP as complaining about the rewrite, but about the (lack of clear) governance after being acquired by Anthropic.
My personal feelings about the matter is that having an LLM rewrite the entire thing as an experiment and then just going with it a few weeks later kills any incentive for a community to build up around it. It's a clear signal that every basic aspect of the runtime can change on a whim.
I don't care about meh Zig being rewritten to bad Rust if it does the same thing, but taking what is presented as" look at this funny experiment I did" and then taking that into production with barely any announcement is what kills off the interest to me.
Bun has been a great ad for whatever LLM they were using but the cool factor is gone now, and that's really what set it apart from basic NodeJS in my mind.
> taking that into production with barely any announcement is what kills off the interest to me.
Did Bun v1.4.0 release weeks ago and I missed it? I would call a formal release the point that it goes "into production", and I think dogfooding it via Claude Code is yet another form of testing Bun-in-Rust before the latter goes to casual users.
Which community specifically though? The overwhelming “user” community would be web developers and people writing JS/TS, right? Not zig/rust developers.
There were very many open pull requests from the community that were all invalidated overnight for something that same community was assured was merely an experiment.
The normal process would be "hey, this experiment is going well, we've made this plan, come help us shake out the new codebase for the switchover in X time." None of that happened. There wasn't even an announcement, just a silent commit that trashed hard work from hundreds of community members.
None of that is needed. Nobody benefits from all that time wasting bureaucracy/corpo speak. Bun is quick to deliver new features and bug fixes. With this change, the hope is that'll only get faster.
All those PRs can be fed thru Claude and converted to rust and then manual polish can be added.
Bun is riddled with bugs. That's what moving fast and breaking things gets you. It gets you famously bad codebases that are nightmares to work with and slow you down over time as your sins catch up with you. Vibecoding is not enough.
Then why do you care? If target users (developers) face issues with bun, they will stop using it. Go back to Node or switch to Deno.
Bun has bugs? yes. Do they affect vast majority of users? Not really. Been using bun for about 3 years; never had an issue with it.
Are you interested in the discussion that was taking place before you popped in or are you just here to get outraged that something you clearly identify strongly with is getting criticism for making poor choices?
"Because the discussion was interesting" is why I care.
Developer community. "Open source" historically implied that an interested developer might hack on the code and submit their changes. But if the entire code-base is rewritten by the maintainer every year, then there's no developer community.
It's like a couple of languages I know where there's still one real owner, and there's no real review, and PRs are unlikely to be merged, even with review: They might be open source, but it's more a source visible thing, because you are never going to get a change in, and the language will change directions at the creator's lone whim. The best you can get at times is "I didn't like your PR, so I implemented the feature you tried to add completely different". Typical community killers.
The language an application is authored in does not matter to me, as a user. I care that it is widely-used (safety in numbers), that it works, and that it is fast.
It's cool that the Zig project exists, but I'm unlikely to ever use Zig so that’s sort of orthogonal to my interests.
> Why does changing to Rust kill the project? I don't understand the point here.
I'm concerned that the complete rewrite in an entirely different language is not a sound technical decision and instead is a ploy to shed copyright claims from past contributors.
Now, based on comments from this thread, the formerly FLOSS project is somehow granting special access to a corporation that apparently is invested in going way out of their way to push implementations that consume the complete rewrite before the world has access to it.
I for one won't be touching Bun. This doesn't pass the smell test. It feels like a bait-and-switch in progress.
> I'm concerned that the complete rewrite in an entirely different language is not a sound technical decision…
Even if this was a terrible technical decision, it is a good, maybe even unavoidable, business decision. And I don’t think moving to Rust was a bad technical decision at all, given Zig is unstable and constantly changing, and that it’s not memory safe, which is a big problem for something like a JS runtime!
The reason it’s a necessary business decision is that Bun is owned by an AI company and Zig has a policy to not accept AI assisted contributions, making it impossible for Anthropic to contribute to a language that is still evolving rapidly, not to mention the bad marketing of using a language that basically is hostile to your product.
A lot of hypotheticals, conjecture, speculation, personal feels devoid of any facts. That somehow kills the project. ok!
> A lot of hypotheticals, conjecture, speculation, personal feels devoid of any facts.
No,not really. There is only one point: does Bun acknowledge that past contributors still hold copyright over the Rust rewrite?
of course they also gave away their own claim to be the copyright owner, but that's neither here nor there ; )
I don't care about the language, but pre-releases the community don't get access to but released (Anthropic) applications do have access to, feels a bit too on the nose after the acquisition.
The whole point of the outrage was that 1.4 was merged into main. Publicly. So I’m not sure what you mean.
Everything is in the open: PR #30412
> The whole point of the outrage
Ok, go ask those people what they think then, I feel no outrage over a project switching language or merging whatever. But when once-semi-transparent projects become more opaque after an acquisition, I'm starting to readjust anything to the project I had in mind.
That PR is the rust rewrite. That's some time in the past now. As of this comment, there is no tagged 1.4 release. This is the present. Anthropic is using apparently a version of Bun that is not publicly available. This is orthogonal to it being Rust-based, as all Bun releases now will be.
It's publicly available in the GitHub repository and if you run "bun upgrade --canary" - https://github.com/oven-sh/bun/releases/tag/canary
That commit (and main) still purports to be 1.3.14, the version numbers haven't changed. Does that not still suggest Anthropic is using something else?
I think Bun/Anthropic should document which commit hash their "1.4" as shipped in Claude Code uses.
Come on, "not publicly available"? You know how git works right? Each Claude release probably has the HEAD of main compiled as "1.4.0" until there is a real official release.
I do know how git works and in my experience, while the version number sometimes doesn't get bumped until just before a release is tagged, the version number comes from the codebase. If they're building something that says 1.4.0, then they have a codebase that disagrees with ours.
Where is the previous version referred to in the codebase? I'm guessing that would be the place to look for changes.
If you can't find an update at that place in the codebase saying 1.4.0 you can ask where it is. It seems after doing that and not receiving an answer would be the appropriate time to start making the claims that people are throwing around.
This seems like a candidate
https://github.com/oven-sh/bun/commit/b18bf6d1d0a92238f240bf...
The PR is public, you can build and use it as well. The anthropic team just decided to use it, and you can as well.
> The PR is public
I'm talking about the 1.4.0 release:
> Claude supports them shipping a preview of a not-yet-released Bun version
Maybe Bun/Anthropic fixed this after Simon's initial release of the blog post, but seemingly when we both looked, it wasn't public.
> Update: The Rust version has been released as Bun canary - running bun upgrade --canary will install this release.)
Does `bun upgrade` provide the source code?
Yes, it provides the commits for a "changelog". Canary builds track main closely, 98f664962 is the tip of main.
~$ bun upgrade [2.42s] Upgraded.
Welcome to Bun's latest canary build!
Report any bugs:
Changelog:Isn't the source code in the git repo?
v1.4 hasn't been tagged... No idea what the shipped binary corresponds to.
Yeah, of course Anthropic making the version publicly available AFTER people notice it wasn't public, completely solves the issue ;)
Anthropic changed nothing since I wrote published this post a few hours ago - I updated my post to mention Bun canary since it was a point of confusion here on Hacker News.
Claude Code has shipped Bun 1.4. already more than month ago: https://github.com/anthropics/claude-code/releases?q=bun&exp...
Version was changed in Bun in May 18
https://github.com/oven-sh/bun/commit/b18bf6d1d0a92238f240bf...
So it has been canary since then, most likely, if docs are accurate that latest main is canary.
You seem to be wrong about that
Nevertheless, the principles of open source never demanded more than providing the source upon request.
It's largely just what jarred is willing to accept this week afaik or not, and they did put the bun 1.4.0 version bump in the changelogs for claude code a while ago, over a month almost.
Though most will be forgiven to not reading it since well it's all AI anyways. I don't know how I feel about all this yet, maybe someday.. ooof
> they did put the bun 1.4.0 version bump in the changelogs for claude code a while ago, over a month almost.
Where? Is see no CHANGELOG in the root. I do see LATEST, last modified 2 months ago, and it says 1.3.14
The Claude Code release notes. Not the Bun release notes: https://github.com/anthropics/claude-code/releases/tag/v2.1....
> Upgraded the bundled Bun runtime to 1.4
(Though that doesn't clarify that this is the Rust rewrite)
I had "investigate if bun is worth it" too, and decided not to use it, but instability was one of the reasons. So it feels it was the right move.
Maybe I’m taking crazy pills, but I’m still stuck on “why the hell does a TUI need to run in terminal React by way of JavaScript”
The fact that Anthropic felt the need to buy a runtime so they could make their TUI better speaks more to the quality of engineering than anything else IMO.
If rewrites are so easy, why not rewrite CC in a native language? Would’ve been a hell of a lot cheaper.
It largely works and it's a massive business success. This is the classic engineer asking the 'why this technology?' to what amounts to a business question.
They chose it early on, it works, and it makes obscene amounts of revenue. End of story. That doesn't mean it was the "greatest" choice, or has a perfect technical architecture.
Rewrites are never easy, even the bun rewrite. But a non-UI developer tool with a rigid API surface contract (and associated tests) will always be easier to trust after a rewrite than a partially tested UI tool with ambiguous functionality.
>It largely works and it's a massive business success. This is the classic engineer asking the 'why this technology?' to what amounts to a business question.
Your counter argument would be valid for a 2000 or a 2020 business decision about some tech stack.
But the whole point of their product is that it supposedly nullifies such "business" concerns around the use of technology, by making it cheap and fast to build whatever you like automatically.
That they wont, or worse, couldn't, speaks against that.
Yeah, this is what I’m trying to get at.
There’s two arguments in competition:
1. LLMs make it cheap (in the time sense) and easy to build
2. Rewrites and/or writing something in a native app or program is harder and more time consuming
I think I am willing to take it as an axiom that a native version of CC would be superior from a user perspective. Performance, etc.
I just don’t see how one can say that building things reliably good is easy now when the company providing these tools can’t even do it well.
>2. Rewrites and/or writing something in a native app or program is harder and more time consuming
Why would it be harder and/or more time consuming rather than the opposite? It's like having full specs and a full test-suite to match against the result you want.
> I just don’t see how one can say that building things reliably good is easy now when the company providing these tools can’t even do it well.
I don't know how you can't see it, to me it's blindingly obvious: risk aversion.
Let's say the risk for a problem is 1%; hell, let's put it at 0.1% even. For a company at this scale even that amount of risk is too much.
I trust Opus/Fable to drive prod database migrations and backfills. I don't trust it with our financial ledger. I trust it with part of the infra. I don't trust it with backups. Etc.
You and others are arguing against a premise that nobody defended, namely "Claude can rewrite everything, for free and with zero mistakes". A bit of a straw man, don't you think?
And that's not even touching the fact that writing a GUI app is difficult for LLMs due to difficulties in it getting feedback and a "feel" whether it delivered what was asked (though I know people are working on it).
> I think I am willing to take it as an axiom that a native version of CC would be superior from a user perspective. Performance, etc.
How does that follow, and from where? I never once noticed any visual jank/lag in the TUI; not in iTerm2, not in Kitty, not in Alacritty, not in WezTerm and not in Ghostty. And even if we exclude those two, me and many other devs are quite fine with a TUI and don't miss a GUI program for everyday coding.
Not saying that our preference is superior -- but it'd be strange to blatantly claim: "for dev purposes, GUI > TUI/CLI".
Going to give a short reply to one point because I’m about to go to sleep (I try to make an effort to be honest as to why I’m not fully engaging with the entire comment) but re: strawman, I don’t think so. When Dario Amodei is saying SWEs will be replaced soon [0], I think it follows that then he believes Claude can write a native app as well as a native app dev.
0 - https://finance.yahoo.com/news/anthropic-ceo-predicts-ai-mod...
CEOs love to promise the sky and the stars. Color me unimpressed.
Now whether they can do it -- that's a separate, and a much more interesting, discussion.
Oh yeah, I mean I certainly think it’s a false premise. But it is a premise someone is giving.
> But the whole point of their product is that it supposedly nullifies such "business" concerns around the use of technology, by making it cheap and fast to build whatever you like automatically.
This is a spectrum, it's not just 0% vs 100%. Even Fable frakked up a few things really badly in my professional work (though to its credit after a very detailed 2h chat it self-corrected and fixed all the blunders).
I would also challenge "fast" -- Fable (and I assume Mythos) are wicked fast and efficient and even they can't compensate for f.ex. slow recompilations or test suite reruns or security scans, linters etc.
Reminder that the Bun's Zig-to-Rust rewrite took 11 days with dozens of agents working 24/7 and the author put the cost they'd pay (if they had to pay) at about $168k.
> $168k
Billions of dollars of annual revenue go through Claude Code, and the people who work on it must be a lot of millions in headcount.
The time matters a fair bit, it's probably time someone can't spend breaking things in the name of new features, but if rewriting the stack had even a tiny impact on retention or driving higher usage, it would pay back that $168k.
If only paying the $168k was some sort of a guarantee. Vibing doesn't give you that.
You might get more maintainable code for $168k by hiring humans, but if its something bespoke it isn't going to get you far (or far quickly).
Vibing is straight out gambling right now, the thing is, I don't know who the house is any more.
It's going to take an order of magnitude longer though, delaying any of that revenue significantly. I'm sorry, but we're talking 11 days here. What does "maintainable" even mean with impossible time-scales like this now!?
The new normal is there is no normal. No common sense, FOMO, YOLO, everything combined is what we're living right now :)
Perpetual complete rewrites. When there’s more bugs the LLM can fix, rewrite the whole codebase. Repeat ad infinitum.
True on the premise, remains to be seen if that's what's going to happen in practice.
In my work I have Fable/Opus add bespoke linters and tie them to verify/precommit tasks (including in CI) so nothing of the reworks and 15+ initiatives we have in flight ever regresses.
Some discipline will remove that worry of yours. It's not nice to immediately assume that the rewrite's orchestrator (Jarred) did not use discipline. He even outlined a few false starts.
.. by hiring the right humans - which is not always a given
Even worse: it's much safer to assume you'll hire the wrong humans, most of the time.
Yep, same thought. And it seems Anthropic agrees.
The company I work for is about 15mm into what is effectively a rewrite. Just a lone data point…
Millimeters?
I read "man months".
15 million dollars
15 million mollars :)
can't imagine rewriting a runtime to be easier than a coding harness
You might be surprised. Runtimes can be easier to test than UI for AI, and the bun rewrite was almost line-for-line translation, whereas CC likely uses many more libraries that cannot be ported directly.
The major open harnesses are in the ~800k lines of code size ( https://simonwillison.net/2026/Jul/15/grok-build/ ) and CC is the oldest and quite-likely largest judging by features.
It's really not about a PL runtime vs. an agent harness, it's about how spaghetti and complex the code is. I do get your point though.
>Reminder that the Bun's Zig-to-Rust rewrite took 11 days with dozens of agents working 24/7 and the author put the cost they'd pay (if they had to pay) at about $168k.
For an entity like Anthropic that's not even the cost of a single developer for a year. It's closer to what they pay a chef on premises.
That the showstopper for a better Claude agent is that they'd need to pay $168k or event $1M or even $10M in costs, can't be used as an excuse.
Lets see what happens in the future. From my experience cost of maintaining this amount of shitty code explodes pretty quickly. We will see in a few years if SW development in all phases using agents is that much automated and easy as people now predict.
Do you know their entire roadmap? If not, maybe different people prioritize things differently when they see their full strategic position.
How is that relevant to my response?
The argument I responded to argued that cost might be the prohibiting factor. I'm saying that for them, the costs mentioned are negligible.
I didn't claim that the cost is the prohibiting factor at all. Obviously they gave Jarred free Fable access and to do as his pleases. The cost was an FYI tidbit and nothing more.
What I argued was that you seemed to have been arguing an extreme point i.e. LLMs can one-shot stuff in any PL and that it does not matter in what PL they'd rewrite Bun.
If I misunderstood -- my apologies.
Well, I never said anything about one-shotting it.
What I said is, those AI companies push LLMs as the replacement of programmers, that can do everything code-wise, say their programmers "don't write code anymore" etc.
So how come they can't have the LLM write something better than "react for cli" for their flagship agent product?
My only half-decent guess: they deem it too big and risky and believe they'll lose revenue while working on it and ironing out remaining kinks.
Claude Code is likely not well-specified and it's a product of rapid iteration and now nobody really knows how the whole thing works. LLMs don't do well when requirements are muddy.
I don't work for them and I don't know their priorities. I can only speculate they're not okay with it but no idea why exactly.
It has to have been purely a marketing move. There's no other way that acquiring a software product for millions and then completely rewriting it makes any sense.
Maybe it's one of the cases when techies call the shots?
I can understand people being more sold on Rust compared to Zig -- there are legitimate differences on the memory safety front and I can see how people will prefer one or the other.
Plus I believe Jarred (Bun's main dev) went out of his way to explain why he chose Rust over Zig in his blog post.
Of course the marketing angle might indeed be the explanation; not arguing against that, I simply followed with interest and Jarred seemed very reasonable to me.
The rewrite makes sense, it's all their dog food at that point. It's the acquisition that doesn't make sense. Why didn't Anthropic just rewrite it themselves?
Good question. I'd guess they didn't want community split?
"Why didn't Anthropic just rewrite it themselves?"
they rewrite themselves, Bun team is under Antrophic umbrella
> Reminder that the Bun's Zig-to-Rust rewrite took 11 days with dozens of agents working 24/7 and the author put the cost they'd pay (if they had to pay) at about $168k.
Does anybody really believe that it only took 11 days, one engineer and $168k in tokens?
It played out in public on the GitHub repository, so yes.
I know what Fable did for just 5x6h sessions, singular agent, for my professional work.
Jarred used many agents and they worked 24/7. It tracks for me.
So yes, I do believe it. What makes you skeptical?
100% believe it. I use multi agent orchestration within oh-my-pi and it can absolutely do targeted things like this.
> by making it cheap and fast to build whatever you like automatically.
Cheaper, but not free (if you don't buy into the marketing promises too much). The bigger the project, the bigger the cost, even with a discount.
At the same time, the early versions weren't very good and you can be sure that any rewrite will also need to be similarly iterated upon until it is also good enough and polished.
If you do that and don't spend enough effort on making it be something polished --> your competitors have a better product and you lose.
If you pause feature development to give enough effort to the initiative, you don't get to add new features quickly enough --> your competitors have a better product and you lose.
Maybe their priorities lay elsewhere, like how I've noticed that the desktop app version of Claude Code has gotten both faster (no 2-4 second lag when switching conversations), more stable and usable over time, to where I enjoy using the models because of it, not in spite of it (though not that they haven't had bumps along the way, like that one cache invalidation issue, or how people didn't like the auto accept timeout thing). I don't doubt that you can get pretty far with gradual patches and improvements, instead of only big rewrites.
Honestly it's really cool for me to see Kimi having their own CLI too, same with OpenCode, Pi, Hermes (well more of an agent than just a coding harness but you get the idea) - there's so many competing solutions out there, each good or bad in unique ways.
Just wish we'd see similarly many GUI solutions, for now OpenCode GUI seems like the one I've settled on (cross platform and supports most models), though it's not exactly ideal either (feels a bit barebones, especially in regards to sub-tasks and progress/plan tracking, even ZCode seems a bit better in that regard, it was actually surprisingly good after they pushed out some updates).
Can't have been that cheap if they thought buying Bun for an undisclosed amount of money was cheaper.
I don't think they bought them just for the claude-code gui harness as it is now. it's to have strategic control over some software runtime they can use to do other things related to verification, deployment, and end to end value delivery. Same reason other companies are buying up dev tools.
Yeah it was a little tongue-in-cheek--I think the estimate I saw was over $100M for bun, which would have been enough to pay Donald Knuth to rewrite Claude Code, let alone AI.
How much extra money do you think they would make if Claude Code wasn’t JavaScript?
Right now? Zero.
In 2 years? A well-engineered TUI could be the difference between the Blackberry and the iPhone for all we know.
Perhaps over those two years they'll reach the same conclusion and change the engineering?
Perhaps by then it can be too little, too late, too?
Perhaps.
Claude is better at Javascript than those other languages though so maybe it would be worse in a better language.
>making it cheap and fast to build whatever you like automatically
This can be true, while "nullifies such "business" concerns" can be false. Both are not dependent on each other.
Automation doesn't "nullify business concerns", it just changes them.
By the same argument, why does it matter from the technology stack side? It doesn't just nullify the business concerns - it largely nullifies the tech stack concerns. Your preference doesn't matter if you aren't touching the code and the product works for your user base.
> But the whole point of their product is that it supposedly nullifies such "business" concerns around the use of technology, by making it cheap and fast to build whatever you like automatically.
Eventually? I am sure they would agree. Currently it's you (and lots of people like you) who are doing the supposing, not Anthropic.
They succeeded in spite of their tech choices. Their model outshone it, which is an extremely rare thing to happen and not something they could've counted on. In any other timeline they could've/would've been hurt by their choices.
It's like "why did you go all in on buying scamcoin 3.0 as your investment strategy?" -- "I 5xed my money! End of story! It was fine!"
> They succeeded in spite of their tech choices.
Or those choices just don't matter, it's fundamentally just "tabs vs spaces".
As much as an enthusiast dev like myself hates it -- this is innately true, way too often.
I am 46 y/o and still excited to code and solve problems with code and I still have trouble to admit to myself sometimes that people make dozens of millions with PHP and the tech hardly matters when you can throw bodies at the problem (and when that throwing of bodies at the problem actually solves it, of course).
> I still have trouble to admit to myself sometimes that people make dozens of millions with PHP
Or many billions. eg. Facebook was originally written in PHP.
As a 52 y/o who cares deeply about software development as an art I don't have trouble admitting that the tech hardly matters relative to the economics, that was obvious to me very early in my career.
I have just never really cared because there has always been a path where you can have a decent career being paid to work on and with good technology in spite of the fact that the technology wasn't important to the economics.
I do fear that the rapid adoption of LLMs will probably cause the path I took to narrow considerably. There will likely be less companies willing to pay people to work on elegant technology when they are all competing against endless code generation machines (and this is assuming software companies can exist at all in this future). But at my age that's more of a concern for younger people than me.
I hear you on the worry, I have the same (and probably so do most devs even).
But IMO the endless churning of code will slow down, if it has not already. Quantity does not equal quality as we know, it even erodes it. There are already consulting companies that are "vibe-code fixers".
I am also not sure it's about "elegant" code. What we might call elegant has multiple measurable axii f.ex. well-isolated effectful code layer so you can easily static-code-check it, domains and enforcement of boundaries between them, bespoke linting to enforce business processes and standing code discipline, and many others.
Apply this reasoning to any other industry. Yes the average person is not the judge of the quality of a doctor or engineer. That doesn’t invalidate it. You want a doctor who cares about medicine , not whatever will accomplish a business goal.
The choices were clearly (far) less important than having the best model and a good product that was way ahead of the competition.
However, that's not the same as the technology choices not mattering at all. As others have mentioned the product is buggy, and it appears Anthropic are struggling to continue to release new features within the existing architecture.
That's also not to say that Anthropic made bad choices - there's always going to be a tension between building quickly to capture the market now vs moving slower and building something more maintainable in the long-term.
Eh, the rendering of Claude Code is genuinely such a mess. I have quit claude code over it because when used as a terminal in PHPStorm it sometimes gets so bad that it becomes hard to use.
This isn't a minor nitpick, it's a pretty major UX issue.
Not saying it's like a massive business downside because I'm just one of a few users, maybe this affects their bottom line a little bit, but probably not by much.
Regardless, switching to pi has been a nice breath of fresh air. It just renders well and smoothly and handles terminal resizes well, which is especially important when used in a terminal window in PHPStorm.
> when used as a terminal in PHPStorm
Truthfully, the terminal in Jetbrains IDEs just isn't that great. It's gotten a lot better with their rewrites (yes, plural) of the last years, especially on Windows, but it can still be pretty dodgy.
That may be so but Claude code certainly has rendering glitches in other terminals too.
You don’t have to use these “tools”.
If they don't matter why isn't GTA6 being built in React?
Tabs vs spaces makes no tradeoffs. Tech choices do
A TUI outputting nothing but text shouldn't consume 70 GB RAM and yet there they were just half a year ago: https://x.com/jarredsumner/status/2026497606575398987
They couldn't even fix flickering in their TUI and their new renderer is complete garbage.
They succeeded despite their tech.
>> They succeeded in spite of their tech choices.
It is rarely the case that technology choice is the make-or-break when it comes to whether a product is successful and achieves widespread adoption. Some choices are less ideal than others, but at the end of the day if you manage to make something that people want, the rest won't matter much.
What do you mean in spite of their tech choices? When have the tech choices ever been an issue in the lifespan of Claude Code? From where I sit, it seems like their tech choices enabled them to create an industry-defining product.
for about half a year claude code had this obnoxious flicker problem. i almost quit and went to codex over it.
I mean people are using Claude Code because of their underlying LLM - they'll put up with Claude Code. There's no other real option to get Opus at a reasonably affordable price without CC.
Most people would choose to swim a lap through a pool of pee to get a billion dollars at the end. The pool of pee itself wasn't the once in a lifetime opportunity (for most).
Sorry, I'm bad at analogies.
I may not be the standard case, but I use Claude Code over Codex, OpenCode, Amp, etc primarily because of the UX, not the models or pricing.
> When have the tech choices ever been an issue in the lifespan of Claude Code?
This is just blatantly ignoring all of the glaring issues Claude Code has had over its lifespan.
I think the point is that people still continued to use it above everything else regardless.
Because there's no legal way to use Claude Code on subscription otherwise
Exactly. Their tech choices were not an issue because other things mattered more to users.
Yes. "People don't use alternatives not because they literally aren't allowed to, but because other things matter more"
I have been working all day every day in Claude. I loathe their bug-ridden UI. Every release is a new crop of bugs, sometimes the old ones get fixed, usually not.
Any kind of scrolling back, copying text, using their menu system - basically anything that isn’t typing characters has had/still has unaddressed bugs.
OpenAI shipped a competitive model and I’m over in Codex now. I have yet to hit a bug.
If you’re holding the SOTA crown, people will put up with your buggy mess. As soon as that crown slips your pile of trash becomes a huge liability.
> basically anything that isn’t typing characters has had/still has unaddressed bugs.
Oh, that's buggy too. I just tried Claude Code on win10 powershell, and the first typed character goes in the wrong spot and can't be backspaced.
It is by far the the least reliable program on my machine, and every time I have to interact with it I feel like walking in eggshells.
> I loathe their bug-ridden UI.
So weird that the same exact people telling you that programming careers are now obsolete are the same group who haven't been able to fix screen flickering bugs for like a year...
Oh, and the memory use! I run a lot of concurrent sessions. 3 gigs for a terminal window is ludicrous.
The vim mode in that text box was a mess for sure
The criticism didn't appear to me to be that the solution didn't work, just that many of the working solutions we are selecting are dangerously overcomplicated due to shortsighted decisionmaking. The benefits of throwing redundant stacks of abstraction atop each other in terms of time to market are questionable, and obviously absent in every other metric.
So, you have a vibe-coded TUI which happens to work, and then, as a workaround you vibe-translate its engine to make it more performant. Where does that leave you ? Basically, fully dependent on AI to fix whatever breaks. Workaround on a workaround is the way I see it, and it aligns with the AI design mentality in general. For a variety of usecases, this might still be a win in terms of overall cost. But, for software that is intended to be built to last, I dont see this approach working out.
That does seem to be the way many use it. I'd be very surprised if they didn't have to insert a rule to prevent opus from constantly asking why they didn't just use ncurses. I just asked sonnet for design options for a tui to onteract with llms to perform sw dev tasks. After describing the tui it immediately suggested ratatui and crossterm as the tech stack. I feel like they must have ignored even the advice of their own llm to come up with this solution.
Edit, the sonnet question shouldn't be taken as proof, it knows I'm a rust dev.
They decided on the tech stack for Claude Code over a year and a half ago.
ratatui was still an excellent choice over a year and a half ago.
Nobody but a JS dev would choose react-on-terminal shenanigans over it
I could see CC getting a ratatui port eventually actually
Bun was not ported to Rust for performance reasons and its not clear to me how anyone can think it was. The reason they've given is memory safety.
It was ported for vibe reasons.
Plus 1) There's much more reusable open source code written in Rust than in Zig 2) There are more Rust developers than Zig developers.
I don't think there being more rust developers should matter if we're talking about a company that solved coding.
I'm going to guess Anthropic are OK with "fully dependent on AI to fix whatever breaks".
> for sw that is intended to be built to last, I dont see this working out.
the era in which the tech industry built software to last was over long before LLMs, especially VC-backed startups.
Did it really exist? I remember buying games on discs as a kid that had bugs in them that prevented you from actually finishing the game at all.
I'm pretty sure "built to last" was only ever more true in specific contexts, and wasn't particularly more true than today.
The era in which the [VC-backed, SV area] tech industry built software to last was over long before LLMs.
Correct
And the question of “if AI is so amazing, shouldn’t it enable easy development of a native TUI even if JS is easier at first?”
Don’t get me wrong I find great value in coding agents daily. Just finding the hype cycle tiring.
This reply makes no sense in this context, though. Sure, it exploded in popularity based on whatever random tech choices were made. But now, when apparently they're deciding there's a problem there, why unleash $150k of tokens to rewrite a JS runtime wrapper from Zig to a million lines of rust, rather than simply rewrite Claude Code itself to rust?
They probably should rewrite it in Rust, but also, I think the Bun guy wanted to rewrite it in Rust because he thinks Rust is a better choice for Bun, independent of Bun being used by Claude Code.
This speaks for the benefits of JavaScript runtimes like Bun and Node.js. JavaScript is a dynamically typed language which makes it a good choice for explorative programming. It is a Lisp in sheeps' clothing.
Programs which need more stability and performance than exploration are better done in statically typed languages like Rust. Therefore Bun is a platform for JavaScript programming, but itself is written in Zig or Rust.
Massive business success? I don't know the financials since they're not published, but google says the acquisition cost low hundreds of millions. So they could throw away the code and rewrite it.
This is the “eating yogurt with a hammer” argument. Yes, of course you can do that. Yes, the yogurt gets eaten. It’s just… you see someone eating yogurt with a hammer and it’s hard not to wonder wtf is going on.
Claude code still can’t handle scrolling history without corruption. It is embarrassingly broken.
> It largely works and it's a massive business success.
The engineer is suggesting that it could be done cheaper and maybe with better outcome. Ironically, this is a classic business case.
...while proving their technology has finally reduced these questions down to what's best, instead of "how much effort will it take to be good enough".
If you have unlimited access to the magical development tool, then why would you not?
But they haven't.
> “It largely works”
A ringing endorsement!
This is a confusing comment because it’s the exact argument you would present against rewriting Bun to Zig, but you are arguing for one and against the other.
> It largely works and it's a massive business success.
You can make anything work when you have enough money to buy and radically change the entire runtime you’re relying on.
One must suspect that if they did not have insane amounts of money to burn, they could have tried other approaches to fixing the problems. Maybe engineering, perhaps.
As an industry we are responsible for making our part good. So yes a business can succeed in spite of bad tech choices, but that doesn’t make it good tech.
Any choice would have made obscene money in this market. It doesn’t make it a good choice.
It doesn’t work, it performs horribly and is full of bugs. Serious people use open harnesses.
For a company that solved coding and doesn't need any software engineers… why spend money to acquire a runtime rather than ask claude to rewrite it in assembly directly and be done with it?
Could it be that they aren't being entirely honest?
> It largely works and it's a massive business success.
I'd argue these tech companies got popular because they have good models, nothing else.
Even OpenAI took two years to fix basic chat scrolling.
This is far less so in this case because this is thier hot path. Everything runs through it and tens of billions in revenue depends on it. It needs to be as fast and solid as possible
This is a useless post-hoc rationalization. "It worked out, so it doesn't matter". You're trying to galaxy brain yourself into ignoring the obvious conclusion.
The point is that if you were starting a new TUI LLM harness today, you would basically use CC's architectural decisions as a guide for what not to do.
So Claude isn't great for everything?!?
No, it's because they wanted a unified pipeline in claude code, claude app, and their website. All of them use more or less the same claude features (claude code has artifacts, claude website has "Ask User a Question" tool, etc.).
Much less fragmented compared to "write the app 3 times in 3 different languages".
I think it makes sense that when you've outlawed competition for many/most users of your product's matching service that you would cheap out on it if you were maximally extractive and took no pride in your work, sure.
But the "coding is mostly solved" narrative kinda doesn't match right? If good, correct, high-performance software is like, free now? Wouldn't you want it to be slick as hell, really reliable, all that? Even a little breakage costs a lot of money at that scale and pricing, it would be better than a wash if you put the magic code thing on the case.
"Claude. Do all employee work. Make no mistake. Notify in slack when revenue is double."
I never knew that running an interactive program in my terminal would absolutely rinse my CPU and battery but that's what Claude, OpenCode and Ghostty have colluded to achieve. Even when the laptop is asleep overnight it's practically melting.
I'm sure there was some logical reason for shoehorning web technology into this stack given that we have a good 40 years or so of experience with interactive terminal programs that use curses/ncurses, alongside emacs, vim, almost the entirety of MS-DOS, and so on.
The fundamental problem with all Js based apps is how they are very single threaded.
With js you get 1 thread at 100% utilization. Power usage and heat scale non-linearly with cpu utilization and 100% utilization on a single threaded js app means you will have ui lag. Other languages like golang would split work across 8 threads and have 8 threads at 20% utilization and this would result in less power usage. Claude Code would have been better off performance wise being an electron app because it would be offloading rendering to the browser and gpu.
Also, the architecture of Open Code is actually a lot better here than Claude Code. ClaudeCode does everything, including rendering in a single thread and it's all in js. OpenCode has a zig based tui renderer it offloads that work onto.
But I will also say these coding agent tuis do get unfairly maligned because they launch subprocesses and those subprocesses tend to be expensive. If you are using Rust analyzer with claude code, it's rust analyzer that's causing the majority of your problems.
No, the fundamental problem of these apps is that they are, for no reason, pretending they need a high powered game engine rendering loop. They don't. It's a text printout of history with some hotkeys for mode switches and such. "rendering in a single thread" should never be an issue because it should never be "rendering". It needs to stream text to stdout. That's been a solved problem for 50 years and now it takes 2GB of memory to be done poorly with broken scrollback.
Drawing to the terminal / rendering / whatever, this is all arguing semantics and very uninteresting and not insightful.
> they need a high powered game engine rendering loop
Don't believe the bs on twitter. Claude code source was leaked, there is no high powered game engine rendering loop.
> It needs to stream text to stdout
These apps are doing real work taking text that is streaming in and doing syntax highlighting, calculating diffs, and rendering markdown. If the work was split across threads they would not use anywhere close to as much power and there would not be a slow ui.
If you think this is actually nothing, prove it. Put the code up on github that shows taking a constant random stream of markdown, code, and diffs and displays it in the terminal can be done cheaply on a single thread.
The reason the computer gets hot and uses more power is because the cpu is getting close to 100% utilization.
There are two different arguments here.
> These apps are doing real work taking text that is streaming in and doing syntax highlighting, calculating diffs, and rendering markdown.
The first argument is that these are expensive operations. They are not. And the second argument is the assumption that these are desirable things for an agent system to be doing. That's a personal preference but, personally, I don't want them and would appreciate a way to disable all of that to reduce CPU use.
The argument is that doing it all on a single thread will result in high cpu utilization and that is what makes the power usage spike and the pc feel hot. Thats it.
A lot of people go “js is bad” reflexively and they are right for the wrong reasons. Its not because js (specifically v8) is slow. I have many websites and web based apps open and none fuck up my laptop as hard as claude code.
Yeah I don't get it we had terminals on single core machines. In early 2000s I am sure they could handle the UI of Claude (probably IO too).
Early 2000s tech could absolutely handle LLM agents as a client. They output like 1-2kbps and even dial up modems would have plenty of capacity for other traffic.
The UI itself requires laughably simple tech. The idea that a markdown renderer that can produce HTML at 50MB/s would use much CPU to process incoming hundreds of bytes per second is insane. CPU should be idle even if doing that constantly. Nevermind that between turns it has nothing to do whatsoever and should use zero CPU at all.
Stuff doable on a pentium 90, and before that, just slowly.
I wonder if those were fast enough nostalgia says yes but I bet it was dog slow if we tried today with 2026 lens.
My Turbo Pascal programs could calculate and print to the screen faster than could be read, on a 486. With DOS however.
I picked the P90 because I remember running Linux ~1.0 and/or NT on it, with real multitasking and services etc. Those soaked up many of the cycles.
Another story, around Y2k/Win2k was asked to write a C program to record all the files/sizes on the C: in to file. Then something would be installed, my program run again, and the results diffed. Despite thousands of files the program was done before the enter key came back up. Boss told me that he thought the program was cheating.
That’s just how fast modern computers are these days, I said. When running C code anyway. That perf is still available today, compare astral’s uv to slow competitors. Just takes some investment, though probably less when boosted by VC bionics.
"The most amazing achievement of the computer software industry is its continuing cancellation of the steady and staggering gains made by the computer hardware industry."
— Henry Petroski
I don't think any of that seriously counts as real work.
Casey Muratori addressed this years ago with the windows terminal drama, https://github.com/cmuratori/refterm
The heck? It does all that rendering for a tiny fraction of the total amount of time that the TUI is running. The streaming is IO bound, there’s no way that it’s outputting nearly enough text to tax the CPU that much.
Sorry, but nope; Golang there would be there a beast doing that in a much, much faster way. Not to mention C/C++ with NCurses.
> If you think this is actually nothing, prove it. Put the code up on github that shows taking a constant random stream of markdown, code, and diffs and displays it in the terminal can be done cheaply on a single thread.
Put up the code and prove it. We already know exactly how fast golang is in comparison to nodejs on basic numeric computations, it's roughly 40 to 50% faster.
https://pierre.computer/writing/on-rendering-diffs
> Power usage and heat scale non-linearly with cpu utilization
I don't doubt this, but I would love details and citations here.
I'm not concerned with CPU use/wakeups while actively using it, but with it sitting idle doing nothing.
That’s not really a big issue. In major OS like the BSD, SMP implementation are not that old. If we can have a full OS running in single core mode, we can have an application being performant too. I’m currently running OpenBSD on 4 cores and it’s basically 99% idle.
Bad coding is just bad coding.
It's basically idle because it's not doing anything. If you are streaming in markdown and code and then doing syntax highlighting on this code in real time, then rendering it on the screen you are doing actual work.
It's also all cpu bound work. The majority of the stuff on your screen is being rendered by the gpu.
> If you are streaming in markdown and code and then doing syntax highlighting on this code in real time, then rendering it on the screen you are doing actual work.
You are really, really not. Not at LLM inference speeds at least. Frontier models output maybe 200 bytes per second on the fast end. I guarantee you that idle BSD box is still processing more than 200 bytes of whatever at any point in time. Streaming 200 bytes of LLM output through syntax highlighting, markdown rendering, and diff formatting, will still leave the box basically idle if done correctly. Claude Code has not done it correctly.
Processors today are very fast. If you are spiking it on rendering diffs, you’re doing it wrong. I can’t even stress it building openbsd’s kernel.
Why are you implicating ghostty? Have you compared its CPU usage to any other terminal?
Of course I have. If I see ghostty constantly consuming the most energy and helping reduce my battery life to barely 2 or 3 hours, the first thing I'm going to do is switch terminal to see if I can improve that situation. The built in terminal and WezTerm have been fine and I've had much more reasonable battery life since.
This does not even speak to it pegging my CPU and keeping the fans running on full blast even when the laptop is supposed to be idle overnight.
This seems a suspicious. How do you measure the CPU load of Ghostty? Is the measure/reporting method just attributing the cpu load of the commands/programs you're running in Ghostty to Ghostty?
You could test this by running "yes > /dev/null" in Ghostty. In Activity Monitor on my Macbook it shows `yes` using 100% and Ghostty using 0.5% of cpu.
If you're looking for a non-ghostty recommendation (not that I have anything against ghostty) I use alacritty + zellij and it works fantastic. It doesn't seem to impact battery, I certainly get good battery usage on both my work and home laptops.
I've messed around with pretty much all the fancy new terms to varying extents. Ghostty, wezterm, alacritty, etc. And I'm all in favour of people innovating in this space again. But at the end of the day, I always end up back with xterm. It's reasonably lightweight, runs and is packaged absolutely everywhere, I never have to muck about with termcap files and/or $TERM on remote hosts, and I've never had it break, crash, or exhibit any kind of bug or strange behaviour in over a decade of using it. The only TUI that has some quirks in xterm is Emacs, but Emacs has weird quirks in every term I've tried to run it in, and different quirks in every case somehow, so I just chalk that up to Emacs being weird. I'm sure xterm has some bugs buried in it still, but I bet all of them are in codepaths that are almost never reached nowadays, or at least are extremely niche. It does lack some features like ligature fonts(I just decided not to care), sixels and similar graphics things(again, don't really care) and panes/tabs/yadda yadda(tmux or screen or whatever you like can do all of that anyway).
Never had to dig through the xterm bug tracker to figure something out. I don't even know what version I'm running, or even what the versioning scheme looks like. I haven't changed the configuration since the first time I set it up. It just works.
Same. I really want to file a proper bug report for this but I haven't been able to really dig into the details and the last thing I want is a "ghostty is a cpu hog" kind of report without useful info on how to debug that.
I don't know if its still the case anymore since 1.3 but Ghostty did have a documented issue with Claude causing resource issues.
I think the author is saying everything that touches llm.
> Even when the laptop is asleep overnight it's practically melting.
Then something is waking it up and it's not asleep at all. Asleep the CPU shouldn't be running.
yep, developers from 10 or even 5 years ago would have considered it a hilarious joke
Its so wasteful, but that tracks with the modus operandi of AI companies.
Codex CLI and Grok Build are both in Rust. OpenAI’s web still use react. Previously their CLI was React Ink until they ported most of it to Rust
It is kind of mind boggling. They could have chosen anything and decided to implement it in the slowest jankiest way possible.
Proves LLMs don’t help with taste.
> why the hell does a TUI need to run in terminal React by way of JavaScript
Because React is the only UI framework that takes the problem seriously. Everything else is stuck in the dark ages.
How HN gets this so badly backwards I'll never understand. Everyone on this site talks a big game about "there shouldn't be so many competing tech stacks, why can't everyone work together on one framework that does things right", and then as soon as that framework actually appears this site hates it more than anything.
I recently saw a blog post [1] about a famous Haskel shop moving away from Haskell to Python because the iteration speed with LLMs was just that much better. There is so much React in training data, TS compile times are minimal compared to Rust and similar.
I suspect user facing/fast moving code (UX layer) will move to dynamic systems with fast iteration times. Infra layer will move towards safe systems level environments like Rust. I'm not sure where Java/C# lands in all of this - it's kind of the middle ground between these two worlds but the tradeoffs change drastically with LLMs - my gut feeling says that TS/Python is good enough for UX work and Rust is better for systems work so it gets less popular going forward.
[1] https://avi.press/posts/2026-07-10-after-7-years-in-producti...
That blog post doesn’t make sense to me at all. The author is going from full modern Haskell (since he mentioned Servant and Beam, you could tell almost every file uses dozens of GHC extensions beyond what Haskell2010 gives you) to Python with dynamic types. He could instead rewrite the Haskell to use less modern type system features and get so much faster compilation speed.
Also GHC has an interpreter. It powers the REPL. No need to compile everything if you’re just experimenting. I do find that in the Haskell world the REPL is criminally underused compared to Python.
And the rest of your comment doesn’t make sense; this shop is rewriting their infra (not UI) from Haskell to Python.
Python was faster to iterate on than Haskell even before LLMs
Why would rewriting Claude code, an app which probably has 30-40 (I might be significantly underestimating) extremely active contributors be easier than rewriting Bun, which has fewer contributors and almost certainly also less lines of code?
Because I’ve been told that Fable can do anything :-)
My question is moreso “why was it ever JS in the first place”
& the cost of a native rewrite would be cheaper than acquiring Bun no matter how you shake it
Probably because it consumes the same APIs originally developed for a web app and the same front end engineers likely created Claude Code. People assume Anthropic set out to create Code as a product and went through a normal design phase. I think it’s more likely it started as an internal tool or someone’s side project and blew up as a product when they released it to the public.
But isn't the point of an API that it abstracts away the language(s) in which your application is written?
>Because I’ve been told that Fable can do anything
I hear some version of this anecdote constantly
yet despite using all these prompting tools since 2019 I have never once heard a lab or professional say “x model can do anything”
Can you provide me whatever specific source you heard for this?
>I have never once heard a lab or professional say “x model can do anything”
Yeah, they "merely" say that they're about to break the singularity in a couple of years, that it's too capable to be safe to release, that it's going to take 50% (or all, depening on the day and audience) of programmers out of work, that it's smarter than Nobel prize winners, that their programmers don't write anything themselves anymore, and things to that effect.
Who is “they?”
Again… provide me a quote from someone doing this every day that says: “they're about to break the singularity in a couple of years”
The only people saying this stuff are random Internet commenters, breathless reporters and reactionaries.
The only person on record for a statement like this was Geoff Hinton about radiologists and he has since walked back his statement
It’s hyperbolic and intended to generalize the sentiment I perceive from others.
Dario Amodei said in January that he expected software engineers to be replaced [0], so I suppose the quote should be extended to “can do anything… a software engineer can do”
And I think we can all agree that SWE is on the more complex end of all white collar jobs. So, my thinking is that if SWE can hypothetically be replaced, so can many other jobs. Hence, the claim the models can “do anything” intending to capture the majority of white collar work.
This, of course, is if you take their claim at face value - which I certainly do not.
[0] https://www.entrepreneur.com/business-news/ai-ceo-says-softw...
Code is the killer app for LLMs so software developers are the easiest to replace.
Code isn’t what the majority of software engineering is.
Pointless nitpicking that completely missed my point. Software developers are not the hardest to replace, so your presumption that everything else should be easier is wrong.
Next time, try being polite, it’ll make me way more inclined to engage with you.
If I missed your point it was unintentional. Instead of being rude, try gentle clarification.
But now I’ve lost interest. Have a good day!
So then nobody actually has ever said that and its explicitly hyperbole
So then its misleading in the extreme to say “I’ve been told AI can do anything”
It amplifies hype when people make claims like this by including hyperbolic statements as though they are reflective of the state of the discussion.
Alright, sure, my bad. I thought it was clear that it was meant tongue in cheek, but I’ll accept it was unclear.
That said, with respect what I clarified, I’m curious your thoughts.
I'm doubtful that it has fewer lines of code, but even so, it is almost certainly less tricky and simpler code. You could also rewrite it in a higher level and more forgiving language than Rust (e.g. Go) and get huge improvements. The improvements would probably be much bigger than the improvements they have achieved at the JavaScript runtime level.
I don't think people are saying it's easier, they're saying the results would be better.
this. /s
Yknow, I really didn't mind Claude Code that badly, but subjectively speaking I really do like Codex more after using it for a couple weeks. Feels a bit snappier and lighter weight. I know with OpenAI you can actually use third party tools with the subscription so there's less of a draw to using Codex, but I still find myself preferring it now.
Is this because Codex is written in Rust and not JS? I dunno. I think it's more just "lighter" in general, or it certainly feels that way. It's probably possible to make something with a similar feel in JS, just perhaps not with the big honking mess they've created.
Codex appears to be a mildly complex, somewhat-but-not-outrageously-sloppy Rust program (yes, I’ve poked around at its source — thank you OpenAI for making it more or less open source). It has lots of features, mostly related all the fancy web features of Codex.
Claude Code seems to be an insanely complex program will all manner of cutesy features and telemetry features. The net result is approximately the same as Codex, but it’s pretty common in software engineering to find a simple thing and a complex thing that do more or less the same thing.
>If rewrites are so easy, why not rewrite CC in a native language? Would’ve been a hell of a lot cheaper.
Yeah, good question. OpenAI decided to rewrite Codex in Rust about a year ago[0].
In fact, since rewrites are that easy, what do we need Bun for? Why doesn't everybody just port all of their Javascript code into Rust?
[0] https://github.com/openai/codex/discussions/1174
Code verbosity and complexity still matter with LLM coding
Yeah, they do, but probably not in quite the same way as it matters to humans.
As a counter argument - I assume that Anthropic is using AI to write Claude Code.
I've read and heard in videos that Javascript is a pretty good language for AI to write code in. Apparently this is because there is so much training data out there. Also Javascript avoids problems of multi threading and memory management that can mess up the AI in other "more performant" languages.
So maybe Javascript is not the worst choice for writing software fast with AI
I feel like a year ago JavaScript and Python were the best languages for coding agents to use because of their heavier presence in the training data, but I'm not sure that's true any more now.
The latest frontier models are competent at Rust and Swift and all manner of other less widely used languages.
The more important factor is how good they language's compiler is at kicking out actionable error messages, since one-shot code generation isn't as important once you have a coding agent loop.
Sometimes I think that if we are willing to burn tokens and rely on compilers in a loop we should be using languages that can catch as many errors as possible at compile time.
Like Ada or Ocaml or Haskell or something.
Or even require like MC / DC testing or MISRA C verification.
Or even some of the languages that apply Hoare checks, like Ada SPARK or FRAMA-C or VALE or whatever.
I don't have the budget to test how that would work but it seems interesting.
I presume haskell applications similar to claude code are well represented in the training data.
There was a post recently from a guy who used Haskell with AI agents. If I remember correctly he said the type checking did catch errors. The problem was the compiler was very slow, which slowed down the feedback loop and output. I think he switched to Python.
> If rewrites are so easy, why not rewrite CC in a native language? Would’ve been a hell of a lot cheaper.
It was unpleasantly surprised when I learned the hard way that LLMs are not much better at translating than writing from scratch.
The more you look into how they work, the more you see that it doesn't really give them a huge advantage, if the classes are big enough. You can tell them to break each function up and translate them one-by-one, but the errors compound, you can't test most of it until you have a lot done, and in the end, it really isn't much faster (and sometimes it seems to be a lot slower) then just telling them to start over from scratch.
The downside is... If you have a system that already works, you don't want to start from scratch and test everything all over again...
I asked this in a thread with a CC author a few months ago (I felt — and hope — very politely, with similar background.) No reply. https://news.ycombinator.com/item?id=46716974
At a guess it's because Boris literally wrote a book on TypeScript: https://www.oreilly.com/library/view/programming-typescript/...
I don’t doubt his expertise, I just am not convinced it’s the right tool.
To me it comes back to the premise I hear a lot from AI hype men (of which I do not subscribe but it’s worth clarifying that I find great value in using it for code) that the code doesn’t matter anymore. I just don’t know how to square that claim with the idea that we’re limited still by JS/TS being easier to use or approachable despite inferior TUI toolsets.
I think Moore's Law and related have made programming sloppy. AI is building on that. There was a time where accounting for memory, footprint, stability, and speed mattered. Your point shows we are well passed that aside from certain areas.
Heck, a buddy and I once chatted about the likelihood of k8s running as the control plane in a prototype autonomous vehicle.
top/btop/htop on the mac are always fun to run and see what's up.
I'm confused as well, could someone who knows how TUIs work explain what's the point of React-style diffing in this context? I thought you need to clean and full redraw if anything changs anyways?
> I thought you need to clean and full redraw if anything changs anyways?
Unless you use an ancient teletype, you don't have to redraw everything. That would make any interactive applications way too slow/flickery.
You can move the cursor arbitrarily in the terminal and start overwriting characters from there. So you need to track state to know what is "dirty" and needs refreshing. Occasionally you issue a full redraw to catch missed artifacts left behind or when the terminal is resized (SIGWINCH).
You can do damage tracking for TUIs. Printing to the terminal is done by moving the cursor and redrawing the line the cursor is on.
Ncurses is how people used to do it.
Cause it works, most users are fine with it, people don't migrate off it because of the codebase, and easier to maintain if the dev team is familiar with code flow.
This is close to the same "why Spotify is a chromium embed?" question. Because it works, and users are ok with it.
JavaScript is very fast and easy for UI rendering. If it works for web apps it’d also work for the terminal. Sure it’s bloated but it’s fine. The dev velocity of JavaScripts is orders better than rust.
And the TUI fights the terminal on basic things like copy/paste. I end up telling Claude to write all outputs to a tmp file.
So the code for the web, the desktop app, and the cli where largely similar.
The component trees have to be rewritten, only the non-view related JS code can be reused.
Otherwise an idle TUI wouldn't halve my laptop's battery life. Maybe that's an exaggeration but not that much, based on looking at wakeups in powertop.
The answer is those are the tools their lead engineers knew, so they repurposed them rather than learning other paradigms .
To the man with a hammer…
This saying has been abused 10 ways til Sunday.
"I'm using technology I know that will get us there" is not the same as treating every problem as a nail. It's making a practical choice that probably also had time constraints and other factors we don't know.
I think it’s completely applicable here. Nobody who worked in the 80s or 90s would have selected this solution.
> why not rewrite CC in a native language?
It's hell to maintain for not much gain (for a use case like this at least). As much as it's become a meme, JS and web tech in general has become extremely portable and stable.
I also don't think Anthropic bought bun to make their TUI better. They could have forked it, they bought bun because it incidentally was excellent for the way agents prefer to work and they wanted to capture that audience.
I thought maintenance was free with LLMs???
I don't think it's that kind of maintenance like code.you need to test cross compiling and running on different platforms. I guess js acts like how the jvm is
I think they bought Bun because it was a supply chain risk for them.
Their new flagship product (earning them billions of dollars in revenue per month) was dependent on a platform maintained by a tiny startup.
Buying Bun was a very rational way to reduce that risk, epically since it also got them some top tier engineering talent.
Thinking about that further, I wonder if that was part of the rationale for switching from Zig to Rust that they haven't talked about?
Zig is a much riskier bet for your multi-billion dollar cash cow than Rust is.
But saying that out loud would be rude - they took steps to NOT openly criticize Zig, even after Zig's founder did not show them the same courtesy.
> But saying that out loud would be rude - they took steps to NOT openly criticize Zig, even after Zig's founder did not show them the same courtesy.
If this does not get Anthropic 'The Presidential Medal of Strategic Restraint' I don't know what will.
it is kinda mystifying bc from what i understand their engineering ethos is very much "if it's not working, just regenerate it" (which i completely understand).
Anything that can be written in JavaScript will be written in JavaScript. That's just how it is it seems.
i got annoyed by this especially the memory use and non portability aspect of bun so I had claude (lol) and kiro cook up my own agent. it runs on linux, openbsd and even on omnios and esp32. it's just a personal project so there are probably rough edges, but I am using it on my clockworkpi uconsole daily now. https://github.com/mischief/clm
I’m not sure what else can you use to share the same business logic between website frontend, desktop gui and tui apps and backend
Lots of devs know how to code in it, and the AI models have more training in JavaScript than any other language.
It's like asking "why does everything run on Windows?" Because everything runs on Windows.
> Maybe I’m taking crazy pills, but I’m still stuck on “why the hell does a TUI need to run in terminal React by way of JavaScript”
No, you are not crazy. They do crazy things with unlimited budget, and still their chat app flickers when using.
They should just port pi-tui from pi coding agent, since they have no clue.
Should have done it in C++ with SDL3.
Probably because claude suggested some kind of wack react based setup early on (because react dominates the training data) and it's be blasphemy worthy of termination for the Anthropic employees to question the sacred pronouncements of the llm.
If you think that way I would recommend just keeping away from these topics. It is just useless arguing and speculating about things don’t matter.
I have been trying to keep away in the last couple weeks and it was all win for me. I still come down here sometimes when I am stressed with real work since it is a strong addiction to see “how terrible the plebs are doing”.
JavaScript is dynamic and supports live reload which means iterations are far faster than would be in a compiled language--even for LLMs.
This is especially useful when you're trying to evaluate behaviors while changing state surgically.
If you are relying on live updates to change state in a dynamic language then you are not doing it "surgically", unless there is some other definition that means hitting it softly with a large rock.
There are several compiled languages with live reloading, including C++.
There's no surgery when you're a company with a trillion dollar hammer and every problem looks like a big ass nail.
Why all the mess with Bun?
Couldn't they have rewritten Claude Code in Rust directly? No more need for a JS runtime, better performance, etc... If their agents can do Zig to Rust, why not JS to Rust?
I know, its so confusing. Its almost as if the bun rewrite to Rust has absolutely fuck all nothing to do with Anthropic's product strategy.
Well, yeah, it's just good marketing and Bun ultimately doesn't matter anyway, not to the wider ecosystem and especially not to Anthropic. The only purpose Bun had for Anthropic was as a way of getting attention, so that's what they used it for.
In isolation, yes, that does seem like it would have been the better decision for Claude Code, but it also would have severely diminished the value of their Bun/oven.sh acquisition.
Claude Code isn't the only user of Bun (it's probably not even the only user of it internally at Anthropic), and this way they get to keep the Javascript runtime (and other tooling) that their coding models may one day, if not already, prefer to use when given the opportunity. For those kind of apps, you'll probably also eventually find that--what do you know!--Anthropic also has their own cloud offering (instead of Bun being the one to build one) that specializes in running and managing those applications for you. Even if all they get is a community of developers that choose to use Bun over other options, that gives them power and seats at tables they wouldn't have if they just rewrote Claude Code in Rust.
That'd be my best guess, anyhow.
So they had to rewrite Bun instead of Claud Code because they “already had bought Bun.”
This thread is filled with non-sequiturs.
Is Claude Code bottlenecked by performance?
I think a JS runtime is fine because the ecosystem of tools is very large and plugins are easy.
People widely report very high memory and CPU usage.
Not all of the memory usage is the fault of Bun/JS. Some of it is likely memory leaks (holding on to data it shouldn't). However, some of the blame does go to using JS. In Rust you can tightly pack your data if you want to, but in JS you can't have nested structs for example. Every object referencing another object is two separate chunks of memory, each with a header, and a pointer from one object to the other. GCs also use more memory. The overhead adds up.
Building a CLI program in JS is a bad choice, and nobody should be defending this decision. Especially since Claude Code is very much able to write Rust code, and they've shown it can port code. Just port Claude Code to Rust directly.
Why is ecosystem of tools and plugins a bottle neck when they literally own Claude models and as per their boss, code is so cheap that anything us just an English sentence away?
I knew this was going to be the first reply.
The answer is because you still need at least one human to develop and test any tool, integration, feature.
Why? Use agent bruh. Even the bun rewrite post said that agents do writing testing everything!!!
Unless AI overlords lied and we do need humans
They had a human oversee the bun rewrite, didn't they?
that's the hypocrisy I was pointing out. Lol
For their work they extensively test using humans with deep expertise
But while marketing they say just vibe code bruh
And here they can't even rewrite CC in rust? Why not! Use 1000000 agents!! Write it in platform specific binary! SAAS is dead, that's what he claimed. So what's stopping him from writing the harness in Rust or C than ReactJS?
What hypocrisy? Anthropic never said you don't need a human anymore.
I think we are not living in the same universe if you claim this. And I can't speak with someone who doesn't live in the same universe
Show me where Anthropic claims you don't need any humans anymore to build working, production ready software.
> The "General Labor Substitute": He rejects the idea that his employment forecasts are "doom marketing". Instead, he asserts that AI will act as a general substitute for human labor, noting that most software engineering could be entirely automated within 1 to 2 years
When someone says all Software engg could be automated within 1yr they don't mean 'oh use our agents and keep human in loop'
They mean 'AI superior than humans fire all humans and all SWEs will be jobless'
I am not going to reply to you going forwards as I can't speak with someone who lives in a different universe
Have you watched the video where that was said, as opposed to just reading interpretations of it from people with their own assumptions?
https://youtu.be/02YLwsCKUww?is=UsJrcLRgdSUd38Jt
Here's a transcript: https://gist.github.com/simonw/0050b4ce40439b97598d4ffdb273d...
I summarised the transcript using LLM just like our AI overlords intended.
News flash: most of software engineering is already automated. When was the last time you wrote code?
They did not claim there is no human involved.
it does seem to be very much bottlenecked by performance, yes. very slow to start up, for example.
Maybe I'm taking crazy pills, but I swore there have been very similar comments I've seen as the current top post by weakfish:
> Maybe I’m taking crazy pills, but I’m still stuck on “why the hell does a TUI need to run in terminal React by way of JavaScript”
> The fact that Anthropic felt the need to buy a runtime so they could make their TUI better speaks more to the quality of engineering than anything else IMO.
> If rewrites are so easy, why not rewrite CC in a native language? Would’ve been a hell of a lot cheaper.
It turns out, there's some similar sentiments in the last year ish:
https://news.ycombinator.com/item?id=47043325
https://news.ycombinator.com/item?id=47105720
https://news.ycombinator.com/item?id=48001113
https://news.ycombinator.com/item?id=46134570
https://news.ycombinator.com/item?id=46124596
I'm not a fan of any of the technologies, companies, or people related to this. I just couldn't shake the feeling that I've seen similar comments.
September and all.
Maybe because the 1st thing any experienced technical person would think about? It's like rebuilding and optimizing the racing track to make F1 run faster.
Perhaps. The thing I was trying to highlight more is comments (particularly disapproving ones) about the intersection of JavaScript (especially React, apparently), TUIs, and LLMs.
I just thought it was interesting. I'm a fan of TUIs, both positive and negative about JavaScript (the modern language is quite nice, given you avoid the historical warts, in my opinion - the ecosystem is unfortunate), and I think the best description for how I feel about LLMs is that I'm bearish. Also Simon is a fantastically prolific and intelligent person though, even though LLMs are not my cup of tea.
https://news.ycombinator.com/item?id=48960912 is a recent comment by someone I also respect related to how LLMs recreate human-like content (Widgets, really), making actual human-created content feel fake.
Sometimes it sure does feel like ELIZA is the main news source these days.
I have ~24 years of experience coding and the LAST thing I think about when opening claude code is "why is this written in react".
Tell you what I sometimes think about though: The fact it has clickable links and complex formatting rules for markdown, the most interactive and highest-quality clickable interface I've ever seen in a terminal, and somehow manages to work. That actually blows my mind.
THEN, I'm reminded that it's written in React, and I think "Huh, guess that does make it a ton easier than using ncurses or something."
And done.
Okay and as someone who would rather just straight up use cursor than claude code, I'd rather have my software not crash out on me every 5 minutes. What sort of self respecting dev purposely uses broken software? Even opencode (use it on nonwork computers) is fully better at this point.
Disingenuous, much? I've only ever had claude code crash once (after it decided to spawn like 12 subagents and got my laptop swapping like mad).
If you're crashing every 5 minutes, either you have a cursed build, or you need to do a memtest.
It's not disingenuous, claude code has over 5k issues that are ignore plus thousands of more that were just silent closed.
This is a product by a company worth supposedly $1trillion and they can't even make one of their starship products not shit the bad within 5 minutes? These are the same engineers telling us for the last 3 years that coding is solved?
Like it's pathetic, and it's pathetic you're falling for it too. Have some standards, good grief.
You’ve been writing code for 24 years and you don’t know that clickable links are a terminal emulator feature and not a Claude Code feature? Or that “markdown formatting” is just ansi escape codes, and possible with things other than React that don’t bring so many downsides?
Correctly emitting the right escape codes at the right positions is arguably very much a Claude Code "feature", as it is on CC to do so.
Claude Code is able to hyperlink any kind of text, not just the native terminal emulator feature of hyperlinking anything starting with https://...
And your "it's just ANSI escape codes" is the weirdest take on any kind of software.
Formatted hyperlinks are an escape code too. It has nothing to do with React.
Not sure why you’re trying to bring up experience as a justification for using React to render a tui and all the downsides that come with that.
It sounds like you completely missed the point I was making: that actually implementing such a highly dynamic TUI application normally requires a significant amount of state tracking and it is significantly easier to write such apps using a functional, descriptive UI framework instead of something like ncurses.
Take it from someone who, in those 24 years, has written UIs in jquery, react and ncurses (and yeah I've tried out Ink and it's great).
"all the downsides that come with that" yeah well, while you're stuck implementing your app in the Best Possible Library, millions of people are happy using claude code and it's crazy useful.
There are fantastic TUI frameworks for Rust, like Ratatui[0] (there are a lot more options, this is an example). You can write beautiful TUIs in native languages, without ncurses or C or C++.
Go has such frameworks, same with C# (which you can AOT compile) and so on. You're not stuck between javascript and C.
[0]: https://ratatui.rs/
Yes I also used Bubbletea. I don’t know about ratatui but honestly I think the hate for react is very blind. It’s not like CC is shipping an embedded web browser. It’s a framework on top of an embedded language that has seen a crazy amount of optimisation.
CC is not even that complex of a TUI. It’s certainly not as complex as many of the GUI programs I use daily. And yet it’s by far the buggiest and worst performing. I don’t understand the desire to make excuses for this. The reason people use it is because it’s the only way they can afford to use Opus and Fable. If Anthropic let people use their subs with other harnesses their market share would plummet.
If they could migrate an entire runtime to Rust why can’t they migrate CC? It’s not as if React is the only way to do declarative UI.
I don't want to edit this to change the narrative, but I wanted to clarify that I'm not not a fan of all of the technologies or people related to this. As far as compan{y,ies} go, though, well..
It's because rewrites are almost always a bad decision. Best case, it's a naive decision made by people who don't know better, worst case it kills the product (who here uses netscape?).
So, from the start, people will be skeptical of a "we rewrote xyz in Rust" because it rarely works out. But there's a lot more to this, in fact it's a little bit loaded with "tech bro" ideas:
- Rewriting in Rust
- Rewriting using AI
- Making terminal apps in JS
- Zig (a lot of people's dear language) is involved somehow
This attracts every single skeptical developer. The only thing missing is maybe blockchain, if that was still cool. It just hits all the "what? why?" spots.
I was already writing a comment, when I realized that what I wanted to write had already been said by the top comment. I suppose that's why comments read so similarly.
What's the implication or inference based upon this? So you're seeing comments sharing a general attitude. And?
As it is now, your post is meaningless to me.
All the emotion of speculations aside, how it runs? It boots faster yeah, but what about RAM and CPU usage? Weird dead loop or dead locks?
If it run as good as before or even better, then that's kinda impressive.
I'm a developer so I really don't like it when AI might took my job, but if everyone on this planet could create a software for themselves exactly as how they wanted with just a few simple demands, that will change the world for the better.
Think of it as a democratization of technology. You don't want Microsoft stealing your data? Just ask a AI to write an OS for you. You don't want Google to listen to what you're saying? Just ask a AI to design a phone for you. If one day the AI ended up doing that, it will be the ultimate technology self-sufficient. In front of that, your job security is insignificant.
It is also why keeping the tech open source is that much important. Otherwise, it's still the same old shit again and again, and, you lose your job too.
> I'm a developer
Then you must know that the hardest part of software development is getting clear requirements...
> everyone on this planet could create a software for themselves exactly as how they wanted
Even with perfect AGI this will never happen because people will never be able to express clear requirements
It's not even about requirements. It's about responsibility. Someone has to take responsibility for the code and the product. Someone has to hotfix a bug that's costing millions of dollars an hour and someone has to be blamed for a bug that's consting millions of dollars an hour.
Not really. The secret of our society is it wouldn't work if people with a controlling interest in things ever faced personal responsibility. Who got blamed for the Iraq war? How much did that cost? The theory is if you tried to blame someone then some future president wouldn't be able to declare war. You don't know how the law works apparently. Corporate law is pretty much the same. The economy doesn't boom if CEOs can actually be blamed for things. You don't blame a "someone" that's what incorporation does. If some code does a booboo just put a $ amount on it, withdraw the funds and move on. The media will focus on the humans because of the drama, but they are largely irrelevant. It doesn't come out of their pockets. A human is already window dressing in this status quo. A LLM has no reason to do the sorts of things that violate such legal protections, be it of a president (none really apply) or a CEO (good luck getting a CEO to take personal responsibility for anything short of outright fraud). If it suddenly goes haywire the law already has a concept of vis major.
The secret is individual humans are already largely irrelevant to our society. That's how we got here. The trend will only continue.
> Think of it as a democratization of technology
Incredibly naive take when these models are closed behind (for now subsidized) paywalls.
This "democratization" argument is so nauseating, seems like the Bun port to Rust as a marketing piece (the primary motivator) sold it well!
That's why it matters for people to hold the control of the tech, not companies, as I've already mentioned quite clearly.
LLM is here to stay, keep denying the fact won't work. What does is to make the tech so abundant, it flushes the bad actors, such as for-profit AIs, completely out. It's either this, or get crushed by for-profit AIs, pick one.
It's a "democracy", in which some people (Anthropic and co., and anyone willing to suck up to them) are more equal than others...
It definitely worked as a marketing stunt for sure
A good tool, in the hands of a skilled craftsman gets great results.
The same tool, in the hands of someone that doesn't know how to handle it? I'll let you finish that
Basically, a good developer can handle the tool better by asking the proper questions, setting good guardrails and tweaking the output where needed
Anecdotal, but I’ve been getting segfaults in Claude Code. I run inside Kitty tabs, and the entire tab becomes unusable when this happens. No response to inputs at all from that point.
When this happens, a link shows up to report the issue. It’s not clickable (likely due to the segfault), and perhaps more important: it’s encoded, so you can’t see what you would be sending in your report.
Hope it gets better.
Something similar has been happening to me with Ghostty, but there is no error message or link and it only happens when Claude uses it's interactive questions interface.
It becomes completely unresponsive to any input except scrolling. I can't select options or even cancel out.
(I am in no way implying this is related to Bun)
Same experience I have with bun in general. As an idea, it's the absolute best js runtime by a very large margin, but in terms of stability it's terrible and segfaults 20x as much as node (I base that number on newrelic telemetry)
> but in terms of stability it's terrible and segfaults 20x as much as node (I base that number on newrelic telemetry)
In Chrome or Firefox, a segfault is usually automatic CVE and in most cases a bounty of thousands of dollars…
What makes you think it's a segfault? Does your shell print "Segmentation fault"? If so, you should be back at your shell and you should be able to recover the tab by typing 'reset' + enter (even if you can't see anything as you're typing it).
If nothing prints "Segmentation fault", this just sounds like a hang
I just had this happen today. It was indeed a segfault.
From what I could tell it looked like it was in JS code that had been JIT compiled. I haven't attempted to troubleshoot further beyond setting all my future Claude Code instances to pipe their stderr to disk so that I don't lose the stack trace next time.
Bun does not have its own JIT compiler. Bun uses JSC made by Apple. So your blame should be directed to Apple.
And I can believe you because I’ve seen JavaScript-heavy Safari tabs crash.
I run Ghostty and Claude Code on a work macbook and I haven't seen this yet.
I actually used to have issues with run away memory leaks causing my computer to hang which often required a reboot to recover from. I haven't experienced that in a couple of weeks now. Too early to say just yet but I think its definitely possible that the rust port fixed a bunch of memory leaks that have tangibly improved the experience atleast for me.
Segfaults were a thing with the Zig version. Purely based on the fact it's a line by line translation of the Zig code to unsafe Rust, all the Zig code that caused segfaults is going to also cause segfaults in the Rust version. The Rust code won't fix it until they get to the point of refactoring it into idiomatic and memory safe Rust.
But if the segfaults are new that implies it’s from the LLM no?
Who said they're new? Also, you can encounter new segfaults in a codebase just by executing code paths you haven't seen before.
It's a transpile. And not even a good one. The generated code is far from idiomatic rust. Some may consider it an abomination.
Seems to be working just fine though?
And like, this is just the beginning of the port. They did a mechanical port basically line by line, next step is to make it idiomatic rust.
I thought by now people would’ve learned to stop betting against this rewrite.
> Seems to be working just fine though?
As with all transpile ports, the true test will be how well it can be extended and maintained over time. Historically working with the output of a transpile is not pleasant and requires heavy rework to get it to the point where you can be comfortable enough to extend it.
The existing community is now either going to need to learn Rust or new Rust developers are going to have to join the project and they may not invested enough to refactor the transpiled output when they could work on something else like Boa.
historically we didn’t have LLMs which don’t mind “unpleasant[ness]” and “heavy rework”.
This is I think a preview of the future of software development. LLMs are having the same effect as compilers, frameworks, etc - they are making new kinds of software development feasible which were not previously so.
> historically we didn’t have LLMs which don’t mind “unpleasant[ness]” and “heavy rework”.
I'm not quite as optimistic. "Unpleasantness" might sound like subjective disgust, but it often relates to objective criteria like complexity, that increases the surface area open to bugs in a real way. Similarly, if reworking has a non-0 chance of bugs, its gonna have some form of risk, and a major one will of course be higher.
LLMs may be capable of a lot, and they miggt change what projects people can take on, but they definitely don't write bug free code.
The bun rewrite/transpile did use some neat ideas like lots of testing and per-file translations, so hopefully they have more in their toolbox than "LLMs hopefully won't be affected by complexity or write bugs"
> next step is to make it idiomatic rust
You can tell what will happen when they release it before sorting out all the new bugs introduced by the not-exactly-line-by-line port.
Sorry you think they’re not going to continue developing and improving bun and making it more idiomatic?
Given the success of the port so far and the fact that CC is now running on rust Bun, that seems highly unlikely to me.
That's a stated goal, so nope. But releasing it before any cleanups is another story.
I'd also like to inform you that
- the current success metrics solely consist of their advertisement, my eyes looking at the code strongly suggest otherwise
- the Bun team lacks knowledge to actually make it more idiomatic: none of the Bun team has written any Rust and relying on model knowledge is already proven insufficient.
The release decision itself is presumably driven by that tbh. It's only LGTM from there when nobody knows how to review unsafe Rust.
> the Bun team lacks knowledge to actually make it more idiomatic: none of the Bun team has written any Rust
Do you know how silly this sounds? Good engineers can work in any language. At the top companies (of which Anthropic is certainly one) they don’t have “C++ engineers” and “rust engineers” they just have engineers.
> Good engineers can work in any language
Given that they are investing their time into actually learning the language before diving into this mess. No, unsafe Rust isn't supposed to be something you can handle without prior knowledge.
Jarred was even asking in public how to use traits without runtime overhead during the rewrite. And the blog post phrased it like a normal problem to encounter while doing a million lines port... That's two months after the initial rewrite so you can guess if they learned.
One of the best Django engineers I ever worked with had hardly any Django or Python experience when we hired them, but had done plenty of Rails.
They were up and running and super-productive with Django within a week.
But Bun did not even release a new version of Bun written in Rust yet. It was still a canary version.
Yeah I don’t understand this port at all other than as a big marketing stunt.
It would have made far more sense, for reliability, efficiency, cost, etc., every metric really, to use or write a source to source translator that preserves as much structure from the original code as possible. Typically if you do a rewrite there are lessons learned from the existing code base that you want to take into account when doing the rewrite; using a bunch of agents to do the porting file-by-file buys you none of that. In either case the code will be an unidiomatic translation, just with LLMs you get an added source of indeterminism and a huge bill at the end of the month.
Can you show some examples of abominable Rust code they have?
Why not transpile directly into LLVM IR?
I don't think AI or humans are trained well on it.
Is it important to be idiomatic if the project meets its goals around memory safety?
No, but the project does not meet its goals around memory safety. It is usage Rust all the way down with same memory safety issues.
If it's not idiomatic, the memory safety won't be guaranteed.
grep -nr 'unsafe' .
Is all you need to know to consider how much of an abomination it is
This comment inspired me to take a look at the trend of "unsafe" in the Bun code over time since the rewrite PR first landed - here are the commits where that number changed by at least 10:
So not as much cleanup as I had expected!ChatGPT written script for counting here: https://gist.github.com/simonw/b1015bcadcedd1a781cedb7af9cbb...
The original code was one giant unsafe block with almost no tangible way to find or debug all the subtle memory bugs and leaks they had.
Now it's smaller, faster and has fewer bugs. Also its every potential memory issue is neatly annotated by an unsafe block so you can go and refactor them out one by one with confidence.
All this seems like a pretty huge improvement to me. Why is this an abomination in your eyes?
> The original code was one giant unsafe block
True.
> has fewer bugs
Nope, this is demonstrably false because Rust has its own invariants around its types and the codebase is violating a lot of them.
> every potential memory issue is neatly annotated by an unsafe block
"Potential memory issue" can originate in unsafe blocks and safe code that are able to alternate the input condition of these unsafe blocks. Guess what? That still counts towards 100% in this code base, hence the abomination remark.
> refactor them out one by one
Not as easy as it sounds. They are like threads in a yarn ball, if there are one or two ends visible it's easier to sort them out. The actual situation is more like we have tens of thousands of ends (all the raw pointer code that comes with every shared object), to fix them it's basically a requirement to unwind the whole thing (rewrite all the callees and reorder the data flow as needed, redesigning all the APIs during that).
It's too early to declare it as anything remotely close to a win, optimistically saying.
> Nope, this is demonstrably false because Rust has its own invariants around its types and the codebase is violating a lot of them.
I'm not sure I'm following what you're saying here. In the rewrite blog post it has been stated that the Rust port landed in a place where it passes 100% of the existing test suite and does so without some of the known memory leaks of the Zig version that they were aware of and didn't know how to address.
Sure, there's no guarantee that the port didn't introduce new bugs and most likely it did, but the 1.4 version has not been released yet, so I don't think a direct comparison of a long-time "stable" version and the just-landed full rewrite is meaningfully helpful.
> "Potential memory issue" can originate in unsafe blocks and safe code that are able to alternate the input condition of these unsafe blocks. Guess what? That still counts towards 100% in this code base, hence the abomination remark.
But that just means that once you get rid of the unsafe block, you're pretty much guaranteed by the Rust compiler to be memory-safe. This means that all your potential memory landmines are annotated in the code and once you disarm them all, you're memory-safe.
I don't understand how what you're saying contradicts any of my statements.
> Not as easy as it sounds. They are like threads in a yarn ball, if there are one or two ends visible it's easier to sort them out.
Still easier than the Zig version, where all the same things you've mentioned apply, but also there's no visible indication of progress and issues are unmarked and could be pretty much anywhere.
> It's too early to declare it as anything remotely close to a win, optimistically saying.
Based on the rewrite blog post it's pretty clear that the Rust version is outperforming the Zig version by pretty much every measurable metric at this point.
I think the backlash is mostly focused on the ideological opposition to fully AI-authored 1MLOC+ PR approach they took.
> In the rewrite blog post
They can't mention what they don't know. And that's the exact reason I'm against this: doing a port without being able to tell what is correct is asking for a disaster, obviously.
I've checked their posts and blogs for a few times, and I'm quite sure they don't know any of these to write about them.
> the 1.4 version has not been released yet
Let's hope the repeated delays (it was scheduled for last week) are not for quality issues, otherwise I'll only be half correct. It appears that all the MIRI errors are not stopping them though. (They have a script to run it but most probably it just fails and they don't care. Personally I'm not executing any of bun's code to avoid summoning nasal demons, so I actually don't know for sure)
> get rid of the unsafe block
Would be possible if they are not disregarding everything else going for numbers. E.g. they are actively increasing the unsafe surface by rewriting some code in SIMD C++ (https://github.com/oven-sh/bun/pull/33032). As if no Rust solutions already exist.
> Still easier than the Zig version
Well, this is true but only realizable if they know how to deal with the new problems emerging during the process. My current conclusion is that they don't.
> ideological
For me it's methodological as explained above.
For someone who is not a rust dev, would you mind giving me an example of this: "Nope, this is demonstrably false because Rust has its own invariants around its types and the codebase is violating a lot of them."
Aw I feel quite sorry for using the word "demonstrable" while not intending to demonstrate anything, in order to avoid any contributions to the project. I apologize for that.
That being said I've found a case that doesn't do much harm even if it's fixed, and is technically not my contribution. You may take a look at that:
https://github.com/oven-sh/bun/pull/30794
An "unsafe" in rust is like an axiom in mathematics. You can use to prove higher level theorems but it has to make sense.
The second that you start to introduce nonsensical axioms (or bugs in unsafe sections) all your proven correct theorems will be worthless.
But code is not mathematics, so incorrect code is not worthless, it’s just worth less.
It’ll most likely still do 99% of the things people need it to do, there’ll be a an issue created for that broken 1%, and eventually it’ll be iterated upon and fixed.
Unless you’re working on a security boundary of course, there you should treat it like maths.
Rust doesn't check for logical errors, it checks for memory errors. So every single issue in an unsafe section is a potential CVE.
Of course, but even the presence of CVEs does not make software worthless, it just makes it worth less.
You don't seem to understand what I'm talking about.
bad axiom -> worthless theorem.
bad unsafe section -> verified safe section is actually not safe.
I’ve understood the distinction. I just don’t like you equating “actually not safe” with “worthless”.
> has fewer bugs
who claimed that? Are you suggesting that the rewrite did not introduce any new bugs? The correct answer is, by the way, that no one knows since it's millions of lines of code no one has properly read.
> smaller, faster
I thought this has already been debunked. You could just write better zig and make it smaller, faster (and have fewer bugs!)
given enough time and tokens, it will become that. I really don't understand how that is a problem in any way.
LLM code has always been an abomination.
Oh good, the vibe coded prompt injection vector that casually accesses things in my home directory without permission is running on a vibe coded prerelease runtime using lots unsafe rust. What could go wrong?
Incidentally, Claude Code has been very buggy for me lately (much more so than before). Lots of TUI rendering issues causing, e.g., the conversation history to be garbled etc.
I've been (grudgingly) using Claude since February.
When I started, I discovered to my shock that it was by far the worst TUI I had ever touched. Rendering glitches, keyboard input screwups, and just all-around jankiness.
Despite that awful baseline, I have to agree that it's gotten noticably worse in the past week or so.
It's started mangling my terminal sessions somehow, so that not all characters I input are visible in the UI.
Backgrounding it, doing a 'reset', then re-foregrounding seems to fix it.
Of course when I asked it to diagnose the problem, it assured me that Claude has no such big and it must be something else I'm running.
All I'm running is tmux and Claude, though, and the behavior surfaced while I was running Claude.
So, yeah - if they just recently updated Claude to use the Rust rewrite, this increased crappiness might actually be due to that. It does seem to at least roughly correlate.
Every time I resize my window now, the output is completely garbled. I often have to ask it to repeat itself just so I can see what it just said. This isn’t a new thing, but it feels like it’s gotten worse. This is on Windows
Same observation. One thing you can do is close out the session and `claude --resume`
Does exiting following by resuming the session fix it?
I'm far from being anti-AI, but these guys take it way too far IMO. It's straight-up AI slop. Like a real engineer still needs to be in the loop and drive the tool.
Anthropic seems to be all in on 100% AI code.
Why even write Claude code in JavaScript at that point, assuming they write the application logic in node and also include the interpreter in the application?
Probably because the team lead is a web developer, and whatever he says goes. Companies are typically very hierarchical, even if they like to claim otherwise.
Whatever the headaches of the internals, I haven’t heard any substantive outcomes in hacker news that have been impacted by this change.
Yes if we had a Zig->Rust transpiler maybe it would produce similar output. But I can’t find one. We’d have to use an agent to build one first :)
a terminal app now has a supply chain long enough to include a runtime acquisition. somewhere between "rewrote it in Rust" and "ship it" someone said "or we could just buy the company"
Contrary to many, I have high hopes that Jarred and team will lapidate the ported codebase and it will continue to flourish as an open source project.
The port of Bun, which has >5000 open github issues, is used in Claude Code, which has >11000 open github issues. Do people use Bun in things that are expected to work reliably? Have any such projects tried the upgrade yet?
To be fair, https://github.com/python/cpython has over 5k open github issues, and that's still generally considered fairly reliably technology even if a lot of HN users seem to hate it.
It's not a great way of inferring software quality, but I think the numbers for both Bun and Claude Code are pretty bad.
cpython has ~7,000 open issues, but ~70,000 closed ones, a 1:10 ratio. Bun's ratio is above 1:2.5, while for Claude Code it's slightly over 1:6.
Much more importantly, though, Bun's oldest issue is from Sep 2021, while Claude Code's is Feb 2025. cpython's oldest issue dates from June 2000 (presumably migrated from an older tracker). Claude Code has very nearly the same total number of issues (open + closed) as cpython at around 77,000, but Claude Code has done it in a year an a half whereas cpython has taken 26 years to get there.
It's a good comparison to pick, as it can't be explained by popularity. For all the real-world use Claude Code sees, it's nowhere near what cpython sees, even over the year and a half in question. Bun, meanwhile, is hitting these numbers while not even being the mainstream choice for what it does (node still holds that crown afaik).
11k in two years vs 5k in two weeks? You're right, numbers speak for themself.
Did Bun mass-close issues that predated the rewrite? It doesn't look like they did, as the oldest open issue is from 2021 and there are many from 2022, but maybe they did something that killed most of the old issues.
Their (public) project management is horrible, you can find fixed issues unclosed and unfixed issues closed. Not really surprising when that part of the work is completely taken over by LLM agents though.
Ah so that's why it has been crashing constantly for me.
Why not just use Deno that's made in Rust and also has safety in mind?
How will Anthropic be able to rewrite that in Rust and use it for marketing?
Yeah I'm also wondering what the point of Bun is when Deno already exists. Especially since it added Node compatibility. Genuine question, why should anyone use Bun if they're already using Deno?
I'm stupid and clearly too stupid to google too. Is bun simply a better nodejs? Assuming it true that all of Claude code is now written by AI, why would AI care about using bun over node?
They’re just wildly successful terrible engineers who can describe problems well and have unlimited token budgets. If they were paying for their own token use, the software would be better, they simply don’t have financial incentive to be more performant.
A dirty secret of AI data centers are that they’re only getting 40-60% efficiency out of their GPU clusters and because the moneygun go brrrrr they just buy more.
You wonder why they’re so afraid of the Chinese competition… they can’t afford to be as wasteful
Describing problems well may be one of the most important skills an engineer can have.
It was an intersting case. Watched a youtube video about this and discussion from zig founder and bun was a little weird.
What is the actual contribution and motivation of this post?
I thought it was interesting. I didn't write this with Hacker News in mind.
(I was actually half way through writing about something related, when I thought it would be interesting to see if I could prove that I had the Rust version of Bun on my laptop already.)
People shouldn’t overthink blog posts. Just write what’s on your mind and have fun.
The motivation is obviously clear. No-one would be doing that for fun 24/7, only covering about AI and nothing else without getting paid for it.
If anyone else did that on HN, they would be accused of slop with their domain blacklisted.
"only covering AI" - don't miss my wildlife photography! https://simonwillison.net/elsewhere/sighting/
(Unless photos of actual pelicans count as "AI" content now.)
I just shipped this filter UI so you can see my other non-AI-tagged content in one place: https://simonwillison.net/search/?exclude.tag=ai
> "only covering AI" - don't miss my wildlife photography!
The "ai" tagged posts (2,100+) significantly outnumber "sighting" posts by orders of magnitude. Even searching HN, this post is the very first mention of it.
Perhaps that is why everyone here (except you) overlooks that or why we don't see much more of those sightings posts here either.
Yeah, wildlife photography is a new hobby - it used to be every few months, now it's several times a week.
I would be very surprised if one of my sightings posts made it to Hacker News. Maybe if I manage to snap a photo of an actual pelican perched on a bicycle some time.
There are many people with unbridled enthusiasm and an ability to write fast
Knowing Simon - he’s very much both :)
I don't blame him, if I had Anthropic's money hose pointed directly into my pocket I'd be spamming HN non-stop too
I've not made any money at all from Anthropic.
You can see my list of previous weekly blog sponsors here: https://simonwillison.net/dashboard/sponsor-history/
None of them get any influence on my content. That would hurt my credibility, and my credibility is the reason my site is worth sponsoring in the first place.
Honestly, if OpenAI or Anthropic offered to sponsor I'd probably turn them down. The optics of taking sponsorship from companies that I frequently write about are not great.
Fair, that rules out "Anthropic pays you directly."
But look at your own disclosure page [0]: OpenAI paid you for your time at a GPT-5 preview, and you regularly get early access, embargoed previews, and free API credits from OpenAI, Anthropic, Gemini, and Mistral. So "I've made no money from Anthropic" is narrower than it sounds, access and preferential treatment are compensation too, even if cash didn't directly change hands.
Same goes for the sponsor list. Microsoft is OpenAI's investor and infrastructure (or was anyways, I've got no clue what the status of that is these days), Amazon and Google are both major Anthropic investors, and most of that list runs on Azure, AWS, or GCP, or sells tools built on these labs' models. Taking a Microsoft sponsorship isn't really separate from an OpenAI one, it's just a single hop removed. The entire software ecosystem and all the players in it are entangled in this bubble.
I'm not accusing you of consciously hyping any of them. Your posts are high quality even when I disagree with the contents of them. You often list downsides too, prompt injection, security, slop issues but the throughline still repeats: this is inevitable, get on board. Product-market fit found, November 2025 as the inflection point. That kinda framing shows up again and again throughout all your posts.
It's refreshing that you're upfront about the previews and credits and all that jazz, but surely you understand why some people stay skeptical even with that disclosed as it confirms the access exists.
Whether you realize it or not, I think they are indeed paying you in some sense, which is part of why I'm skeptical when your posts consistently land at the top of HN. Not because the writing isn't good, but because I think the same incentive shaping the coverage probably shapes some of that reach too.
[0] https://simonwillison.net/about/#disclosures:~:text=2024%2E-...
Your comment here is fair, and it's why I take my disclosures seriously.
Nobody is unbiased, no matter how hard they might try. I like to get my information from sources where I understand their motivations, so my approach is to try to make my motivations as clear as possible.
(That's why I spend an unreasonable amount of energy arguing with people on Hacker News who call me a shill!)
At this point we all know the answer
Is anyone else failing to understand all the internet drama surrounding this?
The rewrite may work out on a technical level or it may not. Let's wait and see. The Bun project did not swear a blood oath to use Zig forever, and it's ultimately their choice to switch to a different programming language.
Beyond that, people seem to be incredibly emotionally involved with this, for reasons that entirely escape me.
Is it easier to rewrite Bun than it is to rewrite Claude?
Damn, I should have not migrated to Bun. Should I revert back to Npm?
I am getting into the frontend dev and one thing that I don't understand is why people use bun in the first place? It's not much better preforming, it's not much safer, it's still not 100% compliant. Some tests show it's actually slower than node. Why bother switching, then?
Faster package manager
Faster startup
Typescript support out of the box
Better stdlib than node
Stdlib includes yaml, sqlite etc so you need to pull in fewer deps, so you can avoid the left-pad/is-even node_modules explosion problem to a greater extent
Can't comment on others, but new Node.js also has typescript out of the box and works pretty well.
I don’t think you would use Bun for front end.
That's what Claude Code does at least
I mean, Astro on Bun?
So much of JS dev is just saying no to random new stuff, Bun included
i assume it's because of all the built in tooling that node doesn't ship with.
There's always deno
but it's written in Rust too /s
What specific technical issues are you experiencing with running Bun that would justify a change?
I love bun - although disliked how Jarred did the conversion.
Project-wise, nothing has changed.
Bun was always great because of the fantastic dx - it was just really easy to use , with stuff like out of the box typescript (unreal that it took so long for node, and it's behind a super long flag, wtf...). And it didnt have the weirdness of deno, it maintained backwards compatability with node api, and it just worked.
But it was never stable. You'd have to be fool to believe that a single project could stably do everything bun covers. It's always been an insane project. It was built on top of zig, a langauge that hasn't reached 1.0, and is constantly changing, and throw in how he was rewriting his own custom zig stuff. Like c'mon, let's apply some common sense here.
For me, little has changed. I am still going to use bun as a nice dev tool, and use node for production.
Anthropic bought Bun, so they kinda, sorta had to make this work. I am sure the cost at $145,000 in Claude time will get some attention.
I am curious how this will work going forward from FOSS perspective. Will humans be allowed to modify the generated code? Only the .md prompts for the agents? Or what?
My perl re-write is not very good.
you know what i hate? i hate that each update, to codex or claude code, it seems like they're always trying to "hide stuff" , reminds me of the 80s and 90s when tech assumes normal people are too stupid to see 'raw' stuff like terminal commands being run, its always been like that, less so now, but i get so mad when its doing stuff, and i can't see if its deleting files or just screwing something up. btw this is totally free tool buttonscli.com that is a full UI terminal app but its got a button for agent control. You click that, paste into claude code or w/e/any agent, and it'll use that for the terminal commands instead of the built in one so you can see everything (and it can open 10 tabs if it wants, you see them all)
Turns out it was just a build step after all.
So does that make Claude Code any better?
Can you select text with shift + arrow keys now in the command line client? :)
It’s interesting that Bun was a human rewrite from Go to Zig. (I think?). Then rewritten from Zig to Rust.
AI is pretty good at rewrites and ports. Quite good infact.
Has all of this drama turned anyone else a bit sour on bun?
I have a long running side project I migrated to bun, and I'm starting to regret it. I don't want to build on top of this much churn.
TIL about Bun.
pi runs in TypeScript and I like it, the target language of the tool, for me, matters only such that I can extend it. I like writing extensions, plugins, things, in TypeScript so I'm cool with that!
Claude Code is closed source, doesn't let me extend it beyond hooks, and these I write in bash anyways.
That all said, why should I bother about this change? Feels like a nothing burger to me, as an end user. This should matter more for those that are internal to Claude Code and Bun developing it.
I despise this era we live in. Pushing rewrites like this upon millions of users, when the Bun rewrite has countless known issues and is likely a security nightmare. Every time I ‘brew outdated’ and I see a wall of updates I die a little inside knowing that most of this code has not been verified or even looked at. Yet we hear about massive supply chain attacks pretty much every week now and we’re still full steam ahead on this vibe coded nightmare. God help us. Claude Code in particular updates sometimes multiple times per day. Like I’m sorry but there is no way all this nonsense is safe.
Basically Anthropic can ship any trojan in underhanded Rust to any target because it is not possible to audit 1M lines of slop.
And the crowd is cheering.
It is absolutely amazing to me that this ai rewrite work so well, maybe claude is not really that much of a complicated tool to stress the bun runtime but still...
It works well because they had tests, they could compare before and after. Likelihood of issues especially if you transpile to a safer language should be minimal.
This post is just "they didn't lie"...
For real
bun upgrade --canary
you are welcome
Yeah, I noticed. I had Claude write a quick JS script for me a few days ago, it then tried to use Bun to run it. When it couldn't find it, it tried to install it with `sudo pacman`. I had to fucking tell it to use Node instead.
as it always should've been Rust was the right move
at this point im declaring any "rewritten in X" articles as trolling lol.
Honestly, I initially thought rewriting an entire codebase with AI would be a huge mistake. After reading this, I'm starting to think I was wrong.
If projects like Bun can be substantially rewritten and shipped to millions of users, it suggests we're entering a very different phase of software development.
Today's AI-generated rewrites may not produce code that humans would consider high quality or maintainable. But I'm beginning to wonder whether that will even matter in a few months. If AI is the primary consumer, maintainer, and refactorer of code, human readability becomes far less important than correctness, performance, and the ability to iterate.
This feels like a shift where software may no longer exist as a long-lived artifact in its current form. Instead of writing and maintaining applications for years, we may generate, adapt, and discard them continuously for each use case.
Some of what you’re saying is likely true but quality is something that will never be optional. There is quantitative data suggest that LLMs perform better on higher quality code base which makes sense. Code that is well organized and coherent will make better use of the context window.
Software refactoring and tech debt is absolutely where LLMs will shine as is evidenced by the Bun rewrite.
> I initially thought rewriting an entire codebase with AI would be a huge mistake
Keep in mind that you are not Anthropic, and you'll likely NOT consider rewrite at all if you don't have unlimited budget
> But I'm beginning to wonder whether that will even matter in a few months.
At that point, even Bun itself doesn't matter. All intermediate tools don't matter if LLMs can reliably write something large.
The problem is that LLM is not quite there yet. The rewrite was only possible because they mostly stick to 1-to-1 translation resulting in non-idiomatic Rust code. So, what from there? I don't think they can really build up a sane codebase from that state. They only shot themselves with a bigger gun.
> The rewrite was only possible because they mostly stick to 1-to-1 translation resulting in non-idiomatic Rust code.
That’s patently false, just read Jarred’s own blog post describing how that was the first stage only, they went through many more to get the amount of non idiomatic, unsafe Rust code to an acceptable level.
Somebody checked[1], and they discovered that the "stages" past the first had minimal impact on the unsafe blocks count. That's just one metric, but it makes me doubt your claim that there was/is a lot of work put into making the translated code idiomatic Rust.
[1] https://news.ycombinator.com/item?id=48967630
Isn't it just: "while true {refactorIdiomatically(); fixErrors()}"
/goal fix all bugs
That sounds like a massive waste of finite energy and compute resources.
That's like saying let's stay with horses.
We'll develop faster and better tech. We'll find resources to feed that. Use that to build better. Access better resources. We'll mine asteroids. We'll harness much more from the sun. The factory must grow.
Is that before or after the earths atmosphere acidifies for humans and our bodies can’t hold enough phosphorus or calcium for basic metabolic tasks? You have until 2050:
https://doi.org/10.1007/s11869-026-01918-5
these doom and gloom reports also said half the land will be under water by now and average temperature will be 40c. Didn't happen.
Earth is in a cooler period and it will get very warm. These crappy climate change activists will not get anything done but to hold us back. We need more power, more tech, and more abundance of things. We will need to engineer our way out of real climate change.
Don’t look up - or that hubris might crush you.
Oh we should certainly trust the opinion of the science denier. Surely his opinions will be based on hard data and not on feelings!
> Honestly, I initially thought rewriting an entire codebase with AI would be a huge mistake. After reading this, I'm starting to think I was wrong.
> If projects like Bun can be substantially rewritten and shipped to millions of users, it suggests we're entering a very different phase of software development.
exactly. this wasn't a technical project. this was a marketing stunt that worked on you.
We are the ones to get to decide. Do we want that? I don’t. But im just a single data point
> Startup got 10% faster on Linux but otherwise, barely anyone noticed.
Just that?
I was expecting more from that rewrite. Maybe Rust is not so worth it after all.
It was already written in a very performant language so no significant performance improvements should be expected.
The benefit of a rust rewrite is memory safety improvements, but currently they've just rewritten zig to unsafe rust so they don't have that either yet
I don't think their motivation was primarily user-visible stuff. They backed themselves into a corner by forking Zig, and also were fed up with fixing memory errors.
You wouldn't notice either of those if you were a user, unless you happened to hit one of those bugs.
The blog claims rust chosen mainly to address memory issues, which rust is a better language for. So, success would simply be less new memory errors / easier to patch old ones.
Claude installer/updater had a high memory usage problem (Gigabytes of resident memory used during a fresh installation of Clade with it's native install.sh script, or during a claude update). This was reported as early as December 2025, see https://github.com/anthropics/claude-code/issues/12327#issue....
The latest Claude installer (2.1.215) possibly does not have it anymore https://github.com/anthropics/claude-code/issues/4953#issuec..., but more tries on various machines are needed to confirm that.
Ok, so let me wrap this for everyone:
While everyone here in this forum kept arguing (and fighting and yelling at each other) whether tis moral/right/secure/cheap for ppl to rewrite and ship a major software package with LLMs/agents, one of the main drivers behind AI actually did it, without consulting your opinion, and most same everyone actually slurped this decision without paying a a notice.
Boring is good, but this boring is super massive major thing that happened, and precisely because security is still intact.
I have a better idea: convert it to a prompt and commit the prompt to the repository. Then Mythos will be your compiler.
the whole Ai skit is anthropomorphing the compiler as a coworker.
I've been using Claude Code daily for a fairly large FastAPI project and didn't notice anything unusual around that timeframe. If this really was the Rust runtime underneath, "boring is good" seems like the right outcome.
I'm looking at this situation strictly as 'What's possible today'. If a 1M lines code rewrite from one language to another goes into production in 1 month, that's a very strong signal that the models are now insanely capable.
My anxiety before merging a 2K lines PR is greatly reduced after 3 frontier models (Fable, 5.6 and kimi K3) finds no issues in it.
Just 6 months ago (Opus 4.6) this was not true, a big PR would have countless number of issues.
Aside from the human drama, the message to all of us is - these things are ready for whatever your imagination can throw at them.
I think that's exactly what Anthropic wanted to communicate.
It was not really a traditional rewrite. More like transpilation. Still impressive
> Aside from the human drama, the message to all of us is - these things are ready for whatever your imagination can throw at them.
…if you have the compute and capital to run that whole agentic system
[flagged]
Please don't.
We detached this comment from https://news.ycombinator.com/item?id=48970444 and marked it off topic.
Everyone associated with "Claude" "Rust" or "Bun" is an idiot.
Any time I see any of those words "Kagi" too I immediately ignore whatever they're trying to sell.
Nobody ever believed these people were creative technologists. Anyone who uses any of these buzzwords is a hack.
Real LLMs are ran locally on real computers (not in data centers optimizing for cost).
Real software is written in C++ and JavaScript.
The browser is Chrome, until someone does something better.
I don't make the rules.