Comment by maxloh
2 days ago
I understand their decision. How could the maintainers understand their codebase if most of it was not directly written by them?
It is impossible to review the entire rewritten codebase. There are just too many lines of code, 1 million lines to be exact [1].
Completely regardless of how the code was written or even if anyone understands it thoroughly, they replaced the entire running codebase in a week. The entire project was one thing and is now something different.
There are countless reasons that this is a very bad thing for consumers of Bun. First and foremost you've instantly lost any and all assurance that it works the way it's supposed to. Every project has load-bearing bugs that may or may not still exist. Can you trust the core behavior is the same?
If the Bun maintainers are willing to completely replace their core product over the span of a week, how is anyone supposed to rely on it? What's preventing another rewrite in a few more weeks?
If you want to position your product as a dependency, it needs to be stable and reliable. Throwing away a million lines of code and replacing the entire product overnight is pretty much the polar opposite of stable and reliable.
It has nothing to do with AI rewriting the code, it's the reckless abandon and wild disregard for consumers that is the problem. It's literally a rug pull.
I don’t think changing from zig to rust suddenly means that don’t know what a certain file contains or how it works or how it relates to other files.
It’s all the same just different syntax. Which, by the way, is why it looks ugly to rust developers. The devs wanted the code to look familiar to them.
I do think they should have called this 2.0 though. Would not feel such a rush (1.3.14 has a few regressions, and no one really cares because there are lots of small rust fires now).
Overall, the bigger issue is that bun chases shiny objects. But never finishes. Just look at test stuff. Most of vistest, but not all. Most of jest, but not all. Most of pnpm, but not all. Now we have image stuff, so most of sharp, but not all. dev server? Most of vite, but you guessed it… not all. Long running process… mostly like node but with memory leaks (and a motivation for rust I’m sure).
When I saw them posting about the Image routines my heart sank. Another shiny object. Coincided with test bugs so I moved to vitest completely.
> It’s all the same just different syntax.
That reminds me of Chris Reigrut's story from https://thedailywtf.com/articles/Holiday_Smorgasbord
> Support : I'm telling you, nothing changed!!! The only difference between the old version and the new version is that the old version was in COBOL, and the new one is in C!!!
Thanks for the chuckles!
I don't know why but AI and LLMs seems to make people to lose basic sense of rationality. I didn't think we would have seen so many comments such as "It’s all the same just different syntax" after a full rewrite some years ago.
I assume most of the complaints about the massive rewrite are in regards to AI, not Rust.
As lots of large and small companies have shown, test suites can only find what you test for. Vibe coded test suites can find?
On the whole, I think vibe coded test suites can be pretty good. But it really depends on how you prompt. I often get the AI to brainstorm needed tests into a text file while it works. Then later I get another agent to write tests based on the list.
It does a reasonable job. Its also pretty good at writing regression tests when it fixes a bug.
Where LLMs struggle - or at least where claude struggles - is fixing the actual bugs. Its very good at getting the test suite to pass. But it cheats. It'll sometimes disable a test, or do some hacky workaround that makes the test pass that doesn't fix the underlying issue. It'll say "All done, the tests pass". But sometimes you really wish they didn't.
I'm wondering if it might be better to set up 2 agents adversarially for bug hunting. Give one agent the goal of finding as many bugs as possible (via tests and other techniques). And another agent has the goal of fixing the bugs.
5 replies →
> Image routines my heart sank. Another shiny object
With quite a peculiar set of supported formats different between operating systems.
Heh, that would include the tests where the content is just replaced with a single sleep.
> I don’t think changing from zig to rust suddenly means that don’t know what a certain file contains or how it works or how it relates to other files.
What if there was some malicious code within the 1 million lines?
What if there was some malicious code within the 1 million previous lines?
The problem is trust... About nobody has the time and the resources to read 1 million lines of code, keep everything in their head and derive whether there are problems...
2 replies →
Pretty normal in many corporate cultures especially ones with high turnover. You get assigned to a team that's "maintaining" a 10 year old code base with few million LoC. The most senior person on the team has been there for a year or 2 and it's just business as usual. You don't know what those 1M+ lines are doing. No one does. It's not a passion of anyone to work on it. You just get a bunch of requirements handed to you, you blackbox everything but the surface areas you need to touch. It's why there are 14 implementations of a background service 8 dependencies that do the same thing, 6 overlapping frameworks, a complete mismatch in style, approaches, etc. It doesn't really matter.
> It doesn't really matter.
It does matter, that's why those people quit because it's such a shitshow, progress happens at a glacial pace, more and more defects and slowdowns keep being created even if they have a big QA department/teams and the users are probably trapped because the software is the only thing in town, the bosses are the ones that makes the purchase decisions, or the it comes attached to big and/or expensive machines and they can't just buy another one for another X years.
yes, of course. I meant "it doesn't really matter" in the sense that businesses have been dealing with this since the beginning of software. Strong ownership and passion was one of the selling points of OSS, but that style of ownership was always very very rare in corporate. It just doesn't really fit with how businesses operate. The "passion" is ARR, not engineering principals. Most software is built, sold, and bought by people who don't use it directly.
1 reply →
People quit because maintenance is an unsexy job with poor career prospects.
The code base itself has never and will never matter in the big picture
2 replies →
Sounds like a great explanation of why it does matter!
Human-written code is theoretically surmountable.
Large LLM-written code is called slop for a reason. It's hard to understand because oftentimes it does not follow human logic.
Even a bad developer, that is, the average developer, develops a whole in which the parts have some degree of coherence. AIs simulate that, but they don’t have intent and thus this coherence is broken in large code bases.
Right. I now have responsibility for rather large codebases where the person who generated it with agentic tools (I'd say it's better than pure 'vibe coding') barely understands how it works. This is okay for unimportant parts of the codebase, but completely unacceptable for a critical piece of infrastructure where it really needs to be well thought out.
> This is okay for unimportant parts of the codebase
Not really. At some point the technical debt accumulates and the only option is to trash it all and start over.
The only party that profits here are the cloud token providers.
So it was possible to write ~2 million lines of (mostly) zig, but it's not possible to review ~1 million lines of rust, even though the same test suite included in those 2 million lines of zig can still be used? I'm not convinced the rewrite is a good idea and will work out, but I'm equally unconvinced by your argument.
Its possible to do that over a period of a few years. Sadly, the Rust rewrite happened in (checks notes) 8 days.
[flagged]
So this question was never answered: If Zig had so may problems that they felt compelled to rewrite it all in Rust, does that suggest the great Mythos was unable to fix the Zig version?
Isn't this suppose to be the most advanced model ever and you're telling me they can't just schedule a cron job that detects and repairs the zig version?
Really? Did they just completely admit that the great AI future can't secure a significant project repository?
6 replies →
It should go without saying that the 2 million lines of zig wasn't generated and shat out into the Bun repo as a single PR within a week.
In a week?
How much of the windows code has been written by its current maintainers? Little.
I feel this argument is not valid, especially for large code bases.
Documentation and code quality is what is important, not who wrote the code.
A project that's 2/5/10/30/100m LoC is obviously not going to be understandable entirely in someone's head. Documentation is critical. But if I'm reading your code, and I come across something confusing or you wrote something in a weird way and I want to understand, then I just... Come and ask you. "Hey, why did you do this this way? Did you consider x?" With an AI you can't do that. IMO this point is especially important if your code base is widely deployed to the point that people use it as a learning resource or a good source to learn good practices.
Isn't windows notoriously shoddy right now, so much so that Microsoft is making a big public effort to try to improve its quality?
True. But you can pick any code base with 20 years of existence, what I said applies.
it's funny how the readme still says "written in Zig"
If Claude isn't even able to correct the readme, I don't know how one can have hope it produces decent results.
Maybe it should say "designed in Zig" because most of the work & thinking was done using that language. The rewrite has no such history.
Is that the new "Designed by Apple in California" equivalent of "Made in China" euphemism but for vibecodes?
1 reply →
I don't use Node.js or Bun, so I'm little out of touch. But what need 1 millions lines of code as the js engine itself is a library ?
I've been wondering the same.
[flagged]
> in many aspects of human history, we have traded understanding for convenience—that's the reason why we buy food at the supermarket instead of hunting for our meal.
You could always take a job on a cattle ranch or an abattoir or meat-packing plant, or watch a How It's Made documentary, and get some understanding of how the sausage gets made and put on the supermarket shelf for your convenience. This was also true as we built abstractions in computer technology: you could start off learning a high level language, then learn a lower level one, then study or build an operating system kernel, a compiler, an assembler, machine code, and then crack some books on microprocessor architecture and signal processing. You could always "go deeper" if you wanted to. And there is a payoff: understanding at a deeper level helps you get things done better at the higher levels (e.g.: understanding the concept of memory hierarchy helps you lay out data structures to make code faster).
There is no such step for slop-coded codebases: you become entirely dependent on a context-limited LLM to have a shot at even approximating some understanding. The proponents of this style will tell you, don't look at the code. It's the antithesis of every other abstraction we've built in computing.
Perhaps more productively, you treat the slop as a black box and build something understandable around it.
This is also why the notion that developers in the future will be committing LLM prompts in English to repositories instead of code written in a programming language is so foolish. I am saying this as someone who uses LLMs quite a lot to help with generating and understanding code.
The limitations are far overstated. Who cares if you don't understand every bit but the LLM does? Is the LLM good enough to ship to prod? Great.
Understanding every corner of your codebase is overrated. LLMs, properly harnessed, are good enough.
What are you talking about? How do you think food get to the supermarket? People put it there.
The entire chain from farm to table is managed and operated by humans.
Every automatization effort ever always had human oversight.
Its not the same thing as entrusting the entire codebase to overachieving markov-chain who has no concept of correctness over anything of sounding ok.
Honestly, saying the humans understanding codebase is a dead concept is the most techbro-ish I heard today.
THIS time it’s different.
[dead]
>How could the maintainers understand their codebase if most of it was not directly written by them?
Counterpoint: I look back at code I wrote a few years ago and just take it on faith that I knew what I was doing at some point. That's still better than never knowing, but it requires faith--faith in a human, vs. faith in an LLM.
Yep. These days, simplicity is a massive part of my development style. I don't want to be looking at a codebase, even my own, and thinking "shit, this guy was way smarter than me".
They support Windows, which is many millions of lines of code not written by the current maintainers.
It's a bit harder to avoid windows than it is to avoid Bun.
More importantly, it's not the same thing at all. All the code in windows (at least until recently) was written by humans, understood by humans and reviewed by humans. And that code has stood the test of time, proven its value and stability in the wild, on billions of systems. The fact that the current maintainers haven't needed to understand or replace the code is some indication of the code's quality.
Almost none of Bun's rust code has been even seen by a human, and it's only about two weeks old.
I'm somewhat willing to accept vibe-coded code if it's either absolutely non-critical, well reviewed, or maybe in the long term if it's proven itself. But not two week old code.
That's a valid way to approach this - bun isn't valuable enough to bother with or at least wait for a while, Windows is.
But I think the comparison is closer than you are making it sound. I sincerely doubt the Windows codebase was all written by humans, let alone reviewed. And my understanding is that the code is being regularly rewritten and replaced because of how flawed it is, it's just a massive undertaking.
Also if you look at their investment in AI-driven code rewriting into Rust, my bet would be that some modern Windows code itself is being vibe-coded.
1 reply →
> They support Windows, which is many millions of lines of code not written by the current maintainers.
All of which was battle-tested on millions, if not billions, of devices over 40 years. The new Bun is effectively a different project than it was a month ago, with next to no prod use.
I have no problem having a dependency on a 40 year/billions of use software, I do have misgivings about a dependency on a project that has never been used in prod, and was only written last week.
Windows have a incredible degree of architectural coherence and design intentionality.
It is far easier to understand some part of the various NT source code leaks than it is to understand Claude code leak
This comment is true on both points: Dave Cutler certainly knew what he was doing.
I'm very skeptic that they read the entire codebase of Bun prior.
> I'm very skeptic that they read the entire codebase of Bun prior.
Well, they didn't really need to. A complete rewrite is effectively a different project. You may feel comfortable using a new project in prod, but most people are not.
Project A: used in production for 3 years - high trust.
Project B: Has yet to be used in production - low trust.
IDGAF about automated tests, let other users shake out the inevitable bugs that show up in prod and after a few years of stability, then we'll see.
To me, it's not about whether humans reviewed the code or not (they didn't), it's more about "here's this brand-new shiny codebase of ~1m Sloc, of which exactly zero lines has been used in prod".
People that like AI are always happy to point out that their code was written fast and passes tests. For me thats just the bare requirement to have more than a “wip” commit on my local codebase.
To create a PR, I need to test it manually. But the only true test is to survive production usage for a while. That’s where edge cases become normal occurrences.
yeah this just feels like an attention stunt tbh
It's not impossible, or even that hard to review the entire rewritten codebase.
10 engineers each reviewing 5,000 LoC a day for 20 days can do it.
And that is being highly conservative with the estimate. A good chunk of the the code is probably highly trivial boilerplate one can easily skim over in minutes.
And five engineers reviewing 20 thousand LoCs would get the job done in ten days, but both numbers are just as BS when it comes to actually understanding the codebase. No one is comprehensively reading 5k lines per day for a month straight.
Seriously, “just review 5k lines a day for a month” is the most out of touch manager suggestion I’ve seen in a hot minute. As though you only need to read each line one single time in a review before magically committing its exact purpose, content, and overall implications to memory. The absurdity of which is multiplied for AI generated code which, based on what I see from my coworkers, is clunkier and weirder and less focused even than regular human code, on average.
20 days is rookie numbers. I can get a million engineers to each review a single line and finish code reviewing the entire code base in a minute.
the code base was rewritten file by file, so parallelizing individual files makes sense, but lines is just BS
5k LoC review every day is absolutely absurd, nobody who has actually worked as a software engineer would suggest that is reasonable
[dead]
This is why I require all my software to have bespoke compilers otherwise how can I trust the devs know what their code is actually running!?
Just because we don't understand or know about compilers or able to read their output does not make them fungible.
In old days we chose between Turbo/Borland C, Quick C and GCC. We didn't think them same or trust blindly even if we didn't know how they worked.
The best developers hand optimized assembly for sub routines which they knew compilers were not good at, the rest of us sure didn't understand how any of it worked, but nonetheless felt the differences and chose with dollars and usage .
Part of what I’m getting at is exactly your point that we used to think about what compiler to use and didn’t always blindly trust them.
If you have enough tests at what point does AI rewriting software in a different language become close enough to ‘deterministic’? Maybe never, maybe not.
1 reply →
I'm certain that the maintainers of Bun have excellent understanding of their codebase. What makes you think that they don't? They wrote the code in the first place. They know the architecture. They know what pieces do what functions.
They did not write the rust code. AI wrote that code. Your response is side stepping the primary issue people have with the rewrite: no human has read and understood all the code AI wrote.
I agree but would propose the weaker argument: no set of human contributors have, put together, read and understood all the code. Even in artisanal-coded projects of sufficient size, it's rare that any one human has read and understood all of it.
2 replies →
I had an actual look at the code, and because it's a translation it's not just straight up de novo slop. The bits I saw were fairly straightforward 1:1 translations, so the Bun developers should still be familiar with the overall structure and logic.
I still think it's mad, but not quite as mad as you might first think from the headlines.
7 replies →