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.
> 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 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.
I find that adversarial multi agent setups eventually fall down because one side or the other always manages to convince the other side to give up given enough time.
I’ve tried all sorts of things to keep Claude from cheating, but the only one that works is to restrict access to the tests files, which obviously isn’t a real solution.
We recently had an “AI week” at work and I spent $1000 in tokens trying out different iterations of this.
> Image routines my heart sank. Another shiny object
With quite a peculiar set of supported formats different between operating systems.
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.
Businesses have been dealing with - more capable one refuse your business and walk away. Or you have to drop prices. And yes, I have seen it happen.
It is not immediate process, but it is a thing.
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?
AI is extremely good at rewriting existing code, and rewriting code is a classic engineering productivity trap. That's a tale as old as time; "we need to rewrite the api in Go" said every new midlevel engineering hire ever. Of course, 9 times out of 10 we don't do it, because the unpredictable costs always outweigh the benefit, and in Jarred's case we're starting to see these costs surface. They aren't technical, they're political; broad swaths of the community have lost faith in him and the Bun project.
Write in C, snapshot to memory safe production Rust that had been verified and differential tested to within an inch of its life. This is a hard reality. Ports will become cheap. Disposable. The vuln finding capabilities are changing everything and not a lot of solutions are out there yet. We can automate the ports and get them efficient.
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.
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.
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.
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.
[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 .
>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".
[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]
I'm very skeptic that they read the entire codebase of Bun prior.
yeah this just feels like an attention stunt tbh
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.
The million or so lines of the original code has been "battle tested" for what it's worth.
This is a massive codebase created within a week or so ago, no one can say what it will do till it does.
"No human understands any of the code" is not the same as "no human understands the entirety of codebase fully". Very different situations.
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.
It's the little bits that aren't 1:1
Who wants to review a brand new codebase for free?
Why is it for free? Isn’t Anthropic paying their salaries?
That doesn't change anything. No one can say with confidence, backed by proof, that the 1M slop is semantically equivalent to the old code. The code is a black box without that guarantee.
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.
I mean should we even compare Bun to Windows in the first place? Like Mircosoft with its resources would find a way to support Bun and Windows is one of their most popular and most used products. The situation with Bun is very different in terms of business/product.
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
[deleted]
It’s not like they are discriminating on someone’s race or religion. If they don’t want a major vibe coded surface, do they even have to defend that? It’s part their “artistic” license as developers.
Or did we forget software inherently is opinionated
Given some posters on the GitHub issue, I get the sense some people feel their religion is being violated.
You don't even have to leave this site: when the original Bun rewrite posts were made, an incredible number of comments were focused, not on Bun, but on Jarred, who I'm assured is a complete rockstar and would never harm Bun.
Unfortunately, his followers don't realize that something like a batteries-included runtime is a huge commitment to build on top of, and governance you can trust matters as much, if not more, than the lines of code.
The way this has been handled is just baffling. A Rust rewrite is supposed to be a freebie for hype, and even an AI rewrite could have been interesting if approached more scientifically and transparently... but instead the opposite of that happened.
Yes, it’s actually similar to discriminating based on race or religion, in the sense that it’s an arbitrary, meaningless criterion to discriminate on. If the Rust Bun port is better in every measurable way — passes all tests, has the same performance or better, and fixes existing bugs — then who cares what language it’s written in or how it was implemented? The point is that it’s higher quality. If you don’t trust the Bun team when they release a Rust version and give it their stamp of approval, why did you trust them when they released the Zig version two weeks ago? It makes no logical sense, and it makes the yt-dlp devs look foolish.
> If you don’t trust the Bun team when they release a Rust version and give it their stamp of approval, why did you trust them when they released the Zig version two weeks ago?
I think you cannot make this comparison because Rust version wasn’t in fact written by the Bun team. It wasn’t even read by them.
Based on the comments I think a lot of people assume the headline pertains to Bun itself.
[deleted]
This stuff brings bad vibes.
exactly... and it's not like it's hard to fork and just raise the minimum version. It will probably be just one number somewhere (I haven't actually looked.)
if it works, it will keep working. they just don't want to support and maintain it and solve issues.
Oh well, I really like using Bun and I get kinda sad about the turn they are taking after the Anthropic acquisition. I really want a good Node with batteries included, but I don't want it vibe coded.
Have there been any significant issues caused by the vibecoded translation?
To be clear, I'm not implying support for the merge. I am against this whole YOLO approach to engineering. Just curious how the switch is going since I haven't seen any news since the merge announcement.
IMO the source of the new code is less important than the sheer volume of it. Bun does not need to be entirely rewritten; certainly not over a period of a week, possibly not even over a period of a year. Stability is hard-fought and battle-tested. Everyone has a plan until they get punched in the face; and every repository has passing tests until it runs production code.
How many lines of translated code would have been acceptable? What about before AI all the machine translated projects that people used for years without a single complaint? The person who did this was the lead for Bun from the get go no? So it stands to reason that they are one of the highest authorities in Bun itself.
What is the essence of a program?
The name? No.
The author? No.
The test suite? No, testing is hard and most projects don't do enough of it.
The code? Not really, code can be rewritten.
The history of the program being executed by its users? Ding ding ding. Yes, it's this one.
Bun no longer exists. What exists now is a program that has the potential to be Bun but at this time is not Bun because it has no history of being executed as Bun.
If the rewrite has been done piece-by-piece or over a longer time period then this history could have been built up over time. As such we will have to wait a while for Bun to exist again.
It's an competitor to bun at the moment, that's what happens when you rewrite a whole program.
Name being the same or not, it's what it is in reality (for better or worse)
> What about before AI all the machine translated projects that people used for years without a single complaint?
If by machine translation you mean something like transpiling, that's a technology that has been proven over decades, and the translators were written by hand with some attempt at formal correctness and guarantees. Translating with LLM is much newer and subject to the errors LLMs can create, such as hallucination. And I think a lot of people would still be nervous about translating an entire project of that many lines, even with the best pre-AI translators.
I agree, I'm just wondering whether the punches have come already. Honestly, the fact that they haven't is against my expectations, my guess was that we'd see a noisy one here a day after merging.
It's too early. It might be too early forever.
Epistemically: if it can be so easily vibecoded to rust, why can't it be vibecoded to be reparted? Isn't the great and Almight AI unable to parse and repair Zig? Identify it's weak points and route around it?
According to the bun team, it was already vibecoded for months before the Anthropic acquisition.
Probably a lie tbh
Why is it so hard to believe that Jarred Sumner, a self-described "Thiel Fellow and a high school dropout", had values aligned with Anthropic's before Bun was approached for acquisition? It's not like Claude was an asteroid that crashed into Eden.
Why dont you want it vibe coded? Does that make it worse?
Not necessarily, but I don't trust Anthropic in making sure it doesn't become worse. They are already doing a terrible job with their own Claude Code CLI.
Ah I see, yep agree with that 100%
I think it's hilarious how hopeful people were at the acquisition that Bun would be able to continue on mostly as it had been but then that all got completely thrown away and trashed.
(Hilarious in the way that's terribly sad, of course.)
It usually takes years for someone's values to be thrown out the window! How long was this one?
"It is difficult to get a man to understand something, when his salary depends upon his not understanding it"
changing your employer tends to accelerate that if the new employer has different values.
How has it been trashed? Does the Bun software not work anymore?
They literally threw out every line of code that existed before and rewrote it in a completely different language, seemingly on a whim. That's how it was trashed, in the very literal sense that all of the existing project was tossed in the trash in favor of a completely brand new code base. That's a big deal even if you ignore the coding agent aspects.
The worst part is that they basically didn't review the new code at all other than making sure it passes tests. We have no idea what could be lurking in the codebase now, and it's even all completely un-idiomatic, Zig-ish Rust.
> making sure it passes tests
Not even the same tests, as far as I can tell. That million-line PR touches a lot of test cases...
I swear they did this as a marketing ploy. To set the precedent that these large refactors are okay to do, and ingrain it in the engineering zeitgeist.
Kind of reminds me how Google starting putting on automatic AI processing of YouTube videos and shorts around the time of AI generated video and images. Their processing gave the videos artifacts that made them look more AI generated, making it harder to discern AI generated images, maybe to make demand for their watermark products.
>Does the Bun software not work anymore?
Nobody knows.
Unless specific issues have been identified that were introduced by it being "vibe coded", isn't a reaction to reject it outright without actually checking the ground truth just exhibiting the behavior you are criticizing?
It's just a trust issue. Have you seen the absolute state of the Claude Code CLI development? I don't want that to suddenly happen to Bun after I've already used it for production stuff.
I don't see any hypocrisy in the comment you are criticizing. The behavior they are criticizing appears to be vibe coding. How is rejecting something for being vibe coding "exhibiting the behavior" of vibe coding?
There’s a big difference between vibe coding and agentic engineering. If you think they are at all the same thing, you need to update your priors
You aren't allowed to dismiss vibe coded software based on the slop vibes. It must be well-researched and human reviewed in order to have an opinion.
The ground truth is that the new maintainers can’t possibly have a good understanding of the many millions of lines of vibe-translated code. Even assuming that the code happens to work okay in its current state, the lack of understanding means a high risk that its continuing maintenance won’t result in a satisfactory level of reliability.
Aren't the maintainers the same people? I haven't seen any talk of who's working on it changing drastically.
You want the yt-dlp authors to review the entire post-migration Bun codebase?
And what are you referring to as "behavior"?
Do you review your dependencies’ entire code?
Virtually no one reviews entire code bases of dependencies, what on earth are you talking about?
They reviewed it in the sense of integrating something that worked, this is something maybe not completely different but different enough to give pause.
No, would you use a proudly vibe-coded banking app?
How would you know it was out wasn’t vibe coded?
[deleted]
I'm not sure what "exhibiting the behavior you are criticizing" would even mean here.
BUT.
"Ignore anything but actual problems" is a terrible stance to take generally for software and dependency selection. Incidents are fairly sparse, process is much easier to observe. So if you can find connections between process and incident possibility, that's a very reasonable heuristic. And it's easy to find examples of overaggressive LLM usage introducing problems into software.
You are putting words in my mouth, I never said anything about such a stance.
The vast majority of new software is written using AI. The problem is not that it is written by AI, but rather than some people treat it like a black box. It is entirely possible to use AI to write code and verify that it is correct. Even Linus Torvalds is allowing AI generated code into the Linux kernel as long as it's managed properly.
>The vast majority of new software is written using AI. The problem is not that it is written by AI
How on earth does this follow? It's common, so it should be accepted without scrutiny?
>The problem is not that it is written by AI, but rather than some people treat it like a black box.
Yes, and guns don't kill people. Obviously the issue has two facets. It would be irrational to say "AI is flawless" or "humans are flawless".
Allowing genAI code does not imply blindly trusting genAI code.
>as long as it's managed properly.
Correct. Hence the issue. This was vibe-coding by even the strictest definitions of the term. Vibe-coding is, by definition, not "properly managed".
You are referring to black-box coding, not vibe-coding. There is no strong formal definition of that word. Is there evidence that they just fired off the LLMs and didn't review or test the new bun code?
The evidence that they didn't review it, is that a million line rewrite was merged 8 days after it began being written. It's simply not possible for a team that size to review that much code in that little time.
As far as testing - yes, they do have a test suite that it was checked against during the rewrite, but that still means that any behaviour that wasn't strictly tested for by that suite could have changed and it would still pass.
This is about the rust conversion but that has not been released.
> Due to foreseeable compatibility and security issues
Hmm, Zig bun crashes plenty.
I wish yt-dlp linked to detail on why there are foreseeable compatibility issues. Both projects have test suites, in an ideal world they would allow fast rewrites.
Maybe they want to limit inflaming the situation, but if they have spotted some specific issues it would be good to see.
I hope Bun.rs is 1.4 or even 2.0 and not a minor release, with some alpha/beta releases.
Yep, it's one thing if there was some project that saw severe regressions in Bun.rs and actually showed data about regressions.
But it's been available for a week. And so far, seems like crickets on actual data on any regressions. It's more "I just don't like this!" style grumbling.
This decision seems to based more in politics than engineering. Have you observed Bun have more segfaults, OOMs, etc, since the Rust rewrite? Have you noticed more security vulnerabilities? Have you seen more bugs? (Of course you haven't, the rewrite hasn't even landed yet.) It seems that you are making this decision because you get a bad feeling when thinking about AI involvement.
I don't select my engineering tools because they give me a bad feeling - I select them because they do the thing I want them to. If Bun starts having more bugs and feeling like worse software, I'll stop using it. But I will base that on data -- not a feeling I have. Jarred has done a lot of impressive stuff with Bun, and it seems unlikely he would ship this rewrite if it didn't meet his quality bar - I am willing to see him out here.
> Have you observed Bun have more segfaults, OOMs, etc, since the Rust rewrite? Have you noticed more security vulnerabilities? Have you seen more bugs? (Of course you haven't, the rewrite hasn't even landed yet.)
On the flip side it's not on the yt-dlp authors to test Bun's new development process and see if it results in more segfaults, OOMs, security vulnerabilities, etc. In fact it would arguably be negligent to experiment on your users if you thought there was a reasonable probability of increased security vulnerabilities.
I think there's a good argument that the responsible thing to say would be "we aren't going to immediately support running our software on a new bun release cut from main right now".
It seems a bit unfortunate to me that they've apparently already intending to never support future releases instead of planning on re-evaluating in the future. On the other hand the yt-dlp developers definitely don't owe anyone anything.
> It seems a bit unfortunate to me that they've apparently already intending to never support future releases instead of planning on re-evaluating in the future. On the other hand the yt-dlp developers definitely don't owe anyone anything.
I think your final comment gets at it. If they said "OK, I am skeptical, so we're going to pause on updating to see how this Rust thing plays out" -- that sounds like a reasonable engineering decision. Saying "because they vibe coded we are dropping support for Bun" sounds political.
Why is it "political" to say "I don't trust software fully written by an LLM that has not been vetted by a human"?
That feels like an entirely reasonable stance to take.
And I see the argument/correction downthread that it's an "emotional" or "ideological" stance. Why does it have to be that? It seems completely rational and logical not to trust software written by a technology that is known to hallucinate and "cheat" to make tests pass.
Of course, I can't say that the yt-dlp maintainer is or isn't being political/emotional/ideological when making this decision; none of us can know their true motivations without asking them, and I choose the charitable explanation unless shown evidence otherwise.
> Saying "because they vibe coded we are dropping support for Bun" sounds political.
I disagree that this is a political stance. People based on their experiences have formed opinions on whether they trust that model of development or not. Bun having taking extreme measure of going 100% in within a week is itself extreme positioning from their side which will likely result in extreme reactions because depending on who you are and your experience you'd bet on the fact that it may or may not work out.
I disagree as well, and wonder if the OP meant an emotional or ideological stance instead.
Yes - this is indeed what I meant, thanks.
In all sincerity, what does political even mean in this context? ELI5, I’m a toddler when it comes to the politics of AI/LLMs.
Its a polarizing world with AI. There are fanboys drinking the kool-aid blindly listening to whatever Sammy/Dario/... say as gospel, and on other side there are haters who again blindly reject the fact that these AI tools can be actually be useful. I think that's what the politics is.
Yes - exactly! I honestly thought I was going crazy when a bunch of people were saying that this decision wasn't political in the slightest.
I’m tracking the polarity of the whole movement, I didn’t understand how politics was attached. I desperately don’t want the whole thing to become a left vs right disaster. We have enough of those.
You might not like it but you actually live in a world with other people and building technology often affects their lives and they have opinions on it. For AI a lot of that impact has been negative.
I don't have the emotional energy to care, actually.
This is actually fascinating. How does my opinion matter? Should I join all the socials (this is my only form of social media) and stand on my soapbox and shout into the void? Do I need to express I care so others know I care and have picked a side and have opionions on evrything?
I do not care. My opinion does not matter. I can scream into all the voids. I can virtue signal until the heat death of the universe/until I die, it matters not. I don't have the desire to spend the limited emotional bandwidth on giving a flaming fuck about the world around me. I'm not that arrogant or self-centered to think anyone else cares.
Engineers not caring is what leads to people working for scumbags who build socially poisonous technology.
What if I told you I was a stay-at-home dad?
> Saying "because they vibe coded we are dropping support for Bun" sounds political.
I don't think "political" is necessarily a bad thing. Engaging in politics is how you shape the world. The mere act of writing and maintaining yt-dlp is quite political considering the context of IP law and enforcement that we live in.
It happens that in this case that I'd disagree with their politics if that's why they are dropping Bun support - I think there's a great deal of value in moving to memory safe languages, little harm in accepting anthropic compute and funding to do so, and that use LLMs themselves is roughly value neutral (though many uses are very much not value neutral). That said reasonable people definitely disagree with me.
vibe coding isn't a political topic lol
this amounts to "i don't trust this dependency anymore, so i'm cutting it out for my own good"
that's fine
That's not what I meant by political. I meant political in the more modern sense of "appealing to emotion rather than thought".
EDIT:
Everyone is rightfully calling me out that this doesn't make a lot of sense. What I meant is that the move is driven by ideology. I think there is a lot of overlap between politics and ideology, and an increasing amount of overlap between ideology and emotion. But it's fair enough to call me out here.
> I meant political in the more modern sense of "appealing to emotion rather than thought".
I'm not familiar with this definition in any modern or archaic sense. Is there somewhere I can read about it? Just because a decision is not directly engineering related (which I'm not even convinced this is) doesn't mean that it's not thoughtful.
That's fair - I updated my comment a little. What I mean is that the decision was driven by an ideological basis, not an empirical one. Bun was written with AI, AI doesn't fit with my ideology, therefore I reject it. As opposed to Bun has these new problems X Y and Z, therefore I reject it.
The irony of this comment on an app that is:
- free and open source, which is an ideology, and that
- expands access to otherwise locked down media, which is again an ideological stance
"Political" here means "I don't like it"
I can't see how this counts as "political" or "ideological" by your definition unless you believe that emotion can't exist as part of any decision, in which case you should give up interacting with human beings entirely.
Regardless, the decision was 99% logical. In fact, even the emotional parts are laudable. For example, I love software. That's an emotion. If you disagree with that foundation, we will fundamentally never be able to converse with each other about what's best for software.
The opposite of political would be someone saying "I have observed that Bun has X, Y and Z bugs -- therefore we are no longer support it". An example of this is the recent announcement that Ghostty is leaving GitHub[1]. Compare and contrast the rationale:
> I've felt this way for a long time, but for the past month I've kept a journal where I put an "X" next to every date where a GitHub outage has negatively impacted my ability to work2. Almost every day has an X. On the day I am writing this post, I've been unable to do any PR review for ~2 hours because there is a GitHub Actions outage3. This is no longer a place for serious work if it just blocks you out for hours per day, every day.
That isn't ideological in the slightest. Count the X's, and move off once you see too many.
But unless you're doing that for every service you use (and not just the ones that annoy you), that's still the same logic. Deciding to count something is just as "political" (as you put it) as choosing to not count something.
Whole OSS is driven by ideology. It does not exiat without ideology. And not just that, whole massive development companies are driven by ideologies.
OpenAI itself is a bundle of ideologies and pretend ideologies. Thw whole puah for AI and AIG is way more about emotions and ideology then about business ir engineering.
Wait, expecting all code to be verified and tested by a human is not engineering-driven but instead emotion-driven mindset???
What code is fully, or even primarily, tested by a human? Haven't you heard of automated testing suites, regression testing, conformance testing..?
Test code written by a human counts as "tested by a human". Also, most code is literally tested (manually) by humans in addition to automated tests. You are being pointlessly pedantic.
Bun has a test suite of tens of thousands of tests. For purely non-functional changes, like refactors or rewrites (e.g. a Rust rewrite) I rely primarily on test suites, not manual testing, in order to ensure that nothing regressed. I mean, sure, I am going to poke around, too, but the test suite is the encoding of thousands of obscure bugs and issues over years. There is no way my manual testing will be able to cover the same ground.
[deleted]
> Test code written by a human counts as "tested by a human".
Were Bun's tests generated by an LLM? If they were, were they read by a human afterwards to be validated?
Publicly based on my calculations[1] there only ~20k tests. I would say they are usual tests for the runtime. Constantly running on the CI much lesser amount. Average test count/line of code ratio drops after rewrite. And even before Node have denser tests count/LOC ratio
If I were to mirror your tone, I'd ask you if you've ever heard of the basic courtesy of running your code manually yourself before you waste anyone else's time with it... Or whether you've heard about QA, or about making demos for Product or for customers...
Neither of these can be replaced by an automated test suite of any kind, and all of these are examples of good engineering practices that guarantee software quality.
Additionally, even if you don't (need to) adhere to the best engineering practices and instead rely solely on an automated test suite, the tests in this suite must be validated - read and understood - by a human in order to guarantee that they nail down the correct requirements.
[flagged]
That has nothing to do with what "politics" means but it's exactly how people have started using "political" to mean "idea I don't agree with".
I think there is a lot of overlap between politics and ideology, and an increasing amount of overlap between ideology and emotion.
I think it's fair to call me out for skipping a step, but I wasn't using it to mean "idea I don't agree with".
>I wasn't using it to mean "idea I don't agree with".
I believe, maliciously or innocently, you were.
> I think there is a lot of overlap between politics and ideology
What is politics without ideology?
Power struggle. Lying about manager from other team so that you look better. That sort of thing is regularly called politics.
In software engineering the word has also long meant "a decision not made purely on technical terms"
Humans have always appealed to emotion - as part of their logical process.
Fear (emotion) is used (advantageously) to force us to check that something isn't going to break us
In this instance fear is being used to ensure that yt-dlp is not exposed to (genuine) concerns about the quality of bun that is openly being built making use of tools we as a whole know is problematic.
I agree with you that the statements are a bit over the top (that's an emotional response to their statements btw) and that (eventually) you would /hope/ that bun gets to a point where it's got some genuine reliability from a users perspective.
Edit: I see your edit to explain that the issue is ideology - but unfortunately (perhaps) that's not an improved stance - ideology has to guide us when we just don't know - it's a heuristic.
That's a perfectly cromulent meaning of the word.
Vibe-coded code is a code no human has written, so no human truly understands how it works. It's a perfectly reasonable technical decision not to support such software, especially if actual human effoft is required for that
I wouldn't have problems with AI-generated code, but LLMs are not AIs, they are random sentence generators. They don't have logic, yet programs are logical constructs. So let's call this what it is: randomly-generated code, kinda sorta filtered by humans and tests. It's not because the output distribution has a good match with the expected distribution that it's not random. An LLM that is "hallucinating" is still working perfectly well and isn't doing anything different, in the same way that a straight-line fit through data points isn't "hallucinating" where it isn't overlapping the data points exactly.
> I wouldn't have problems with AI-generated code, but LLMs are not AIs, they are random sentence generators.
AI includes a lot of technologies, LLMs being just one of them. Several of these technologies use probabilistic algorithms, so having randomness does not disqualify something from being classified as AI.
And I didn't say it does. Intelligence is not necessarily deterministic, and being random is not the problem with LLMs. The problem is that they are not intelligent: they statistically mimic reasoning and logic, which still could have been acceptable except that they don't generalize well and have double-digit (at best single-digit) error rate percentages.
They also have the worst possible failure mode imaginable: Producing erroneous output that looks perfectly fine and expertly-crafted.
Imagine a food synthesizer machine. You press a button. 80% of the time you get a chicken sandwich, 20% of the time it beeps an error. That's OK. With the LLM version of that, 80% of the time you get a sandwich, 20% of the time you get what looks like a perfect sandwich except that it contains bits of plastic and metal, and you have to start eating it to find the pieces.
"You're absolutely right! Food shouldn't contain bits of plastic. Let me synthesize that again."
I wouldn't say it's random. But I do like referring to them as statistical code generators.
I'm repeating a point I made in a sub-thread but please WHY should the onus be on yt-dlp to review their decision on a project that has zero commitment to review their very code?
I get the idea to "battle-test" the rewrite first but (a) how does one even determine a reasonable timeframe for battle-testing that much LOC and (b) each vibe-coded update pushed to the Bun upstream basically resets the battle-testing timer. I guess you could lag behind $LATEST by a given window but that just brings us back to (a).
Adding support again later is cheap.
Stopping maintaining and testing support for upcoming versions is cheaper than doing that work.
Sure it’s political but it is also just a sane approach, to stay away from such disruptive change and treat it as wait-and-see instead of tagging along for the ride. There is not really any technical upside to tagging along and promising support.
> Stopping maintaining and testing support for upcoming versions is cheaper than doing that work.
If it’s based on predictions of how some alpha software might turn out in the future then I don’t see how you can claim it’s cheaper.
If a bunch of new bug reports came in then you said no, then everyone would understand.
This is pretty obviously ideological otherwise. Which is fine, but we shouldn’t pretend otherwise because we might agree with it
I think it's perfectly rational to take a wait-and-see approach when a dependency has been completely rewritten from scratch.
That would still be rational if it had been rewritten by hand, and not by an LLM.
This isn't a wait and see approach, this is proactively removing it
It's "we support 4 JS backends, we don't have the capacity to support 5 currently". They're not dropping bun entirely, instead bumping the minimum bun version and not supporting "bunv2" because they don't want to be beta testers.
Has the team announced that they're breaking backwards compatibility, or that testing will be reduced?
I disagree it's a political stance, this reads like a technical decision to me. In my opinion, there is no vibe-coded project that's going to be reliable long term. Eventually there's too much code, too many bugs and the whole things slows to a halt. Or it gets too expensive to continue to be vibe-coded, because token cost.
If they had decided to drop Bun for "AI assisted coding," that might strike me as a political decision.
What does "political" mean in this context? To me it seems obvious that yes, that is a political choice, as is every other choice a group of people make for themselves together.
That wasn't my read, though. I think if they don't want to go with the vibe-coded version then they have to go with the last release before that. And presumably that last release won't be updated (except with the vibe-coded version). Therefore it makes sense to deprecate.
What's wrong with yt-dlp - an app almost entirety driven by political stances - taking another one regarding llms?
“Vibe coded” means “human programmers did not review the code”. So I think that’s an entirely reasonable line to draw that’s no more political than dropping support for some other project that suddenly decided to drop all unit testing or to refuse to do any security vetting.
> It seems a bit unfortunate to me that they've apparently already intending to never support future releases instead of planning on re-evaluating in the future. On the other hand the yt-dlp developers definitely don't owe anyone anything.
The other side of this is that as far as I'm aware, Bun support in yt-dlp was always experimental. They mainly use Deno.
It's not really political. Or let me rephrase possibly yt-dl is being political. VUT the concept of 'not adopting a core dependency until it has been widely used in production for 6 months - a year.', is not a political on general. A full rewrite of 1 million loc is essentially a new runtime that has the same ABI as the previous and for many downstream consumers it's not something they are comfortable taking a production dependency on. If for sale of argument BUn was fully rewritten by hand would be the same situation. I personally think this kind of decision is pretty standard, I also personally think the Bun LLM rewrite will be of good quality overall, but I certainly would not bet my product/company on it. I want to be the one making the risky changes on my software not being forced into it by downstream deps.
I think your stance is more reasonable than the one in the article, TBH. If yt-dlp said something like "We're going to wait 6 months on the Rust rewrite", that would be reasonable. But instead it says something more like we think that Bun is vibe-coded, so we don't want to use it any more. That seems less reasonable.
It's not less reasonable. They don't have to promise giving Bun time in the future to evaluate. They might do it but they absolutely don't have to be responsible for doing it when the project made such dramatic shift.
They can do absolutely what they want with their project especially when its majority decision. There can't be no doubt about that.
They can absolutely do what they want, and I can absolutely say it's an unreasonable decision. When I say "unreasonable", I am evaluating whether they are operating on sound technical principles or not - not like, "are they allowed to do this" or something more obviously true.
Why is it unreasonable, from a technical standpoint, to avoid vibe-coded software?
To me, proving a vibe-coded piece of software is fit for purpose is much more difficult than if it is human-written, or LLM-assisted with a human reviewing all the generated code.
Welp, I mean once the Rust rewrite is merged, isn't it vibecoded? Fair enough, it was vibecoded from a pretty detailed Zig specification :)
I think it's fine to not depend on code that nobody, even the maintainers, has read. Is that really controversial?
I do find it ironic you think this project is making rash decisions on no technical merit, and not Bun
> A full rewrite of 1 million loc is essentially a new runtime
It's not a rewrite exactly. Nobody wrote anything. Not a single human has even seen, much less understood those 1m lines.
Who or what does the writing doesn’t determine whether it was a rewrite. It was definitely a rewrite. Maybe it was 100% automated. But it’s a rewrite.
Even re-written by hand isn't the same because a hand re-write proceeds slower over a longer period of time with more smaller updates that get tested somewhat along the way.
Also I don't think it's wrong to use an action as an input to judging engineering character. That could be read as judging yt-dlp or judging bun but in this case I mean it's reasonable to judge bun's developers.
IDK if i'd personally judge this action quite so badly though. It depends how they went about it and what they proffessed to get out of it.
I am very much against letting llms think and decide for you, but I don't think it's so wrong for an actual coder to employ automation.
But if they are acting like it's magic and everything will be so much better after the magic llm uses the magic safe language... yeah that definitely gets the side eye. Or no eye. Just no longer interested in or concerned with their output.
Since this is being offered as the next release version while still being new and stuffed with unsafe, looks like it's the latter. So I'm with yt-dlp in this case.
It doesn't matter if the new code happens to be ok or not, it's still a problem that they got there by hoping a black box does the right thing. A black box that that no one wrote and no one understands, not just themselves.
gcc is a black box to me, but I know that someone wrote it and understands it (or some people collectively understand all it's parts), and I know that any time I want, I can choose to understand any part of it, and satisfy myself that it is doing something both sane and deterministic.
So a developer choosing to use gcc when it's a black box to them does not reflect badly on them to me.
But no one can say that about any llm or ai. So yeah, a developer choosing to use them, depending on exactly how, may reflect badly on them.
The same was true for cheap off-shore gig coding by humans too. I have tried to use them myself in the past, hire out for small generic programming jobs using those web sites where you put up some escrow money and post a job and people bid for it, you choose one, they do it and get paid from the escrow. I only tried about 3 times for the same small job and every time I git ridiculously shit (but technically functional) results.
These were humans 15-20 years ago, no possibility of hidden ai usage like today, and it's essentially the same dynamic of just hoping some magic will get you something good for cheap, and accepting any result that appears good as good.
If someone said that that's how they made their product, I would decide that product is probably pretty crap inside and no way should I buy it or invest in it as a dependency if I have any choice.
And that's humans not ai. The problem isn't really the ai, it's the judgement to use an ai that way.
Every accusation is an admission, isn't it? As always with these cases, the rhetorical contrast is staggering compared to the thread about Bun deprecating Zig.
Bun made a snap decision to merge 1M lines of unreviewed code within a week, including code generated moments before the merge. AI or not, that forces downstream users to cope with total unpredictability. This process bears no resemblance to science or engineering.
All the QA work you're demanding of yt-dlp is work Bun should've done. Trying to flip that responsibility proves your argument isn't grounded in engineering principles. And you sure made your feelings known in your comments for someone who claims not to let emotions affect technical decisions.
yt-dlp made a sane technical decision to drop a high-risk dependency. Not only is the Bun code now unpredictable, but the maintainer is too. The maintainer called the rewrite "experimental," then merged it within a week. If direct statements can flip overnight without warning or explanation, it's no wonder downstream projects want out. Especially when yt-dlp already supports alternative JS runtimes.
If you wait for more segfaults, OOMs and other issues, than you have failed to avoid the problem. In my opinion this direction is correct and history will show who's right.
When expressed, sounds like a trivial principle. It's surprising how rare it is to see people actually do this.
Not only with tech stack: choosing cars, laptops, staying in a toxic relation, the list goes on
Notably, they aren't (yet) dropping support for older, pre-rewrite versions of Bun. They also could be leaving the door open to support Bun in the future, if the rewrite proves successful. I think waiting and seeing is the right, conservative move.
If that was how it was phrased I think there would have been less push back, but that's not at all how it's been communicated.
There is no assumption to rereview at a later date at all given the focus on the AI usage etc.
If they said we will rereview in 1-6 months or whatever the whole discussion would be mute.
Why should yt-dlp commit to review their decision in the future about a project that makes no commitment (that I've seen) on reviewing their source code?
I get the idea to "battle-test" the rewrite first but (a) how does one even determine a reasonable timeframe for battle-testing that much LOC and (b) each vibe-coded update pushed to the Bun upstream basically resets the battle-testing timer. I guess you could lag behind $LATEST by a given window but that just brings us back to (a).
Given that part of their announcement is to keep supporting pre-rewrite versions of Bun, it implies to me that they are open to reconsider if the Bun team cleans up their act. I don't think it could get any more reasonable than that.
> This decision seems to based more in politics than engineering.
Project governance is very important on a project; the fact that Bun's authors bent the knee to their new owner shows where their priorities lie.
> Have you observed Bun have more segfaults, OOMs, etc, since the Rust rewrite? Have you noticed more security vulnerabilities? Have you seen more bugs?
I - them - are not going to sit around waiting for bugs to start crashing everything
> I don't select my engineering tools because they give me a bad feeling - I select them because they do the thing I want them to
Good thing that you don't run an open source project then, I would remove anyone's project from my dependencies who thinks like that.
It really is amazing to me how many developers do not understand that governance is important. If I have a dependency and a maintainer of that dependency has a process I can’t trust, it’s perfectly valid to remove that dependency based on that lack of trust.
Not caring about governance is how we end up with repeated supply chain attacks.
Reading and understanding code is more difficult than writing code.
It is significantly easier to modify code that you personally wrote, or code that you have read and understood to fix an issue in previously. This is why the maintainers of a project change slowly over time and it takes a long time for new ones to get up to speed.
All of Bun has been rewritten by a tool. In a different language that maintainers may not be fully proficient in.
Even though the rewrite was done well, and even if we assume it's functionally equivalent to the old Zig code, there will still be future issues. And ALl of the maintainers are essentially now new hires who have never seen that code in their lives.
It's not "politics" to have an ounce of sense to foresee problems in such a project as a dependency.
A key element of engineering is projecting a current trajectory. Given that, it absolutely makes sense to avoid tools that give you a bad feeling. The easiest time to move away from a tool that will become a train wreck is before you've integrated it.
But what exactly are you projecting? Typically when people have said they have a bad feeling about something (imagine Next.js) it's because they are running into more bugs or they are seeing more production incidents. In this case there has been no chance to observe these things.
Bun in its current state absolutely has issues like segfaults. As nice as it is, I moved off of it back to node for production.
Folks generally tolerate issues if they believe they’ll get better with time. I know I did for a while. If that confidence collapses, that’s not politics.
But there's no evidence of that in the post. If they had said something like "Bun had bugs X, Y and Z - this Rust thing is the last straw, it's over" -- that would be a reasonable decision, and no one could really complain. But they didn't say that. They just said it "seems like a future headache".
Are we reading the same post? They literally point to bugs X and Y.
I don't see politics, I see frustrated maintainers of a hobby project that aren't particularly professional.
Engineering decisions and the resulting output.
We've known for decades that machine-translated code is garbage, and should only be done as a last resort.
Your HN account is too new for me to be sure whether you're being sarcastic or not. Perhaps you know, or perhaps you don't, that all code is machine-translated, even assembly language. None of it is perfect, but it's not garbage. Today's AI merely provides a new level. It's a weird, non-deterministic level, but hiring an employee to write code for you is similarly non-deterministic.
Right, and that's why Mel was a true programmer!
Seriously though, that's an overly-pedantic definition of a compiler. Broadly speaking, languages compile in a direction of decreasing abstraction. Crossing from one high-level abstraction to another is just asking for trouble, especially in this case where the target language makes very specific performance promises as long as certain abstractions are maintained.
It's 1mloc that no human has seen. There is no possibility for that project to be reliable, at least initially.
“You're absolutely right! I've seen things you humans wouldn't believe.”—Claude Opus 4.7
Then Bun's rewrite is also political. They couldn't upstream their vibe coded "improvements" so in spite they decided to vibe a rewrite in Rust. The arguments for the rewrite were not backed by any data.
> They couldn't upstream their vibe coded "improvements"
What are you talking about? There is no upstream rejecting contributions here. It's the original bun developers who vibe-ported it to rust and they absolutely could and did upstream their vibe coded changes because they are the upstream.
they're referring to the changes they tried to upstream to zig.
To be fair, I don't know if the Bun team ever did try to upstream it. In their Twitter thread announcing their vibe-coded fork of the Zig compiler, they said they wouldn't bother trying to upstream their changes because of Zig's policy banning LLM-authored contributions. Still probably a calculated political move to cut ties with Zig and muster community support for a Rust rewrite. https://x.com/bunjavascript/status/2048428104893542781
They did try upstreaming to Zig, but it was rejected for already being implemented not because it was vide coded.
Bun were so excited about their 4x speed improvement that they missed that Zig had already implemented it, plus other optimisations that were far larger.
The changes submitted to zig were rejected because they were off an old fork and had already been implemented.
They may have been rejected for being vibe coded if they were original, but they were rejected for being pointless. The rust rewrite was because Bun was butt hurt that they didn't actually help.
[deleted]
Every single macOS update the top comments are about giving it six months to stabilize, but when a program’s biggest ever rewrite involves a lot of AI, the top comment is calling you irrational if you don’t YOLO it, and probably a jerk, too.
I didn't say you were irrational or a jerk.
But this also isn't a fair comparison. The article doesn't say "let's wait 6 months", it says they are fully deprecating Bun. Those are two very different statements. I would have had no issue with the first.
And FWIW I think my viewpoint is the uncommon one. Look at all the responses to a previous thread about it [1] and see how many of them are negative. It's certainly a majority.
I don't know if your viewpoint is uncommon or if the vibe-coding hating crowd is just louder.
YOLO? Bun has an extensive test suite and this implementation passed the test suite.
Can we at least try to be a bit more accurate and less hyperbolic?
I will continue to use Bun because the same people that made bun have made this decision. I trusted them one week ago. I have used bun for the past 2 years, and so have many others.
I'm not about to just assume they've become immature idiots yolo'ing stuff overnight. They're still the same people they were a week ago. Or two weeks ago.
Program testing can be used to show the presence of bugs, but never to show their absence! Dijkstra (1970) "Notes On Structured Programming"
LLM generated code is garbage, not because it writes obvious errors. But because it lacks any kind of reasoning - Claude will gladly write you a solution for a problem you never had. Good luck fixing these kind of issues that will never be catched by tests.
>> same people that made bun have made this decision
Are they the same people though? Their interests, goals, environment, incentives, boss etc etc all changed after they got acquired by Anthropic. Its not uncommon for a big company to acquire a smaller one and completely destroy that product to serve the parent company's goal.
You can go read all the details on Jarred's X account - including the progress, how it was thought out, strategy, that they're aware that it looks like zig still, etc etc etc.
Speaking of environment though, everyone neglects to mention that the Bun core team now has access to Claude Mythos. You think they haven't already run Mythos against this? So they have private access to the best cybersecurity scanner known to man.
Suffice to say, I'm yet to see anything that really worries me in any major way with this.
I've read the details, strategy, extensive test suite etc. I'm sorry, I don't think "they have access to Claude Mythos" is the rationale to it unless you truly believe the marketing 100%.
I think we'll just see how it all turns out. Maybe check back in a year or two on hwo it all goes. Anyone who says they "know" or are "very sure" this is the right path or wrong path is plain stupid IMO. Having seen how things work in big companies with high market visibility, I believe there is non-trivial chance this driven mostly as marketting stunt (particularly in current climate) and decision isn't purely based on best interest of Bun's future and longevity.
jarred two weeks ago: "we're probably not going to merge any of this"
jarred a few days ago: "bun has been rewritten in rust"
thought out?
> YOLO? Bun has an extensive test suite and this implementation passed the test suite.
I'm sure macOS has an extensive test suite that Apple runs as well, and yet still people suggest waiting a bit before adopting a new macOS release.
An extensive test suite can prove that you have regressions when you change the code, by showing you one or more newly-failing tests. However, it cannot prove that you don't have any regressions; it can only increase your confidence somewhat.
Presumably MacOS has an extensive test suite that it is passing before each disastrous release. Tests matter, but they aren’t the entire story.
> this implementation passed the test suite
Didn't they also change the tests to make the re-write pass?
They did, but they also reverted most of those changes.
I don't think refactoring 1M lines of code into another language within 7 days and merging it to master is responsible. I won't make my code depend on it.
It's not refactoring. It's LLM transpiled.
I think the correct term is *translopped*
[dead]
FYI in case you aren't aware, the rewrite was shipped, and then had to be reverted due to issues being discovered. That's "Jarred's high quality bar" you're so confident in.
The whole point of having canary builds is that they're unstable. That's why they're called canary. Rockets failing in test flights isn't a bad thing.
It absolutely is a bad thing. That's why so much effort goes into designing and manufacturing rockets correctly. So the tests go well and you can move onto actual launches. Using that as a metaphor for canary builds displays a lack of knowledge in just multiple areas lol.
[flagged]
It is a bad thing. It is good that the rocket doesn't fail during the test flight.
> Rockets failing in test flights isn't a bad thing.
I hate to be pedantic but for a whole host of environmental reasons, they are suboptimal, and it still incinerates money to lose a rocket during a flight test.
Yes, building rockets costs money and is bad for environments.
Yes, exactly this. SpaceX are super environmentally irresponsible, I wish they would follow the ESA/NASA development model that is so much better for the environment! So European.
Can you link me a source that says that the rewrite shipped to a point release (not canary)? I'm not seeing this.
News to me… share a link?
[deleted]
Every decision is made with imperfect information about the tool, its future, and your current/future needs. This is a normal type of engineering decision.
Bun being replaced entirely with stochastically generated code is red flag (regardless of whether it was or not). But Bun was also acquired by a huge corporation, which has been classically a huge red flag. Both of these are plenty of reason for yt-dlp not to support Bun.
In either case, this seems like a niche use case. I've used yt-dlp for years and I've never used Bun with it. If Anthropic really wants their recent acquisition to be supported in yt-dlp, it can fork it and support it itself.
> I don't select my engineering tools because they give me a bad feeling - I select them because they do the thing I want them to.
With that in mind, is there anything that yt-dlp uses the Bun runtime for which it can not use the other supported runtimes for? Similarly, perhaps the yt-dlp maintainers shouldn't keep supporting Bun just because it gives them a good feeling when every runtime incurs a maintenance cost.
That said, as a developer I skim over so much bullshit simply based on "bad feelings". I don't have time to evaluate every potentially useful technology in terms of whether it does what I want it to do, and no one else does either. It's clear to me that Bun is in an experimental phase of development and I think that's a good enough reason to move on if your use case is not.
“... it seems unlikely he would ship this rewrite if it didn’t meet his quality bar” is every bit as vibes-based as the decision you are critiquing.
Jared has shipped a lot of things that have impressed me. His software is measurably faster than the alternatives, and I have measured it. It runs code that Node et al can't run, and I have tried. These are normal, everyday experiences with software - based in fact, not vibes. I'm not going to argue every decision he's ever made is amazing, but his decisions have historically tracked above average.
He plays around with a toy project in a separate branch, tells everybody to relax that's just an experiment that has no chance of being merged, then abruptly merges 1m lines of code not seen by a human, effectively zeroing out all the contributions ever made by anyone to bun, including contributions in progress.
At the same time, his arguments in favor of Rust are sound, there is no doubt about that.
>that's just an experiment that has no chance of being merged
If we're gonna fight, lets go xbox vs playstation. Javscript runtimes are a snoozefest.
Stating e.g. "Bun is more performant than Node [along a particular benchmark]" is not a fanboy statement. It's a statement of measurable fact.
[deleted]
> it seems unlikely he would ship this rewrite if it didn't meet his quality bar
What happened to
> don't select my engineering tools because they give me a bad feeling
Who cares if you have a good feeling about this dude? There are obvious and clear conflicts of interest at play here. If you care at all about quality, you'll wait before adopting new releases until bugs get discovered/ironed out. Don't adopt based on some dude's reputation when that reputation was built under a very different incentive environment.
Why wait?
Seems reasonable to preemptively drop support and let someone else either suffer the fallout, or get proven wrong and just pick up support again. It's not for a lack of people motivated by IA. Unless the motivation is more "use my IA generated content" than "actually consume IA generated content", of course.
Not sure what seems "political" about this.
When deciding to support a given thing, you have to make a determination as to whether it's worth the effort or not.
You don't simply ignore unknowns. That effectively means assigning the unknowns zero cost, which is unlikely to turn out to be true. Generally, the more unknowns, the higher the risk, and the higher the risk, the higher the estimated cost.
There are a lot of unknowns about vibe bun right now.
One effective strategy for dealing with unknowns is to turn them into knowns if you can. Here, that probably means waiting to see how vibe bun turns out.
If it turns out to be stable and highly compatible, at some point in the future, they can always pick up support then.
> I don't select my engineering tools because they give me a bad feeling - I select them because they do the thing I want them to. If Bun starts having more bugs and feeling like worse software, I'll stop using it. But I will base that on data -- not a feeling I have.
being reactive is fine if you can tolerate issues. otherwise, you need to be proactive -- don't wait for the train to hit you before you move off the tracks
I wouldn't call it politics. I've seen enough people aim a gun at their foot and pull the trigger. They'll never thank you for stopping them, they just want to be left alone while they do it.
So, great, if this dude wants to regress through the workforce to a level of engineering maturity I associate with a high school student, I don't wish to try to be the one to stop him. Doesn't mean I'm gonna follow him. It's possible to be smart enough to just not walk into the tarpit. He's going in, I'm not.
You can’t really tell if you got sick from dirty hands, a week old egg, or the cheeseburger you had for lunch, but if Shake Shack had also just announced they’ve moved over to vibe-cleaning their kitchens then it’s reasonable to only eat at Five Guys from now on. Let someone else iron out the kinks.
Anyone who merges such a huge PR of ai generated code doesn’t deserve trust. This is a real black box now, even for the developer himself.
It is entirely rational to not use a completely new library no one yet confirmed is good. And complete agentic rewrite makes it completely new thing.
The argument that you somehow cant unless you go through trouble of testing it is way more "politics" and way less "engineering".
What world do you live in where selecting your dependencies doesn't involve personal judgment calls?
Those judgement calls are driven by things like “oh this is too slow” or “oh this API is a mess”.
> This decision seems to based more in politics than engineering.
Will you use untrustworthy dependencies in your project, which has users? I think, no.
I don't know, but I feel that this is the case with yt-dlp.
And this is absolutely engineering - care about quality and security of your software, which is used by thousands of people
a vibecoded rewrite right after being acquired is not political?
Is it so unthinkable to people on "hacker" news that someone might want to try a cool experiment like rewriting an entire repo into Rust?
Is it so unthinkable that people don’t want to participate in that cool experiment?
Most commenters here don't have an issue with Rust.
The 1M lines of code refactor by AI in a week or so then thrown into a production codebase... Yeah
Cool experiment? true
Cool production? false
[deleted]
No one says that? Of course Bun rewrite is political. And if you deprecate Bun support due to they did something political, obviously this decision itself is political too.
the bun team has recently demonstrated a lack of agency over their project. making massive structural changes with unclear and misleading communication. There is nothing political about seeing that as a red flag and deciding to rely on more stable projects.
> This decision seems to based more in politics than engineering.
I'm glad some engineers realize that technology is inseparable from politics. It always has been. All evil came from engineers who beleived they were above politics. Selecting the tool which got the job done/made the number go up/paid a paycheck is how we got Facebook, Google, Palantir, crypto, AI, techno-fascism and neo-feudalism. None of it would've have happened without engineers blindly applying their knowledge to achieve "purely" technical results, while ignoring the social consequences. With the hindsight of the last 20 years, anyone who still advocates for an irresponsible adoption of technology should be considered automatically suspect
> I don't select my engineering tools because they give me a bad feeling - I select them because they do the thing I want them to
Among tools that meet a technical expectation—especially for (often) superfluous activities like downloading videos—I pick one that feels right and costs the right amount, and that's the one that wins. Free + works + usable is an unbeatable combination.
However, I'd argue their decision is related to a peer dependency than it is itself one about an engineering tool, which is an assessment of the risk surface and potential cost associated with doing so. I already wasn't using bun at all, but if they stopped supporting whichever runtime I do use, I can either adapt or stop using yt-dlp, which I won't because this isn't a technical thing worth wasting much time on. This mild, recent change to recently introduced peer dependency integration is largely inconsequential, and I support the call to not waste time providing extra support if it hypothetically became necessary.
I would argue the opposite. The decision to rewrite was based on politics, and the decision to deprecate support was based on actual engineering.
You may not want to take part in politics, but politics wants to take a part in you.
>I don't select my engineering tools because they give me a bad feeling
But you do select your engineering tools on faith apparently.
> I select them because they do the thing I want them to.
Regardless of the other aspects, this is a joke in any context I have been in since I started working in this field about 9 years ago.
Even as pure logic, you know they do what you want it to do only after you chose them. You can’t possibly be trying every option to the fullest capacity of your application.
You also converge on the “Jarred” aspect and the guy that made the decision in the title post has the opposite sentiment
> I don't select my engineering tools because they give me a bad feeling.
Those bad feelings are often your years of experience trying to tell you something.
I have no idea how that’s what you get from this. I don’t want my project using any tech that decides to take 6 days to rewrite the entire library with AI. That is at its core an engineering decision.
No healthy engineering team is going to do that. And I’d want to distance myself as far as I could from a project that behaves like that.
> Have you observed Bun have more segfaults, OOMs, etc, since the Rust rewrite? Have you noticed more security vulnerabilities? Have you seen more bugs? (Of course you haven't, the rewrite hasn't even landed yet.)
Your argument could go other way too. Why haven't they landed if they're so confident with the change?
The first sentence on the linked page is literally:
"Due to foreseeable compatibility and security issues"
> I don't select my engineering tools because they give me a bad feeling
I do, for example when I see constant behavior of lying, or negligence for security issues or not considering valid PRs and rewriting it to fit their paid plan and so on.
> I select them because they do the thing I want them to.
This is one of the dimensions when I pick the tools, I know Oracle produces nice products, but I don't want to get sued if I do something accidentally their lawyers dislike.
So, let's see here. Here we have a program, that is used to install scripts from source that has been targeted, and breached multiple times last few months, can run arbitrary code on millions or billions of user computer, servers. And, it was ported to another programming language, resulting in 1m LOC, in 7 days for publicity stunt of a LLM company
Even multiple people can not go through 1m lines of code for any kind of vulnerability in 7 days, let alone 'observe' more segfaults, OOMS, unsafe behavior, on who knows how many possible ways things can go wrong in this new condition.
Only guaranty is 99% tests passed, and the engineer who is paid by the same LLM company.
How in the world, any sane engineer would agree, this would be remotely a good idea to continue using this tool, for a chance that such a expensive change won't actually land in production?
Everything is politics, sorry to say. Even software engineering try as we might.
> feeling like worse software
Politics ;)
As far as I'm concerned Bun has been extremely irresponsible with this entire rewrite, and it calls into question their entire development philosophy. Any project that cares about stability and reliability should steer clear of Bun for a while.
> I will base that on data -- not a feeling I have.
and yet...
> If Bun starts having more bugs and feeling like worse software, I'll stop using it.
Is it not possible to judge that certain approach is more likely to bring unforseen controlable problems than another by analyzing how it works without assessing it's output? No "feeling" is needed
[deleted]
I believe you contradicted your first point by following it with "If Bun starts having more bugs and feeling like worse software"
...so you do use feelings in your calculation? To be clear, I have no problem with that and think there is some level of speculation you need to do when deciding what to rely on.
As a hypothetical, pretend that Bun added obfuscated binary blobs that get executed at build time. Well, your code still works and no effects show up at runtime. Are you going to keep using it or dump it based on the "feeling" that something isn't right?
Bug counts are numbers. Memory usage and performance are numbers. Eventually those numbers get so bad that you leave.
Well if you promise support you promise support.
You cannot take back a promise after you make it. So if you discover bugs later you cannot just leave.
This script is just a JavaScript helper to bring full YouTube support to some media download tool. It does not seem important to anyone that executing it using Bun is supported. They support the Deno and Node runtimes.
The rust rewrite isn’t even out of canary IIUC.
Isn't that what Bun/Anthropic did? A rewrite based on vibes?
Except "because we can" and the expectation that some kind of bug will be reduced and other metrics will not get worse
All Bun devs are happy to change programming language?
When their competition is already in rust and more mature
While using the LLM that is now paying their salaries. Kind of a conflict of interest
Even a major version upgrade is enough for me not to touch it for 6 months, let alone a full rewrite
Has Bun posted any analysis and shown the data?
> Has Bun posted any analysis and shown the data?
Jarred promised a blog post just like he promised to not merge the slop branch.
[deleted]
absolutely, and `its development seems to have taken a turn towards being fully vibe-coded` ungrounded claim confirms the hysteria, I'm afraid
The whole code base is a vibe coded rewrite, half a year after Bun was acquired by Anthropic.
I see lots of ground for that claim.
I apologize, may I ask you, do you use Bun? If yes, you probably do monitor the development of this project (I do, it sounds reasonable to track your tools/deps), probably familiar with Jared's coding style, decision making process, architecture nuances, previous choices? Do you have any issues opened/closed in Bun's repo? Were you satisfied with contributors' reaction? Do you feel you can trust devteam behind Bun?
I get it if you're trying to defend your buddy, but at the end of the day it's on software to justify itself to me. Not for me (or parent poster) to justify their refusal.
Once bitten twice shy, y'know. Maybe the first bite wasn't even from bun. If bun can't take this on the chin and come back stronger, maybe bun wasn't a good choice to begin with. I'm sure a future version of bun with a rebuilt reputation will have an easy time getting re-adopted by most projects that needed to play it safe during the transition.
There is no evidence that it was "vibe" coded. It was ported to Rust by an expert engineer using an AI tool using solid SWE practices.
1 million lines of code in 7 days = ~6000 lines of code to be reviewed per hour, 24 hours per day.
or... they just trust that their ai got it right, which to most people is "vibe coding".
How can you claim following SWE best practices if couldn't realistically even have read the code?
So transcoding doesn't work unless every line of code is read? That's not how transcoding is done in practice.
"Please follow best practices."
You're telling me that isn't good enough? You might need to head off to the VC reeducation camps.
the speed of the rewrite and various analyses of the resultant codebase provide ample evidence that it was vibe coded and solid SWE practices were ignored
nobody understands the Bun Rust codebase. I wouldn't risk my business on code understood by no person. who is responsible? who will take accountability?
nobody. into the trash with it.
It was not ported by an engineer. It was transpiled by an LLM and no engineer has ever seen those 1mloc.
In 7 days?
That's just agreeing with extra steps.
1 million lines of code written and approved, in 9 days proves without reasonable doubt it was vibe coded.
Those SWE practices were so solid that the rewrite was already rolled back!
What are you afraid of?
I'm afraid "we" tackle (agressively) the wrong problem, also making it's tough for the maintainers, who did nothing wrong (I have a lot of sympathy towards Bun's developers, they got a lot of ugly feedback within the last month). I don't think AI-written code is the problem at all. Human signs off the changeset the same way as it happened before. I don't care if Rust rewrite did happen using pipeline/harness and LLMs, if the maintainer takes responsibility, and in projects like Bun it happens "by default", I think.
I agree with you that AI-written code should not be a problem and tons of open-source projects have AI-written code right now. But do you really believe the way Bun rewrites and merges its code to master is the same as before? The change in rhetoric (from "don't overreact, it's just an experiment" to "merge it anyway"), the never-arrived blog post promised to explain the decision are concerning to me.
I really appreciate the maintainers' effort towards this awesome project. However, I think it is fair to be a little bit less confident with the current state of Bun.
[dead]
A codebase that no human understands.
Yeah this is a cringe way to weigh in on something completely unrelated to your project. Who cares if some random package supports Bun? Compat was always on Bun, anyway.
> This decision seems to based more in politics than engineering.
You are 100% right. This is a decision made on VIBES and not evidence. The proof is here:
> Bun was recently rewritten in Rust using Claude, and its development seems to have taken a turn towards being fully vibe-coded. This is alarming and disappointing for a number of reasons, and frankly it seems like a future headache that we'd prefer to avoid.
They haven't tested it, they haven't found a single problem. They just don't like AI code and they're clearly saying "the fact that the project tested every line of code and it passes all tests doesn't matter to us. The fact that it's vide coded by people who literally make coding LLMs also doesn't matter."
Pure ego, no data.
So a vibed decision to reject vibed code. Minus minus equals plus?
I think you should read what the bun devs published about their process. It's not just vibed.
Care to share a link? There are 0 posts on Bun blog, or the GitHub page README announcing/explaining the rational for the rewrite, or project direction
There's been lots of talk about it here and on his twitter and such.
[dead]
Why are some people so pressed about this decision? From my point of view, if you're truly a vibe code enthusiast wouldn't you be able to just vibe code your own better yt-dlp (or fork the existing one and do whatever you need to do with it)?
Indeed. I've heard a lot of words about how trivially easy vibe coding makes building software, and how just about anyone can build something in no time at all anymore. Even stuff about how people will vibe code one-off private software for everything at all times, and such.
There really shouldn't be a reason for vibe coders to complain about any software decisions. Vibe coding a personal fork you better agree with should be a piece of cake. Isn't that part of the vibe code promise?
What's more is yt-dlp already has plugin support for 3rd party interpreters. They're just saying they don't want to deal with supporting bun themselves and the infrastructure for anyone else do use whatever they want is already there.
This is just the standard misguided entitlement people feel towards other people's projects supported by other people's time and effort. It's continually outrageous to me how people feel they can just volunteer other people's time and effort to support their own wants. The people who do the work are entitled to make their decisions and if you don't like it fork it yourself. This has been the way of this ecosystem since it started.
yt-dlp is surprisingly hackable as is.
Because for a lot of AI fans (not all, I know), it's like a religion. They aren't content to live and let live and let history show whose approach to building software is better, they insist that everyone has to agree with them. I have that situation at my job and it drives me insane that honest technical disagreement isn't allowed when it comes to AI.
I see Bun’s Rust rewrite (esp the style how it was done) as a form of massive internet trolling for PR reasons. By making a bigger fuss about it, we’re feeding the troll
We desperately need some new terminology to describe using LLMs to support development work. "Vibe code" has a strict definition but no one really cares. I have a really hard time believing that the Rust port was 100% "vibed" the way the original definition was laid out.
It's a big slushy of emotions that I understand (both positive and negative) but it makes it so hard to actually tells what problem someone actually has when they just use "vibe coding" as a general LLM usage slur.
I'm using LLMs to assist my development and I'm measurably (in all the ways we engineers could possibly care about) doing better work faster.
Vibe coding indeed originally meant "give in to the vibes [...] and forget that the code even exists."
In the case of this specific port, the port was done so fast that it is clear humans did not verify the soundness of the translation. It is not clear whether this manual verification will ever occur.
That being said, most software projects were already doing "vibe coding" by Dijkstra's standards long before AI showed up. Going on vibes and forgetting that correctness even exists ;)
Guaranteeing the correctness of complex code is difficult, but it will increasingly become non-optional as we now have a billion hackers in a data center.
---
Edit: "Bun's unreleased Rust port has 13,365 unsafe blocks"
I'm using LLMs to assist my development and I'm measurably (in all the ways we
engineers could possibly care about) doing better work faster.
Studies suggest you aren't any faster and may in fact be slower. It's difficult to study such a new tech, but even optimistically, empirical evidence is only showing a ~3% gain in some domains.
Writing code is rarely the limiting factor in our work.
I think those studies have framing or methodological issue.
I agree the maintenance burden is probably being undervalued by developers in general, but there's just no way the work I do isn't faster. I just categorically couldn't have achieved the outputs I do now in the time windows I have. The software just wouldn't have existed in the world of 3 years ago and I did enough coding back then to say that with certainty.
Surely that argument is dead once someone has migrated a million lines of code in eight days.
Surely that reinforces the argument - there are now a million LOC in a different language, needing stunning amounts of work to validate it actually functions? Writing the code has never been the bottleneck.
There's no uncertainty here. Every day I ask myself how long something I did would have taken without it. The answer is always crystal clear. It's not hard or difficult at all.
Those studies have well known flaws. I'm measuring my output so I happen to know I'm not only going faster, but the quality is better.
I'm not vibe-measuring my output ;)
studies suggest nothing. i've released a massive number of features in the last year for several projects that i estimate would have taken me multiple years to put together in a much more mentally exhausting way.
Your drive-by comments are unwelcome. You can estimate all you want, but the data is collating, and it isn't within your worldview.
It is healthy to question results: That's good science.
This result wouldn't surprise me if the tooling was limited to, say, copilot :)
It would surprise me if it included tooling like Claude Code. Which seems unlikely, given its recency.
[dead]
[deleted]
[dead]
Being conservative with technology choices and only using Node LTS has paid dividends lol
I can’t help but read the logic as not being too far off from: “libfoo switched to being developed using emacs instead of vim so we can’t trust it anymore”
It’s not the same obviously, but here’s why I can’t help but view it analogously:
The only truth in software is whether it works or not for whatever your use case is. Even before AI, we couldn’t have known if the author of a piece of software was proceeding with rigor or just trying random stuff until it seemed to work.
In other words, we didn’t judge someone’s software by inspecting their methodology or what tools they used. Heck, we often ended up using software that had no test suite or where the test suite was junk! And so many of us who are fans of memory safety use tools written in C, and vice versa (I’m no Rust fan but I use plenty of tools written in Rust).
So yeah, the logic that goes, “I won’t use your stuff because I don’t approve of your use of AI” is about as believable to me as if you stopped using something because you didn’t like the authors choice of editor
I don't know how to tell you this, but people actually can and do, in fact, worry about the methods things come to be made with, and make decisions based on if they approve of that process or not. Otherwise the idea of free trade chocolate/coffee/other shit would not exist.
>I can’t help but read the logic as not being too far off from: “libfoo switched to being developed using emacs instead of vim so we can’t trust it anymore”
That's wild. You should read it as being nowhere in the same ballpark nor adjacent ballparks as that.
Yea for real. Like how is it possible to even formulate that as anywhere near the subject matter in any way, shape or form :S
People addicted to chatbots appear to be suffering from cognitive atrophy.
> I can’t help but read the logic as not being too far off from: “libfoo switched to being developed using emacs instead of vim so we can’t trust it anymore”
So let's say they up the ante and set up a cron job to rewrite the entire codebase in a new language on the first Monday of every month: from Rust to C++ to Go to Swift and back again.
For customers using the product, that's basically the same as a maintainer switching editors? Irrelevant detail?
Most people probably think the text editor used would have no meaningful effect on the code written.
I don't think many would say the same for LLMs.
Maybe vibe bun is just as good or better than old bun, but how would we know at this point?
> ...we couldn’t have known if the author of a piece of software was proceeding with rigor...we didn’t judge someone’s software by inspecting their methodology...
That's not true. First, some people do directly check whether a project has a level of rigor they are comfortable with before adopting it (or when deciding whether to continue using it). I personally do it, where it matters. Many more use reputation signals, which, while certainly not perfect, correlate, may be good enough, and are a lot easier than direct, manual reviews.
> Maybe vibe bun is just as good or better than old bun, but how would we know at this point?
By considering objective facts like efficiency, performance, error rates, security vulns etc. like we always do?
There is no such thing as "we always do" now.
We care about those things you listed and also the fact that code was written by (or exhaustively reviewed by) a sentient consciousness. It's just that the second thing has historically been implied. That's the difference you are experiencing.
These objective facts aren't known right now for vibe bun.
Someone would have to do a bunch of work to establish these things.
Do you mind if I vibecode a fresh vehicle control software for your car?
Don’t worry, it’ll just be in a different language.
I don't know how to feel about the Bun rewrite.
On one hand, it seems very scary to me, having most of your codebase unreviewed.
On the other hand, it passes their tests with few regressions from what I heard.
Maybe it's just because I don't have enough experience there, but I wouldn't trust my tests to this degree and completely rely on them without reading the code.
To be honest, I share primeagen's view that LLMs handle translating code from one language to another quite well. As far as I know, they converted the languages file by file. This is what led to such a high volume of `unsafe` code. Although, in any case let's be honest, this is causing, and will continue to cause, various issues. I find it easier to live with this point of view.
primeagen's view
He's a content creator on youtube, a celebrity, not a serious programmer.
He was a software engineer at Netflix before turning to content creation. It is also clear watching his videos that he knows his thing. As an experienced programmer myself, I find his commentary to be way too relatable to be just bluff.
He may not be Don Knuth, Linus Torvalds, John Carmack or Fabrice Bellard. But he is definitely a serious programmer. That he livestreams doesn't make him less of a programmer.
Who cares what you think of someone else’s qualifications?
It’s just someone quoting someone to help ground their position.
What if it was a journalist writing about a security vulnerability then a programmer quoting them, would that count then?
If it doesn't matter, why did the previous poster mention them?
It's pretty clearly a type of argument called an "appeal to authority", where an authority is cited to add credibility to a position. It's usually considered a pretty weak form of argument, but it can be effective. So the credibility of the cited authority is relevant.
> This is what led to such a high volume of `unsafe` code
Which defeats the purpose of having it in rust.
That is incorrect.
Identifying where code is unsafe, is a qualitative improvement. Not guaranteed to be complete, but more complete than a language that does not focus on that concern. Moving forward, the benefits of Rust compound. The concern about AI is orthogonal to the concern about moving to Rust.
Now there are 2 versions[1] that can be instrumented, regardless of the misgivings about AI.
[1] Bun v1.3.14, released on May 13, 2026 (commit 0d9b296af) and current.
I think this is fine with the caveat that if it does turn out the rust rewrite works just as well as before they should start supporting it again.
Say what you will about Rust vs Zig as languages, the Zig toolchain is definitely the easier of the two to integrate into another project.
This doesn't really have anything to do with the merits of the languages themselves, but rather with the rewrite being entirely vibe coded. If it had been from Rust to Zig instead of from Zig to Rust, I expect the exact same response would have happened.
Mostly unfounded in my opinion. They took the _exact_ same strategy that go did when they moved from C Go to a Go based compiler.
First they essentially wrote a translator that preserved the C idioms (so it wasn't idiomatic go) until they had byte for byte output.
Then they started changing code one by one to be more Go-based.
Bun is doing the same. Right now it is mostly a one for one translation of the zig code. Over time they'll make it more idiomatic Rust.
So many people in the comments here are making assertions about the quality of the rust re-write but the point largely remains the same. There is no way you've read all million LOC in the time and reviewed to make sure it really is transpiled. It's not a criticism of the method, but the time and review process.
They foresee potential issues in the future, so they deprecate now? I mean, whatever lol do as you like, but that's an odd choice.
There is an implicit assumption that the other supported runtimes aren't being vibe-coded. Looking at commit metadata tells a different story.
This is such a knee jerk reaction.
Your bank has vibe coded their entire codebase into rust in a week.
The test suites passed so it's all good.
I think this HN submission provides little value and a lot more headache to the maintainers of FOSS project (you can already see a lot of brigading in the GitHub comments). IMHO HN shouldn’t allow submissions like this.
The "to vibe code or not to vibe code" holy war is now in full swing.
war implies "not vibe code" could win. that's impossible
There's literally nothing that LLMs can build that humans cannot. The only factor influencing people to use AI is time. They trade off a small amount of quality for a large amount of time savings. The tortoise and the hare parable comes to mind.
so why arent you using punch cards? are you pretending time is not the most important resource?
What does this use bun for? I thought this was a python project?
They need a JavaScript runtime to execute some challenges that certain pages present (like YouTube)
[deleted]
This title is wrong. It makes it sounds like Anthropic dropped support for and deprecated Bun.
Has bun really shipped using a million line vibecoded PR. I know they merged it, but merging something in a new dir doesn’t mean anything compared to what code is actually running for customers. It’s crazy if the vibecoded rust version is what’s running for customers and not just some experimental hack.
Except it's not vibecoded, it's litteraly the best prompt an LLM can ever get - literal code. If the whole thing ends up as a failure, then it will show that the king is naked.
zig is barely adopted relative to rust. totally reasonable to move to Rust, which isn't as risky of a bet. and you're not the guy having to find their zig memory leaks.
Someone should fork yt-dlp and rewrite it in Rust...and have it use bun exclusively
there could be recommended runtimes, but shouldn’t the runtime be user-configurable anyway?
There is no generic “JavaScript runtime” interface that runtimes would implement, therefore support must be tailored to the specific interfaces of existing runtimes.
At one point we had UMD[0], which effectively provided runtime-agnostic interface, but ES modules were incompatible with that.
Deno and Bun have decent Node compatibility, so couldn't Node APIs be used as the generic runtime interface?
There is another by Meta for react native. Forgot the name.
hermes
Google did something similar with golang. Of course it was a tool based rewrite and they did lots of tests but some bugs still emerged. People should stop being mad about a company that delivers a tool that is about shipping software faster. The world does not resolve around high quality software, the world resolves around things that might need a reboot every other day, that was never touched for over 2 years. Things that somebody did once and it worked but most people do not understand it because of the aweful code.
Yes of course we still need high quality code in some parts, but most parts of the world is already running on software that is way worse than modern vibe coded things
Do not vote on this comment! I am a server! :)
tl;dr: give up, stop trying. just approve the juniors' PR without comment so you have more time to proompt.
Why even use bun or anything else if everything is getting slapped together with LLMs? May as well use them to build native
[deleted]
Do you also install pre-alpha revisions of operating systems on your main work pc? No, you do not. Why? Because of the "foreseeable compatibility and security issues".
"Well, why don't you install and only then resolve issues if you have those difficulties?" most comments here are asking, in effect
Cause you're sane, that's why!
Same here. yt-dlp does not owe it to anyone to beta test things. Maybe this bun rewrite will be the best thing since sex, and maybe it won't be. Not wanting to alpha test someone else's shit is sane. And the bugs (if any) would go to yt-dlp, forcing them to debug someone else's alpha software. This is a sane response.
[deleted]
Who was actually using yt-dlp with bun? The primary use is to solve JavaScript challenges sent by YouTube, which uses Deno by default.
To be fair, I'm not quite sure why it would prefer either Deno or Bun when it's far more likely that a user has Node on their system.
I assume they need to do a bunch of WebAPI bullshit to get around Youtube's draconian policies, but maybe one day https://txikijs.org/ will solve all problems with embedding javascript. I believe, and maybe the strength of my belief will be enough.
Bun was just one of multiple JS runtimes supported, so dropping them doesn't have user-facing consequences. The people posting militant comments here and harassing the maintainer on GitHub are fighting for Anthropic instead of trying to raise any legitimate concerns about yt-dlp.
Do we know which model was used for the rewrite?
Claude
Bun’s source code rewrite from Zig to Rust was executed primarily through AI-assisted development using Anthropic’s Claude agents, specifically within a branch named claude/phase-a-port. The project creator, Jarred Sumner, merged the massive pull request (PR #30412) on May 14, 2026, which involved over 1 million lines of code added and 6,755 commits completed in roughly one week.
Claude is a model provider: they have many models. It would be interesting to learn if the models used were Sonnet, Opus, Mythos, some other internal unreleased model, or some mixture of them.
Gemini, obviously.
I already came across some bs bug in claude today due to this stupid rust bun thing, so I absolutely 100% support this decision.
Bun alert!
Good news!
As long as Deno support is still there I'm not sure why you need anything else. It's not vibe coded slop for one.
Deno's LLM contributions have been smaller in scope, so they're more likely to be reviewed by a human, and the codebase remains understood by its contributors. Can the same be said of Bun, which switched to an entirely different language in a single, million-line PR?[0]
Since when small vibe coded slop became the norm? Because there exists bigger vibe coded slop, it's no justification to have a smaller vibe coded slop.
One shotting slop is very different from iterating back and forth with an AI. Also, most of the AI work that's being done has been getting node compatibility tests passing with the help of comparing that to the Node.js code, which is something an LLM is very good at.
> One shotting slop is very different from iterating back and forth with an AI.
Bun is also iterating back and forth with AI. The rewrite only got popular because of bigger scope. The bigger the scope is, the more bugs there are.
> getting node compatibility tests passing
So does Bun.
> which is something an LLM is very good at.
Doesn't matter. The code those LLMs operate on is simple enough that any middle software engineer can do.
Using AI to write code is not necessarily vibecoding nor slop.
I don't think it matters how code is produced -- it matters what it achieves. Is there evidence that there is something wrong with recent Bun releases?
I think one of the big disconnects here are the competing views about "what it achieves" means on a fundamental level.
There's the "what it achieves" today; software x works as intended as of right now.
And then there's "what it achieves" long term.
Those with significant experience with sprawling, LLM-generated, codebases, often built by those who don't understand the code produced, can attest to things being good today, unworkable tomorrow.
While this isn't true across the board, and my own experience should be considered anecdotal at best, those who consider "what it achieves" to also include long term viability as a success metric, are skeptical of these types of changes.
Personally, success for dependencies isn't just "does it work today" but "can I trust it to work long term."
I don't use Bun. I don't care about Bun. But my opinion is that how code is produced will have some effect on what it achieves, if the goalpost includes more than "it works today."
I see a lot of commentators in this thread who are aggressively critical of volunteer maintainers for making a decision about how to maximize the value of the free labor they donate to the world.
And yet none have offered to volunteer their time to maintain a downstream fork or otherwise rectify the perceived problem.
Strange.
Which "volunteers" are you referring to? Bun? yt-dlp?
yt-dlp, clearly. Bun has no volunteers (as of the rust rewrite at least, it's all highly paid SWEs and GPUs.)
Most developers can’t see AI slop because their level of competence is actually below what an AI can produce.
Technical debt was a reality before vibe coding. Someone was writing all that trash by hand.
I like this clear divide of:
Zig bad, rust good
You bad, ai good
and then some random posts in between that try to create some hot takes for upvotes. What is the internet at this point?
Ah yes, more examples of averse behavioral ai syndrome
Reason #2 is purely speculative. It’s disappointing to see technical decisions being made on such grounds.
All dependency management is speculative. You've got to hedge your bets that the dependency is reliable and fit for purpose. It is reasonable to view Bun's recent choices as increasing the risk associated with depending on it.
Very much agree. Until the vibe-coded version has been fully audited and profiled to perform, within reasonable tolerances, as well as the original code base, it feels like a bad idea to support it downstream or use it in production.
Even if it performs reasonably, it may still be unmaintainable, meaning that any future changes are likely to introduce bugs and instabilities. At the present state of AI coding it’s completely understandable not wanting to depend on code that the maintainers have no good understanding of. The code auditors would have to become the maintainers.
Any rational person investing in AI rewrites at this scale must fundamentally believe that all the downsides of the slop will eventually be cleaned up by the next version of the slop machine. So it's slop all the way down until, wave wands, the slop is indistinguishable from magic.
That is to say, techno jesus cometh.
Yes, but only if auditing includes an exhaustive human review of the code, not just passing the tests we (or an AI) thought to write.
I'd hope that the bun team is going to put into the work to ensure the LLM translated version is up to snuff before cutting a release from it though... it doesn't seem fair to assume that that isn't going to happen.
Really?? So you base your engineer in "speculation". The Bun team has a deep track record of delivering a high quality product. What makes you think that is going to stop?
>What makes you think that is going to stop?
a million-line rewrite over 7-8 days
>What makes you think that is going to stop?
The PR that was merged.
> All dependency management is speculative.
What a nonsense generalization.
In this case, the speculation ostensibly is that in future, there will be a release version of Bun that has is buggier or otherwise lower quality than the current stable version.
There's literally no basis for believing that. The actual basis is "I don't like how they're approaching the development of their next version."
If that's a valid basis for "dependency management", then using a Ouija board would be just as valid.
It's a common fallacy among tech folks to believe that every decision can be made from 100% deterministic grounds ("X decision will result in Y percent change"). In reality, successful decision-making often involves speculation. The speculation in question is within the bounds of reason. You may disagree, but the fact that it is speculative isn't the problem.
And not acting while doing the whole analysis to reach close to 100% deterministic grounds mis a decision in itself! It’s perfectly reasonable to drop support for bun, and potentially revisit later on when more details come up
> The speculation in question is within the bounds of reason. Y
I disagree. It seems to be an emotional reaction borne of ignorance and uncharitable assumptions. There's no "reason" involved.
What part of the recent history of vibe coded projects has not resulted in low quality, bug laden code? Dismissing this a "purely speculative" is just like dismissing the weather report as "purely speculative" when deciding what to wear in the morning.
Low quality, bug laden code has existed long before LLMs and it'll continue to exist long after. Their rationale about avoiding future headaches could literally apply to any open source project they have a dependency on.
The existence of bad code doesn't mean you should be happy to accept it.
There is quite the selection bias going on here... you aren't hearing about the successful projects.
People love to brag about using AI to get work done. If anything I expect the successful projects to be overrepresented.
Care to list them then? I have yet to see a successful vibe coded project
With all the unprecedented investment and desperation behind it, these hypothetical LLM successes would be getting shoved down our throats.
We're only hearing about the failed projects? I call BS. Precisely the oppositee is both true and obvious if you're not a shill. The "successful" ones are being trotted out all the time trying to convince us how great it is. If anything, we're not hearing about all the catastrophic and costly failures while the cherry-picked almost successes are all over this platform and others.
Doesn’t bun have a massive test suite that the rewrite passes? What else do people want?
1. You cannot make bug-free software with tests alone. Moreover, code that compiles and executes successfully is only one goal, memory efficiency and performance and security are other desirable traits. Claude Code can consume GBs of memory to display 1kb of text because it is slopware.
2. Even if somehow you did make bug-free software with tests alone, even if the Rust port is at perfect parity with the Zig codebase today owing to the years of careful human work that went into building tests as a framework to guide the AI... the future can only be downhill from here. Nobody has a mental model of the new 1m loc codebase that's never read by humans, so Bun's future is committed to 100% vibecoding. Maybe the carefully planned tests minimized the worst case scenario, but the future tests will be written by Claude too.
If, and this is a big if, it turns out that there are no major problems and Bun is better off in a year from today than it is now... then somebody can just fire up Claude and fork yt-dlp to support Bun anyways and their decision doesn't matter. In any other scenario than human code becoming completely obsolete, they are simply saving themselves a headache by getting rid of a troublesome dependency.
Tests are one quality control. It's horrifying that some of us treat them as the only thing that matters. There's review, obviously, and of course we haven't even had to think about "written by a thinking mind" as a beneficial quality until now.
How is "written by a thinking mind" a beneficial quality? All of sounds like to me is bias and gatekeeping. History repeating itself.
Vibe coding from scratch is far from translating an existing app to another language.
I don't know any bad stories about ai-translated apps. Partially because it's a relatively new trend, but also because a big amount of usual vibe code fail modes are not applicable here.
It's a reasonable decision to not take a dependency which doesn't meet your own engineering standards. People in the JS community could learn something from that.
[dead]
When Patty?
[dead]
[dead]
Idiotic. Why do they care what language it's written in? If it works it works.
Wow, bun support was just added in November last year (I think). That's a lot of work to throw away, but you can't argue with their reasoning.
bun is still supported for specific versions so nothing is being thrown away. in any case the actual code is the same, since it's all javascript. it's more a matter of the wrapper code that calls the different runtimes and maybe some edgecases where the runtimes are not 100% compatible.
Honestly I hope agentic AI ushers in a new age of minimal-SBOM software. I myself am moving all of my projects towards nearly 100% vanilla where possible. For example, golang. Why use [insert web framework] when you can just use vanilla for 99% of web apps?
There's something really satisfying about a go binary with minimal dependencies running in a busybox docker container.
Rather than have complexity centralised and managed, let's generate the same vulnerable code across millions of apps. Great plan.
"A little copying is better than a little dependency." - Go Proverbs [1]
Most complexity is unnecessary. Adding dependencies to your project exponentially increases your project's surface area, which in turn increases its regulatory/cybersecurity burden, especially if your software is a medical device, munition, etc. Why is Echo/Gin/Gorilla/etc better/more secure than vanilla Go's mux? Just anecdotal, but we use the Echo web framework for Go and it's caused nothing but headaches. It does magical XML parsing by default even though we don't deal with XML which gets us flagged in pen tests. Updating from v4 to v5 broke production for us because they made an undocumented server config change that makes all requests have a 30 second timeout. Meanwhile vanilla go has the ability to register routes and middlewares, so what value is Echo bringing to the table? Ditto for lots of other unnecessary dependencies. A lot of times we just need one little thing out of the whole package, and in those cases a little copying (or a little AI generation) is better than a little dependency.
A static go binary with minimal dependencies running in a busybox container has a tiny CVE footprint when run through grype/snyk, etc. Do the same for a NodeJS app with zillions of dependencies running in an ubuntu container and you'll spend all day triaging CVEs.
I'm not saying "roll your own crypto" but I am saying "axios-like packages don't make sense to use any more in a world where AI+vanilla accomplishes the same thing"
Wouldn't that be worse? With dependencies, it's at least possible that someone else has audited the code, but with a vibe-coded from scratch app, it's definitely totally unreviewed.
I never said AI code should be "unreviewed". I'm saying that instead of pulling in axios or requests (as a contrived example) to make HTTP requests, just use AI to generate some vanilla JS/Python that has the exact subset of functionality you need. Your code has fewer dependencies, CVE surface area, etc, wins all around.
You only add what you need instead of importing some bloated dependency. That means you can actually review the code yourself.
> Removed: mathjs dependency. 14MB, 200+ functions. Twelve functions used. Added: Custom math utilities module (src/math-utils.js). Addition, subtraction, multiplication, division, a handful of trig functions. Co-authored-by: chatgpt. Changed: Bundle size reduced by 68%. Build time down from 12s to 4s. Module: 47 lines across 1 file. 0 tests. 0 dependencies.
Are you aware this is satire?
Yes, it says so right under the title. But it's not wholly fictional: this happens all the time, to the point we have a name for it (Not Invented Here syndrome).
That it took so long before they started trying to phase out their home-rolled library for the "hard cases" is somewhat unrealistic, although possible in a sufficiently-dysfunctional organisation. Some of the details about the problems of their homespun library are clearly anecdotes translated from other settings, and are unrealistic in the context of a mathematics / finance library. (They only noticed that interest calculations were wrong when a customer complained? Seriously?) The development of 6.1.0 (via 6.0.0) taking only two weeks isn't congruent with the rest of the story, although it may be realistic for AI-driven development (with which I am unaccustomed).
But otherwise, this is one of the more realistic satire pieces I've read.
> There's something really satisfying about a go binary with minimal dependencies running in a busybox docker container.
Go binaries are immensely satisfying, but I don't follow your logic here. The vast vast majority of dependencies in Go do not depend on the outside world, so the binary would remain self-contained whether it has 1 or 100 dependencies, no?
Assuming you disable CGO, yes, the binary is always self-contained. However, I want to clarify a few things.
The "self contained" part is only important in that it lets you use busybox or "from scratch" as your container runtime environment which has a very tiny cybersecurity surface area compared to, say, ubuntu or even alpine which has a bunch of system libraries your go binary isn't using, but which could still get flagged for having vulnerabilities.
Minimizing dependencies of the go binary is a separate, but equally important task that reduces the cybersecurity surface area of your go binary itself to just "the go standard library" instead of "go stdlib + a dozen github packages"
Whenever I am working with a NodeJS project I pity the fool who has to do SCA because the CVE surface area is enormous compared to go, which has a fairly batteries-included stdlib
That must be why so many vibe-coded UIs have awful UX (terrible contrast, too small fonts, everything gets its own colors, no attempts at standardized behaviour)
[deleted]
Frameworks and ORMs were the pre-agentic AI "iron man suit".
I'm quite liking how good Claude Code Opus is at Rust + sqlx (raw SQL with type safety) + actix-web.
This like if BitTorrent cut off Windows support over objections to Microsoft embrace/extend/extinguish. It’s a slightly incoherent position.
This seems like a tenuous analogy, to put it lightly.
Care to explain why, or nah?
Not BitTorrent, but I can see a world where e.g. Transmission dropping Windows support because of Microsoft policies.
To me it feels more like the old "this site only supports IE6". Instead of checking which JS engine the user has, check for specific api support and fail gracefully.
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].
[1]: https://github.com/oven-sh/bun/pull/30412
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 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.
I find that adversarial multi agent setups eventually fall down because one side or the other always manages to convince the other side to give up given enough time.
I’ve tried all sorts of things to keep Claude from cheating, but the only one that works is to restrict access to the tests files, which obviously isn’t a real solution.
We recently had an “AI week” at work and I spent $1000 in tokens trying out different iterations of this.
> Image routines my heart sank. Another shiny object
With quite a peculiar set of supported formats different between operating systems.
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.
Businesses have been dealing with - more capable one refuse your business and walk away. Or you have to drop prices. And yes, I have seen it happen.
It is not immediate process, but it is a thing.
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?
AI is extremely good at rewriting existing code, and rewriting code is a classic engineering productivity trap. That's a tale as old as time; "we need to rewrite the api in Go" said every new midlevel engineering hire ever. Of course, 9 times out of 10 we don't do it, because the unpredictable costs always outweigh the benefit, and in Jarred's case we're starting to see these costs surface. They aren't technical, they're political; broad swaths of the community have lost faith in him and the Bun project.
Write in C, snapshot to memory safe production Rust that had been verified and differential tested to within an inch of its life. This is a hard reality. Ports will become cheap. Disposable. The vuln finding capabilities are changing everything and not a lot of solutions are out there yet. We can automate the ports and get them efficient.
https://duckduckgo.com/?ia=web&q=bun+fork+of+zig+compiler
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.
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.
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.
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.
[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 .
>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".
[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]
I'm very skeptic that they read the entire codebase of Bun prior.
yeah this just feels like an attention stunt tbh
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.
The million or so lines of the original code has been "battle tested" for what it's worth.
This is a massive codebase created within a week or so ago, no one can say what it will do till it does.
"No human understands any of the code" is not the same as "no human understands the entirety of codebase fully". Very different situations.
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.
It's the little bits that aren't 1:1
Who wants to review a brand new codebase for free?
Why is it for free? Isn’t Anthropic paying their salaries?
That doesn't change anything. No one can say with confidence, backed by proof, that the 1M slop is semantically equivalent to the old code. The code is a black box without that guarantee.
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.
I mean should we even compare Bun to Windows in the first place? Like Mircosoft with its resources would find a way to support Bun and Windows is one of their most popular and most used products. The situation with Bun is very different in terms of business/product.
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
It’s not like they are discriminating on someone’s race or religion. If they don’t want a major vibe coded surface, do they even have to defend that? It’s part their “artistic” license as developers.
Or did we forget software inherently is opinionated
Given some posters on the GitHub issue, I get the sense some people feel their religion is being violated.
You don't even have to leave this site: when the original Bun rewrite posts were made, an incredible number of comments were focused, not on Bun, but on Jarred, who I'm assured is a complete rockstar and would never harm Bun.
Unfortunately, his followers don't realize that something like a batteries-included runtime is a huge commitment to build on top of, and governance you can trust matters as much, if not more, than the lines of code.
The way this has been handled is just baffling. A Rust rewrite is supposed to be a freebie for hype, and even an AI rewrite could have been interesting if approached more scientifically and transparently... but instead the opposite of that happened.
Yes, it’s actually similar to discriminating based on race or religion, in the sense that it’s an arbitrary, meaningless criterion to discriminate on. If the Rust Bun port is better in every measurable way — passes all tests, has the same performance or better, and fixes existing bugs — then who cares what language it’s written in or how it was implemented? The point is that it’s higher quality. If you don’t trust the Bun team when they release a Rust version and give it their stamp of approval, why did you trust them when they released the Zig version two weeks ago? It makes no logical sense, and it makes the yt-dlp devs look foolish.
> If you don’t trust the Bun team when they release a Rust version and give it their stamp of approval, why did you trust them when they released the Zig version two weeks ago?
I think you cannot make this comparison because Rust version wasn’t in fact written by the Bun team. It wasn’t even read by them.
Based on the comments I think a lot of people assume the headline pertains to Bun itself.
This stuff brings bad vibes.
exactly... and it's not like it's hard to fork and just raise the minimum version. It will probably be just one number somewhere (I haven't actually looked.)
if it works, it will keep working. they just don't want to support and maintain it and solve issues.
Oh well, I really like using Bun and I get kinda sad about the turn they are taking after the Anthropic acquisition. I really want a good Node with batteries included, but I don't want it vibe coded.
Have there been any significant issues caused by the vibecoded translation?
To be clear, I'm not implying support for the merge. I am against this whole YOLO approach to engineering. Just curious how the switch is going since I haven't seen any news since the merge announcement.
IMO the source of the new code is less important than the sheer volume of it. Bun does not need to be entirely rewritten; certainly not over a period of a week, possibly not even over a period of a year. Stability is hard-fought and battle-tested. Everyone has a plan until they get punched in the face; and every repository has passing tests until it runs production code.
How many lines of translated code would have been acceptable? What about before AI all the machine translated projects that people used for years without a single complaint? The person who did this was the lead for Bun from the get go no? So it stands to reason that they are one of the highest authorities in Bun itself.
What is the essence of a program?
The name? No.
The author? No.
The test suite? No, testing is hard and most projects don't do enough of it.
The code? Not really, code can be rewritten.
The history of the program being executed by its users? Ding ding ding. Yes, it's this one.
Bun no longer exists. What exists now is a program that has the potential to be Bun but at this time is not Bun because it has no history of being executed as Bun.
If the rewrite has been done piece-by-piece or over a longer time period then this history could have been built up over time. As such we will have to wait a while for Bun to exist again.
It's an competitor to bun at the moment, that's what happens when you rewrite a whole program.
Name being the same or not, it's what it is in reality (for better or worse)
> What about before AI all the machine translated projects that people used for years without a single complaint?
If by machine translation you mean something like transpiling, that's a technology that has been proven over decades, and the translators were written by hand with some attempt at formal correctness and guarantees. Translating with LLM is much newer and subject to the errors LLMs can create, such as hallucination. And I think a lot of people would still be nervous about translating an entire project of that many lines, even with the best pre-AI translators.
I agree, I'm just wondering whether the punches have come already. Honestly, the fact that they haven't is against my expectations, my guess was that we'd see a noisy one here a day after merging.
It's too early. It might be too early forever.
Epistemically: if it can be so easily vibecoded to rust, why can't it be vibecoded to be reparted? Isn't the great and Almight AI unable to parse and repair Zig? Identify it's weak points and route around it?
According to the bun team, it was already vibecoded for months before the Anthropic acquisition.
Probably a lie tbh
Why is it so hard to believe that Jarred Sumner, a self-described "Thiel Fellow and a high school dropout", had values aligned with Anthropic's before Bun was approached for acquisition? It's not like Claude was an asteroid that crashed into Eden.
Why dont you want it vibe coded? Does that make it worse?
Not necessarily, but I don't trust Anthropic in making sure it doesn't become worse. They are already doing a terrible job with their own Claude Code CLI.
Ah I see, yep agree with that 100%
I think it's hilarious how hopeful people were at the acquisition that Bun would be able to continue on mostly as it had been but then that all got completely thrown away and trashed.
(Hilarious in the way that's terribly sad, of course.)
It usually takes years for someone's values to be thrown out the window! How long was this one?
"It is difficult to get a man to understand something, when his salary depends upon his not understanding it"
changing your employer tends to accelerate that if the new employer has different values.
How has it been trashed? Does the Bun software not work anymore?
They literally threw out every line of code that existed before and rewrote it in a completely different language, seemingly on a whim. That's how it was trashed, in the very literal sense that all of the existing project was tossed in the trash in favor of a completely brand new code base. That's a big deal even if you ignore the coding agent aspects.
The worst part is that they basically didn't review the new code at all other than making sure it passes tests. We have no idea what could be lurking in the codebase now, and it's even all completely un-idiomatic, Zig-ish Rust.
> making sure it passes tests
Not even the same tests, as far as I can tell. That million-line PR touches a lot of test cases...
I swear they did this as a marketing ploy. To set the precedent that these large refactors are okay to do, and ingrain it in the engineering zeitgeist.
Kind of reminds me how Google starting putting on automatic AI processing of YouTube videos and shorts around the time of AI generated video and images. Their processing gave the videos artifacts that made them look more AI generated, making it harder to discern AI generated images, maybe to make demand for their watermark products.
>Does the Bun software not work anymore?
Nobody knows.
Unless specific issues have been identified that were introduced by it being "vibe coded", isn't a reaction to reject it outright without actually checking the ground truth just exhibiting the behavior you are criticizing?
It's just a trust issue. Have you seen the absolute state of the Claude Code CLI development? I don't want that to suddenly happen to Bun after I've already used it for production stuff.
I don't see any hypocrisy in the comment you are criticizing. The behavior they are criticizing appears to be vibe coding. How is rejecting something for being vibe coding "exhibiting the behavior" of vibe coding?
There’s a big difference between vibe coding and agentic engineering. If you think they are at all the same thing, you need to update your priors
You aren't allowed to dismiss vibe coded software based on the slop vibes. It must be well-researched and human reviewed in order to have an opinion.
The ground truth is that the new maintainers can’t possibly have a good understanding of the many millions of lines of vibe-translated code. Even assuming that the code happens to work okay in its current state, the lack of understanding means a high risk that its continuing maintenance won’t result in a satisfactory level of reliability.
Aren't the maintainers the same people? I haven't seen any talk of who's working on it changing drastically.
You want the yt-dlp authors to review the entire post-migration Bun codebase?
And what are you referring to as "behavior"?
Do you review your dependencies’ entire code?
Virtually no one reviews entire code bases of dependencies, what on earth are you talking about?
They reviewed it in the sense of integrating something that worked, this is something maybe not completely different but different enough to give pause.
No, would you use a proudly vibe-coded banking app?
How would you know it was out wasn’t vibe coded?
I'm not sure what "exhibiting the behavior you are criticizing" would even mean here.
BUT.
"Ignore anything but actual problems" is a terrible stance to take generally for software and dependency selection. Incidents are fairly sparse, process is much easier to observe. So if you can find connections between process and incident possibility, that's a very reasonable heuristic. And it's easy to find examples of overaggressive LLM usage introducing problems into software.
You are putting words in my mouth, I never said anything about such a stance.
The vast majority of new software is written using AI. The problem is not that it is written by AI, but rather than some people treat it like a black box. It is entirely possible to use AI to write code and verify that it is correct. Even Linus Torvalds is allowing AI generated code into the Linux kernel as long as it's managed properly.
>The vast majority of new software is written using AI. The problem is not that it is written by AI
How on earth does this follow? It's common, so it should be accepted without scrutiny?
>The problem is not that it is written by AI, but rather than some people treat it like a black box.
Yes, and guns don't kill people. Obviously the issue has two facets. It would be irrational to say "AI is flawless" or "humans are flawless".
Allowing genAI code does not imply blindly trusting genAI code.
>as long as it's managed properly.
Correct. Hence the issue. This was vibe-coding by even the strictest definitions of the term. Vibe-coding is, by definition, not "properly managed".
You are referring to black-box coding, not vibe-coding. There is no strong formal definition of that word. Is there evidence that they just fired off the LLMs and didn't review or test the new bun code?
The evidence that they didn't review it, is that a million line rewrite was merged 8 days after it began being written. It's simply not possible for a team that size to review that much code in that little time.
As far as testing - yes, they do have a test suite that it was checked against during the rewrite, but that still means that any behaviour that wasn't strictly tested for by that suite could have changed and it would still pass.
This is about the rust conversion but that has not been released.
> Due to foreseeable compatibility and security issues
Hmm, Zig bun crashes plenty.
I wish yt-dlp linked to detail on why there are foreseeable compatibility issues. Both projects have test suites, in an ideal world they would allow fast rewrites. Maybe they want to limit inflaming the situation, but if they have spotted some specific issues it would be good to see.
I hope Bun.rs is 1.4 or even 2.0 and not a minor release, with some alpha/beta releases.
Yep, it's one thing if there was some project that saw severe regressions in Bun.rs and actually showed data about regressions.
But it's been available for a week. And so far, seems like crickets on actual data on any regressions. It's more "I just don't like this!" style grumbling.
This decision seems to based more in politics than engineering. Have you observed Bun have more segfaults, OOMs, etc, since the Rust rewrite? Have you noticed more security vulnerabilities? Have you seen more bugs? (Of course you haven't, the rewrite hasn't even landed yet.) It seems that you are making this decision because you get a bad feeling when thinking about AI involvement.
I don't select my engineering tools because they give me a bad feeling - I select them because they do the thing I want them to. If Bun starts having more bugs and feeling like worse software, I'll stop using it. But I will base that on data -- not a feeling I have. Jarred has done a lot of impressive stuff with Bun, and it seems unlikely he would ship this rewrite if it didn't meet his quality bar - I am willing to see him out here.
> Have you observed Bun have more segfaults, OOMs, etc, since the Rust rewrite? Have you noticed more security vulnerabilities? Have you seen more bugs? (Of course you haven't, the rewrite hasn't even landed yet.)
On the flip side it's not on the yt-dlp authors to test Bun's new development process and see if it results in more segfaults, OOMs, security vulnerabilities, etc. In fact it would arguably be negligent to experiment on your users if you thought there was a reasonable probability of increased security vulnerabilities.
I think there's a good argument that the responsible thing to say would be "we aren't going to immediately support running our software on a new bun release cut from main right now".
It seems a bit unfortunate to me that they've apparently already intending to never support future releases instead of planning on re-evaluating in the future. On the other hand the yt-dlp developers definitely don't owe anyone anything.
> It seems a bit unfortunate to me that they've apparently already intending to never support future releases instead of planning on re-evaluating in the future. On the other hand the yt-dlp developers definitely don't owe anyone anything.
I think your final comment gets at it. If they said "OK, I am skeptical, so we're going to pause on updating to see how this Rust thing plays out" -- that sounds like a reasonable engineering decision. Saying "because they vibe coded we are dropping support for Bun" sounds political.
Why is it "political" to say "I don't trust software fully written by an LLM that has not been vetted by a human"?
That feels like an entirely reasonable stance to take.
And I see the argument/correction downthread that it's an "emotional" or "ideological" stance. Why does it have to be that? It seems completely rational and logical not to trust software written by a technology that is known to hallucinate and "cheat" to make tests pass.
Of course, I can't say that the yt-dlp maintainer is or isn't being political/emotional/ideological when making this decision; none of us can know their true motivations without asking them, and I choose the charitable explanation unless shown evidence otherwise.
> Saying "because they vibe coded we are dropping support for Bun" sounds political.
I disagree that this is a political stance. People based on their experiences have formed opinions on whether they trust that model of development or not. Bun having taking extreme measure of going 100% in within a week is itself extreme positioning from their side which will likely result in extreme reactions because depending on who you are and your experience you'd bet on the fact that it may or may not work out.
I disagree as well, and wonder if the OP meant an emotional or ideological stance instead.
Yes - this is indeed what I meant, thanks.
In all sincerity, what does political even mean in this context? ELI5, I’m a toddler when it comes to the politics of AI/LLMs.
Its a polarizing world with AI. There are fanboys drinking the kool-aid blindly listening to whatever Sammy/Dario/... say as gospel, and on other side there are haters who again blindly reject the fact that these AI tools can be actually be useful. I think that's what the politics is.
Yes - exactly! I honestly thought I was going crazy when a bunch of people were saying that this decision wasn't political in the slightest.
I’m tracking the polarity of the whole movement, I didn’t understand how politics was attached. I desperately don’t want the whole thing to become a left vs right disaster. We have enough of those.
You might not like it but you actually live in a world with other people and building technology often affects their lives and they have opinions on it. For AI a lot of that impact has been negative.
I don't have the emotional energy to care, actually.
This is actually fascinating. How does my opinion matter? Should I join all the socials (this is my only form of social media) and stand on my soapbox and shout into the void? Do I need to express I care so others know I care and have picked a side and have opionions on evrything?
I do not care. My opinion does not matter. I can scream into all the voids. I can virtue signal until the heat death of the universe/until I die, it matters not. I don't have the desire to spend the limited emotional bandwidth on giving a flaming fuck about the world around me. I'm not that arrogant or self-centered to think anyone else cares.
Engineers not caring is what leads to people working for scumbags who build socially poisonous technology.
What if I told you I was a stay-at-home dad?
> Saying "because they vibe coded we are dropping support for Bun" sounds political.
I don't think "political" is necessarily a bad thing. Engaging in politics is how you shape the world. The mere act of writing and maintaining yt-dlp is quite political considering the context of IP law and enforcement that we live in.
It happens that in this case that I'd disagree with their politics if that's why they are dropping Bun support - I think there's a great deal of value in moving to memory safe languages, little harm in accepting anthropic compute and funding to do so, and that use LLMs themselves is roughly value neutral (though many uses are very much not value neutral). That said reasonable people definitely disagree with me.
vibe coding isn't a political topic lol
this amounts to "i don't trust this dependency anymore, so i'm cutting it out for my own good"
that's fine
That's not what I meant by political. I meant political in the more modern sense of "appealing to emotion rather than thought".
EDIT:
Everyone is rightfully calling me out that this doesn't make a lot of sense. What I meant is that the move is driven by ideology. I think there is a lot of overlap between politics and ideology, and an increasing amount of overlap between ideology and emotion. But it's fair enough to call me out here.
> I meant political in the more modern sense of "appealing to emotion rather than thought".
I'm not familiar with this definition in any modern or archaic sense. Is there somewhere I can read about it? Just because a decision is not directly engineering related (which I'm not even convinced this is) doesn't mean that it's not thoughtful.
That's fair - I updated my comment a little. What I mean is that the decision was driven by an ideological basis, not an empirical one. Bun was written with AI, AI doesn't fit with my ideology, therefore I reject it. As opposed to Bun has these new problems X Y and Z, therefore I reject it.
The irony of this comment on an app that is:
- free and open source, which is an ideology, and that
- expands access to otherwise locked down media, which is again an ideological stance
"Political" here means "I don't like it"
I can't see how this counts as "political" or "ideological" by your definition unless you believe that emotion can't exist as part of any decision, in which case you should give up interacting with human beings entirely.
Regardless, the decision was 99% logical. In fact, even the emotional parts are laudable. For example, I love software. That's an emotion. If you disagree with that foundation, we will fundamentally never be able to converse with each other about what's best for software.
The opposite of political would be someone saying "I have observed that Bun has X, Y and Z bugs -- therefore we are no longer support it". An example of this is the recent announcement that Ghostty is leaving GitHub[1]. Compare and contrast the rationale:
> I've felt this way for a long time, but for the past month I've kept a journal where I put an "X" next to every date where a GitHub outage has negatively impacted my ability to work2. Almost every day has an X. On the day I am writing this post, I've been unable to do any PR review for ~2 hours because there is a GitHub Actions outage3. This is no longer a place for serious work if it just blocks you out for hours per day, every day.
That isn't ideological in the slightest. Count the X's, and move off once you see too many.
[1]: https://news.ycombinator.com/item?id=47939579
But unless you're doing that for every service you use (and not just the ones that annoy you), that's still the same logic. Deciding to count something is just as "political" (as you put it) as choosing to not count something.
Whole OSS is driven by ideology. It does not exiat without ideology. And not just that, whole massive development companies are driven by ideologies.
OpenAI itself is a bundle of ideologies and pretend ideologies. Thw whole puah for AI and AIG is way more about emotions and ideology then about business ir engineering.
Wait, expecting all code to be verified and tested by a human is not engineering-driven but instead emotion-driven mindset???
What code is fully, or even primarily, tested by a human? Haven't you heard of automated testing suites, regression testing, conformance testing..?
Test code written by a human counts as "tested by a human". Also, most code is literally tested (manually) by humans in addition to automated tests. You are being pointlessly pedantic.
Bun has a test suite of tens of thousands of tests. For purely non-functional changes, like refactors or rewrites (e.g. a Rust rewrite) I rely primarily on test suites, not manual testing, in order to ensure that nothing regressed. I mean, sure, I am going to poke around, too, but the test suite is the encoding of thousands of obscure bugs and issues over years. There is no way my manual testing will be able to cover the same ground.
> Test code written by a human counts as "tested by a human".
Were Bun's tests generated by an LLM? If they were, were they read by a human afterwards to be validated?
Publicly based on my calculations[1] there only ~20k tests. I would say they are usual tests for the runtime. Constantly running on the CI much lesser amount. Average test count/line of code ratio drops after rewrite. And even before Node have denser tests count/LOC ratio
[1] https://kant2002.github.io/en/llm/2026/05/16/bun-pr-analysis...
If I were to mirror your tone, I'd ask you if you've ever heard of the basic courtesy of running your code manually yourself before you waste anyone else's time with it... Or whether you've heard about QA, or about making demos for Product or for customers...
Neither of these can be replaced by an automated test suite of any kind, and all of these are examples of good engineering practices that guarantee software quality.
Additionally, even if you don't (need to) adhere to the best engineering practices and instead rely solely on an automated test suite, the tests in this suite must be validated - read and understood - by a human in order to guarantee that they nail down the correct requirements.
[flagged]
That has nothing to do with what "politics" means but it's exactly how people have started using "political" to mean "idea I don't agree with".
I think there is a lot of overlap between politics and ideology, and an increasing amount of overlap between ideology and emotion.
I think it's fair to call me out for skipping a step, but I wasn't using it to mean "idea I don't agree with".
>I wasn't using it to mean "idea I don't agree with".
I believe, maliciously or innocently, you were.
> I think there is a lot of overlap between politics and ideology
What is politics without ideology?
Power struggle. Lying about manager from other team so that you look better. That sort of thing is regularly called politics.
In software engineering the word has also long meant "a decision not made purely on technical terms"
Humans have always appealed to emotion - as part of their logical process.
Fear (emotion) is used (advantageously) to force us to check that something isn't going to break us
In this instance fear is being used to ensure that yt-dlp is not exposed to (genuine) concerns about the quality of bun that is openly being built making use of tools we as a whole know is problematic.
I agree with you that the statements are a bit over the top (that's an emotional response to their statements btw) and that (eventually) you would /hope/ that bun gets to a point where it's got some genuine reliability from a users perspective.
Edit: I see your edit to explain that the issue is ideology - but unfortunately (perhaps) that's not an improved stance - ideology has to guide us when we just don't know - it's a heuristic.
That's a perfectly cromulent meaning of the word.
Vibe-coded code is a code no human has written, so no human truly understands how it works. It's a perfectly reasonable technical decision not to support such software, especially if actual human effoft is required for that
I wouldn't have problems with AI-generated code, but LLMs are not AIs, they are random sentence generators. They don't have logic, yet programs are logical constructs. So let's call this what it is: randomly-generated code, kinda sorta filtered by humans and tests. It's not because the output distribution has a good match with the expected distribution that it's not random. An LLM that is "hallucinating" is still working perfectly well and isn't doing anything different, in the same way that a straight-line fit through data points isn't "hallucinating" where it isn't overlapping the data points exactly.
> I wouldn't have problems with AI-generated code, but LLMs are not AIs, they are random sentence generators.
AI includes a lot of technologies, LLMs being just one of them. Several of these technologies use probabilistic algorithms, so having randomness does not disqualify something from being classified as AI.
And I didn't say it does. Intelligence is not necessarily deterministic, and being random is not the problem with LLMs. The problem is that they are not intelligent: they statistically mimic reasoning and logic, which still could have been acceptable except that they don't generalize well and have double-digit (at best single-digit) error rate percentages.
They also have the worst possible failure mode imaginable: Producing erroneous output that looks perfectly fine and expertly-crafted.
Imagine a food synthesizer machine. You press a button. 80% of the time you get a chicken sandwich, 20% of the time it beeps an error. That's OK. With the LLM version of that, 80% of the time you get a sandwich, 20% of the time you get what looks like a perfect sandwich except that it contains bits of plastic and metal, and you have to start eating it to find the pieces.
"You're absolutely right! Food shouldn't contain bits of plastic. Let me synthesize that again."
I wouldn't say it's random. But I do like referring to them as statistical code generators.
I'm repeating a point I made in a sub-thread but please WHY should the onus be on yt-dlp to review their decision on a project that has zero commitment to review their very code?
I get the idea to "battle-test" the rewrite first but (a) how does one even determine a reasonable timeframe for battle-testing that much LOC and (b) each vibe-coded update pushed to the Bun upstream basically resets the battle-testing timer. I guess you could lag behind $LATEST by a given window but that just brings us back to (a).
Adding support again later is cheap.
Stopping maintaining and testing support for upcoming versions is cheaper than doing that work.
Sure it’s political but it is also just a sane approach, to stay away from such disruptive change and treat it as wait-and-see instead of tagging along for the ride. There is not really any technical upside to tagging along and promising support.
> Stopping maintaining and testing support for upcoming versions is cheaper than doing that work.
If it’s based on predictions of how some alpha software might turn out in the future then I don’t see how you can claim it’s cheaper.
If a bunch of new bug reports came in then you said no, then everyone would understand.
This is pretty obviously ideological otherwise. Which is fine, but we shouldn’t pretend otherwise because we might agree with it
I think it's perfectly rational to take a wait-and-see approach when a dependency has been completely rewritten from scratch.
That would still be rational if it had been rewritten by hand, and not by an LLM.
This isn't a wait and see approach, this is proactively removing it
It's "we support 4 JS backends, we don't have the capacity to support 5 currently". They're not dropping bun entirely, instead bumping the minimum bun version and not supporting "bunv2" because they don't want to be beta testers.
Has the team announced that they're breaking backwards compatibility, or that testing will be reduced?
I disagree it's a political stance, this reads like a technical decision to me. In my opinion, there is no vibe-coded project that's going to be reliable long term. Eventually there's too much code, too many bugs and the whole things slows to a halt. Or it gets too expensive to continue to be vibe-coded, because token cost.
If they had decided to drop Bun for "AI assisted coding," that might strike me as a political decision.
What does "political" mean in this context? To me it seems obvious that yes, that is a political choice, as is every other choice a group of people make for themselves together.
That wasn't my read, though. I think if they don't want to go with the vibe-coded version then they have to go with the last release before that. And presumably that last release won't be updated (except with the vibe-coded version). Therefore it makes sense to deprecate.
What's wrong with yt-dlp - an app almost entirety driven by political stances - taking another one regarding llms?
“Vibe coded” means “human programmers did not review the code”. So I think that’s an entirely reasonable line to draw that’s no more political than dropping support for some other project that suddenly decided to drop all unit testing or to refuse to do any security vetting.
> It seems a bit unfortunate to me that they've apparently already intending to never support future releases instead of planning on re-evaluating in the future. On the other hand the yt-dlp developers definitely don't owe anyone anything.
The other side of this is that as far as I'm aware, Bun support in yt-dlp was always experimental. They mainly use Deno.
It's not really political. Or let me rephrase possibly yt-dl is being political. VUT the concept of 'not adopting a core dependency until it has been widely used in production for 6 months - a year.', is not a political on general. A full rewrite of 1 million loc is essentially a new runtime that has the same ABI as the previous and for many downstream consumers it's not something they are comfortable taking a production dependency on. If for sale of argument BUn was fully rewritten by hand would be the same situation. I personally think this kind of decision is pretty standard, I also personally think the Bun LLM rewrite will be of good quality overall, but I certainly would not bet my product/company on it. I want to be the one making the risky changes on my software not being forced into it by downstream deps.
I think your stance is more reasonable than the one in the article, TBH. If yt-dlp said something like "We're going to wait 6 months on the Rust rewrite", that would be reasonable. But instead it says something more like we think that Bun is vibe-coded, so we don't want to use it any more. That seems less reasonable.
It's not less reasonable. They don't have to promise giving Bun time in the future to evaluate. They might do it but they absolutely don't have to be responsible for doing it when the project made such dramatic shift.
They can do absolutely what they want with their project especially when its majority decision. There can't be no doubt about that.
They can absolutely do what they want, and I can absolutely say it's an unreasonable decision. When I say "unreasonable", I am evaluating whether they are operating on sound technical principles or not - not like, "are they allowed to do this" or something more obviously true.
Why is it unreasonable, from a technical standpoint, to avoid vibe-coded software?
To me, proving a vibe-coded piece of software is fit for purpose is much more difficult than if it is human-written, or LLM-assisted with a human reviewing all the generated code.
Welp, I mean once the Rust rewrite is merged, isn't it vibecoded? Fair enough, it was vibecoded from a pretty detailed Zig specification :)
I think it's fine to not depend on code that nobody, even the maintainers, has read. Is that really controversial?
I do find it ironic you think this project is making rash decisions on no technical merit, and not Bun
> A full rewrite of 1 million loc is essentially a new runtime
It's not a rewrite exactly. Nobody wrote anything. Not a single human has even seen, much less understood those 1m lines.
Who or what does the writing doesn’t determine whether it was a rewrite. It was definitely a rewrite. Maybe it was 100% automated. But it’s a rewrite.
Even re-written by hand isn't the same because a hand re-write proceeds slower over a longer period of time with more smaller updates that get tested somewhat along the way.
Also I don't think it's wrong to use an action as an input to judging engineering character. That could be read as judging yt-dlp or judging bun but in this case I mean it's reasonable to judge bun's developers.
IDK if i'd personally judge this action quite so badly though. It depends how they went about it and what they proffessed to get out of it.
I am very much against letting llms think and decide for you, but I don't think it's so wrong for an actual coder to employ automation.
But if they are acting like it's magic and everything will be so much better after the magic llm uses the magic safe language... yeah that definitely gets the side eye. Or no eye. Just no longer interested in or concerned with their output.
Since this is being offered as the next release version while still being new and stuffed with unsafe, looks like it's the latter. So I'm with yt-dlp in this case.
It doesn't matter if the new code happens to be ok or not, it's still a problem that they got there by hoping a black box does the right thing. A black box that that no one wrote and no one understands, not just themselves.
gcc is a black box to me, but I know that someone wrote it and understands it (or some people collectively understand all it's parts), and I know that any time I want, I can choose to understand any part of it, and satisfy myself that it is doing something both sane and deterministic.
So a developer choosing to use gcc when it's a black box to them does not reflect badly on them to me.
But no one can say that about any llm or ai. So yeah, a developer choosing to use them, depending on exactly how, may reflect badly on them.
The same was true for cheap off-shore gig coding by humans too. I have tried to use them myself in the past, hire out for small generic programming jobs using those web sites where you put up some escrow money and post a job and people bid for it, you choose one, they do it and get paid from the escrow. I only tried about 3 times for the same small job and every time I git ridiculously shit (but technically functional) results.
These were humans 15-20 years ago, no possibility of hidden ai usage like today, and it's essentially the same dynamic of just hoping some magic will get you something good for cheap, and accepting any result that appears good as good.
If someone said that that's how they made their product, I would decide that product is probably pretty crap inside and no way should I buy it or invest in it as a dependency if I have any choice.
And that's humans not ai. The problem isn't really the ai, it's the judgement to use an ai that way.
Every accusation is an admission, isn't it? As always with these cases, the rhetorical contrast is staggering compared to the thread about Bun deprecating Zig.
Bun made a snap decision to merge 1M lines of unreviewed code within a week, including code generated moments before the merge. AI or not, that forces downstream users to cope with total unpredictability. This process bears no resemblance to science or engineering.
All the QA work you're demanding of yt-dlp is work Bun should've done. Trying to flip that responsibility proves your argument isn't grounded in engineering principles. And you sure made your feelings known in your comments for someone who claims not to let emotions affect technical decisions.
yt-dlp made a sane technical decision to drop a high-risk dependency. Not only is the Bun code now unpredictable, but the maintainer is too. The maintainer called the rewrite "experimental," then merged it within a week. If direct statements can flip overnight without warning or explanation, it's no wonder downstream projects want out. Especially when yt-dlp already supports alternative JS runtimes.
If you wait for more segfaults, OOMs and other issues, than you have failed to avoid the problem. In my opinion this direction is correct and history will show who's right.
When expressed, sounds like a trivial principle. It's surprising how rare it is to see people actually do this. Not only with tech stack: choosing cars, laptops, staying in a toxic relation, the list goes on
Notably, they aren't (yet) dropping support for older, pre-rewrite versions of Bun. They also could be leaving the door open to support Bun in the future, if the rewrite proves successful. I think waiting and seeing is the right, conservative move.
If that was how it was phrased I think there would have been less push back, but that's not at all how it's been communicated. There is no assumption to rereview at a later date at all given the focus on the AI usage etc.
If they said we will rereview in 1-6 months or whatever the whole discussion would be mute.
Why should yt-dlp commit to review their decision in the future about a project that makes no commitment (that I've seen) on reviewing their source code?
I get the idea to "battle-test" the rewrite first but (a) how does one even determine a reasonable timeframe for battle-testing that much LOC and (b) each vibe-coded update pushed to the Bun upstream basically resets the battle-testing timer. I guess you could lag behind $LATEST by a given window but that just brings us back to (a).
Given that part of their announcement is to keep supporting pre-rewrite versions of Bun, it implies to me that they are open to reconsider if the Bun team cleans up their act. I don't think it could get any more reasonable than that.
> This decision seems to based more in politics than engineering.
Project governance is very important on a project; the fact that Bun's authors bent the knee to their new owner shows where their priorities lie.
> Have you observed Bun have more segfaults, OOMs, etc, since the Rust rewrite? Have you noticed more security vulnerabilities? Have you seen more bugs?
I - them - are not going to sit around waiting for bugs to start crashing everything
> I don't select my engineering tools because they give me a bad feeling - I select them because they do the thing I want them to
Good thing that you don't run an open source project then, I would remove anyone's project from my dependencies who thinks like that.
It really is amazing to me how many developers do not understand that governance is important. If I have a dependency and a maintainer of that dependency has a process I can’t trust, it’s perfectly valid to remove that dependency based on that lack of trust.
Not caring about governance is how we end up with repeated supply chain attacks.
Reading and understanding code is more difficult than writing code.
It is significantly easier to modify code that you personally wrote, or code that you have read and understood to fix an issue in previously. This is why the maintainers of a project change slowly over time and it takes a long time for new ones to get up to speed.
All of Bun has been rewritten by a tool. In a different language that maintainers may not be fully proficient in.
Even though the rewrite was done well, and even if we assume it's functionally equivalent to the old Zig code, there will still be future issues. And ALl of the maintainers are essentially now new hires who have never seen that code in their lives.
It's not "politics" to have an ounce of sense to foresee problems in such a project as a dependency.
A key element of engineering is projecting a current trajectory. Given that, it absolutely makes sense to avoid tools that give you a bad feeling. The easiest time to move away from a tool that will become a train wreck is before you've integrated it.
But what exactly are you projecting? Typically when people have said they have a bad feeling about something (imagine Next.js) it's because they are running into more bugs or they are seeing more production incidents. In this case there has been no chance to observe these things.
Bun in its current state absolutely has issues like segfaults. As nice as it is, I moved off of it back to node for production.
Folks generally tolerate issues if they believe they’ll get better with time. I know I did for a while. If that confidence collapses, that’s not politics.
But there's no evidence of that in the post. If they had said something like "Bun had bugs X, Y and Z - this Rust thing is the last straw, it's over" -- that would be a reasonable decision, and no one could really complain. But they didn't say that. They just said it "seems like a future headache".
Are we reading the same post? They literally point to bugs X and Y.
I don't see politics, I see frustrated maintainers of a hobby project that aren't particularly professional.
Engineering decisions and the resulting output.
We've known for decades that machine-translated code is garbage, and should only be done as a last resort.
Your HN account is too new for me to be sure whether you're being sarcastic or not. Perhaps you know, or perhaps you don't, that all code is machine-translated, even assembly language. None of it is perfect, but it's not garbage. Today's AI merely provides a new level. It's a weird, non-deterministic level, but hiring an employee to write code for you is similarly non-deterministic.
Right, and that's why Mel was a true programmer!
Seriously though, that's an overly-pedantic definition of a compiler. Broadly speaking, languages compile in a direction of decreasing abstraction. Crossing from one high-level abstraction to another is just asking for trouble, especially in this case where the target language makes very specific performance promises as long as certain abstractions are maintained.
It's 1mloc that no human has seen. There is no possibility for that project to be reliable, at least initially.
“You're absolutely right! I've seen things you humans wouldn't believe.”—Claude Opus 4.7
Then Bun's rewrite is also political. They couldn't upstream their vibe coded "improvements" so in spite they decided to vibe a rewrite in Rust. The arguments for the rewrite were not backed by any data.
> They couldn't upstream their vibe coded "improvements"
What are you talking about? There is no upstream rejecting contributions here. It's the original bun developers who vibe-ported it to rust and they absolutely could and did upstream their vibe coded changes because they are the upstream.
they're referring to the changes they tried to upstream to zig.
To be fair, I don't know if the Bun team ever did try to upstream it. In their Twitter thread announcing their vibe-coded fork of the Zig compiler, they said they wouldn't bother trying to upstream their changes because of Zig's policy banning LLM-authored contributions. Still probably a calculated political move to cut ties with Zig and muster community support for a Rust rewrite. https://x.com/bunjavascript/status/2048428104893542781
They did try upstreaming to Zig, but it was rejected for already being implemented not because it was vide coded.
https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
Bun were so excited about their 4x speed improvement that they missed that Zig had already implemented it, plus other optimisations that were far larger.
The changes submitted to zig were rejected because they were off an old fork and had already been implemented.
They may have been rejected for being vibe coded if they were original, but they were rejected for being pointless. The rust rewrite was because Bun was butt hurt that they didn't actually help.
Every single macOS update the top comments are about giving it six months to stabilize, but when a program’s biggest ever rewrite involves a lot of AI, the top comment is calling you irrational if you don’t YOLO it, and probably a jerk, too.
I didn't say you were irrational or a jerk.
But this also isn't a fair comparison. The article doesn't say "let's wait 6 months", it says they are fully deprecating Bun. Those are two very different statements. I would have had no issue with the first.
And FWIW I think my viewpoint is the uncommon one. Look at all the responses to a previous thread about it [1] and see how many of them are negative. It's certainly a majority.
https://news.ycombinator.com/item?id=48133519
I don't know if your viewpoint is uncommon or if the vibe-coding hating crowd is just louder.
YOLO? Bun has an extensive test suite and this implementation passed the test suite.
Can we at least try to be a bit more accurate and less hyperbolic?
I will continue to use Bun because the same people that made bun have made this decision. I trusted them one week ago. I have used bun for the past 2 years, and so have many others.
I'm not about to just assume they've become immature idiots yolo'ing stuff overnight. They're still the same people they were a week ago. Or two weeks ago.
Program testing can be used to show the presence of bugs, but never to show their absence! Dijkstra (1970) "Notes On Structured Programming"
LLM generated code is garbage, not because it writes obvious errors. But because it lacks any kind of reasoning - Claude will gladly write you a solution for a problem you never had. Good luck fixing these kind of issues that will never be catched by tests.
>> same people that made bun have made this decision
Are they the same people though? Their interests, goals, environment, incentives, boss etc etc all changed after they got acquired by Anthropic. Its not uncommon for a big company to acquire a smaller one and completely destroy that product to serve the parent company's goal.
You can go read all the details on Jarred's X account - including the progress, how it was thought out, strategy, that they're aware that it looks like zig still, etc etc etc.
Speaking of environment though, everyone neglects to mention that the Bun core team now has access to Claude Mythos. You think they haven't already run Mythos against this? So they have private access to the best cybersecurity scanner known to man.
Suffice to say, I'm yet to see anything that really worries me in any major way with this.
I've read the details, strategy, extensive test suite etc. I'm sorry, I don't think "they have access to Claude Mythos" is the rationale to it unless you truly believe the marketing 100%.
I think we'll just see how it all turns out. Maybe check back in a year or two on hwo it all goes. Anyone who says they "know" or are "very sure" this is the right path or wrong path is plain stupid IMO. Having seen how things work in big companies with high market visibility, I believe there is non-trivial chance this driven mostly as marketting stunt (particularly in current climate) and decision isn't purely based on best interest of Bun's future and longevity.
jarred two weeks ago: "we're probably not going to merge any of this" jarred a few days ago: "bun has been rewritten in rust"
thought out?
> YOLO? Bun has an extensive test suite and this implementation passed the test suite.
I'm sure macOS has an extensive test suite that Apple runs as well, and yet still people suggest waiting a bit before adopting a new macOS release.
An extensive test suite can prove that you have regressions when you change the code, by showing you one or more newly-failing tests. However, it cannot prove that you don't have any regressions; it can only increase your confidence somewhat.
Presumably MacOS has an extensive test suite that it is passing before each disastrous release. Tests matter, but they aren’t the entire story.
> this implementation passed the test suite
Didn't they also change the tests to make the re-write pass?
They did, but they also reverted most of those changes.
I don't think refactoring 1M lines of code into another language within 7 days and merging it to master is responsible. I won't make my code depend on it.
It's not refactoring. It's LLM transpiled.
I think the correct term is *translopped*
[dead]
FYI in case you aren't aware, the rewrite was shipped, and then had to be reverted due to issues being discovered. That's "Jarred's high quality bar" you're so confident in.
The whole point of having canary builds is that they're unstable. That's why they're called canary. Rockets failing in test flights isn't a bad thing.
It absolutely is a bad thing. That's why so much effort goes into designing and manufacturing rockets correctly. So the tests go well and you can move onto actual launches. Using that as a metaphor for canary builds displays a lack of knowledge in just multiple areas lol.
[flagged]
It is a bad thing. It is good that the rocket doesn't fail during the test flight.
> Rockets failing in test flights isn't a bad thing.
I hate to be pedantic but for a whole host of environmental reasons, they are suboptimal, and it still incinerates money to lose a rocket during a flight test.
Yes, building rockets costs money and is bad for environments.
Yes, exactly this. SpaceX are super environmentally irresponsible, I wish they would follow the ESA/NASA development model that is so much better for the environment! So European.
Can you link me a source that says that the rewrite shipped to a point release (not canary)? I'm not seeing this.
News to me… share a link?
Every decision is made with imperfect information about the tool, its future, and your current/future needs. This is a normal type of engineering decision.
Bun being replaced entirely with stochastically generated code is red flag (regardless of whether it was or not). But Bun was also acquired by a huge corporation, which has been classically a huge red flag. Both of these are plenty of reason for yt-dlp not to support Bun.
In either case, this seems like a niche use case. I've used yt-dlp for years and I've never used Bun with it. If Anthropic really wants their recent acquisition to be supported in yt-dlp, it can fork it and support it itself.
> I don't select my engineering tools because they give me a bad feeling - I select them because they do the thing I want them to.
With that in mind, is there anything that yt-dlp uses the Bun runtime for which it can not use the other supported runtimes for? Similarly, perhaps the yt-dlp maintainers shouldn't keep supporting Bun just because it gives them a good feeling when every runtime incurs a maintenance cost.
That said, as a developer I skim over so much bullshit simply based on "bad feelings". I don't have time to evaluate every potentially useful technology in terms of whether it does what I want it to do, and no one else does either. It's clear to me that Bun is in an experimental phase of development and I think that's a good enough reason to move on if your use case is not.
“... it seems unlikely he would ship this rewrite if it didn’t meet his quality bar” is every bit as vibes-based as the decision you are critiquing.
Jared has shipped a lot of things that have impressed me. His software is measurably faster than the alternatives, and I have measured it. It runs code that Node et al can't run, and I have tried. These are normal, everyday experiences with software - based in fact, not vibes. I'm not going to argue every decision he's ever made is amazing, but his decisions have historically tracked above average.
He plays around with a toy project in a separate branch, tells everybody to relax that's just an experiment that has no chance of being merged, then abruptly merges 1m lines of code not seen by a human, effectively zeroing out all the contributions ever made by anyone to bun, including contributions in progress.
At the same time, his arguments in favor of Rust are sound, there is no doubt about that.
>that's just an experiment that has no chance of being merged
Yeah he never said that.
> It runs code that Node et al can't run
What kind of code can't node run?
Bun supports import and require together in the same file https://bun.com/docs/runtime/module-resolution#using-import-...
So, you're fanboying?
If we're gonna fight, lets go xbox vs playstation. Javscript runtimes are a snoozefest.
Stating e.g. "Bun is more performant than Node [along a particular benchmark]" is not a fanboy statement. It's a statement of measurable fact.
> it seems unlikely he would ship this rewrite if it didn't meet his quality bar
What happened to
> don't select my engineering tools because they give me a bad feeling
Who cares if you have a good feeling about this dude? There are obvious and clear conflicts of interest at play here. If you care at all about quality, you'll wait before adopting new releases until bugs get discovered/ironed out. Don't adopt based on some dude's reputation when that reputation was built under a very different incentive environment.
Why wait?
Seems reasonable to preemptively drop support and let someone else either suffer the fallout, or get proven wrong and just pick up support again. It's not for a lack of people motivated by IA. Unless the motivation is more "use my IA generated content" than "actually consume IA generated content", of course.
Not sure what seems "political" about this.
When deciding to support a given thing, you have to make a determination as to whether it's worth the effort or not.
You don't simply ignore unknowns. That effectively means assigning the unknowns zero cost, which is unlikely to turn out to be true. Generally, the more unknowns, the higher the risk, and the higher the risk, the higher the estimated cost.
There are a lot of unknowns about vibe bun right now.
One effective strategy for dealing with unknowns is to turn them into knowns if you can. Here, that probably means waiting to see how vibe bun turns out.
If it turns out to be stable and highly compatible, at some point in the future, they can always pick up support then.
> I don't select my engineering tools because they give me a bad feeling - I select them because they do the thing I want them to. If Bun starts having more bugs and feeling like worse software, I'll stop using it. But I will base that on data -- not a feeling I have.
being reactive is fine if you can tolerate issues. otherwise, you need to be proactive -- don't wait for the train to hit you before you move off the tracks
I wouldn't call it politics. I've seen enough people aim a gun at their foot and pull the trigger. They'll never thank you for stopping them, they just want to be left alone while they do it.
So, great, if this dude wants to regress through the workforce to a level of engineering maturity I associate with a high school student, I don't wish to try to be the one to stop him. Doesn't mean I'm gonna follow him. It's possible to be smart enough to just not walk into the tarpit. He's going in, I'm not.
You can’t really tell if you got sick from dirty hands, a week old egg, or the cheeseburger you had for lunch, but if Shake Shack had also just announced they’ve moved over to vibe-cleaning their kitchens then it’s reasonable to only eat at Five Guys from now on. Let someone else iron out the kinks.
Anyone who merges such a huge PR of ai generated code doesn’t deserve trust. This is a real black box now, even for the developer himself.
It is entirely rational to not use a completely new library no one yet confirmed is good. And complete agentic rewrite makes it completely new thing.
The argument that you somehow cant unless you go through trouble of testing it is way more "politics" and way less "engineering".
What world do you live in where selecting your dependencies doesn't involve personal judgment calls?
Those judgement calls are driven by things like “oh this is too slow” or “oh this API is a mess”.
> This decision seems to based more in politics than engineering.
Will you use untrustworthy dependencies in your project, which has users? I think, no.
I don't know, but I feel that this is the case with yt-dlp.
And this is absolutely engineering - care about quality and security of your software, which is used by thousands of people
a vibecoded rewrite right after being acquired is not political?
Is it so unthinkable to people on "hacker" news that someone might want to try a cool experiment like rewriting an entire repo into Rust?
Is it so unthinkable that people don’t want to participate in that cool experiment?
Most commenters here don't have an issue with Rust.
The 1M lines of code refactor by AI in a week or so then thrown into a production codebase... Yeah
Cool experiment? true
Cool production? false
No one says that? Of course Bun rewrite is political. And if you deprecate Bun support due to they did something political, obviously this decision itself is political too.
the bun team has recently demonstrated a lack of agency over their project. making massive structural changes with unclear and misleading communication. There is nothing political about seeing that as a red flag and deciding to rely on more stable projects.
> This decision seems to based more in politics than engineering.
I'm glad some engineers realize that technology is inseparable from politics. It always has been. All evil came from engineers who beleived they were above politics. Selecting the tool which got the job done/made the number go up/paid a paycheck is how we got Facebook, Google, Palantir, crypto, AI, techno-fascism and neo-feudalism. None of it would've have happened without engineers blindly applying their knowledge to achieve "purely" technical results, while ignoring the social consequences. With the hindsight of the last 20 years, anyone who still advocates for an irresponsible adoption of technology should be considered automatically suspect
> I don't select my engineering tools because they give me a bad feeling - I select them because they do the thing I want them to
Among tools that meet a technical expectation—especially for (often) superfluous activities like downloading videos—I pick one that feels right and costs the right amount, and that's the one that wins. Free + works + usable is an unbeatable combination.
However, I'd argue their decision is related to a peer dependency than it is itself one about an engineering tool, which is an assessment of the risk surface and potential cost associated with doing so. I already wasn't using bun at all, but if they stopped supporting whichever runtime I do use, I can either adapt or stop using yt-dlp, which I won't because this isn't a technical thing worth wasting much time on. This mild, recent change to recently introduced peer dependency integration is largely inconsequential, and I support the call to not waste time providing extra support if it hypothetically became necessary.
I would argue the opposite. The decision to rewrite was based on politics, and the decision to deprecate support was based on actual engineering.
You may not want to take part in politics, but politics wants to take a part in you.
>I don't select my engineering tools because they give me a bad feeling
But you do select your engineering tools on faith apparently.
> I select them because they do the thing I want them to.
Regardless of the other aspects, this is a joke in any context I have been in since I started working in this field about 9 years ago.
Even as pure logic, you know they do what you want it to do only after you chose them. You can’t possibly be trying every option to the fullest capacity of your application.
You also converge on the “Jarred” aspect and the guy that made the decision in the title post has the opposite sentiment
> I don't select my engineering tools because they give me a bad feeling.
Those bad feelings are often your years of experience trying to tell you something.
I have no idea how that’s what you get from this. I don’t want my project using any tech that decides to take 6 days to rewrite the entire library with AI. That is at its core an engineering decision.
No healthy engineering team is going to do that. And I’d want to distance myself as far as I could from a project that behaves like that.
> Have you observed Bun have more segfaults, OOMs, etc, since the Rust rewrite? Have you noticed more security vulnerabilities? Have you seen more bugs? (Of course you haven't, the rewrite hasn't even landed yet.)
Your argument could go other way too. Why haven't they landed if they're so confident with the change?
The first sentence on the linked page is literally: "Due to foreseeable compatibility and security issues"
> I don't select my engineering tools because they give me a bad feeling
I do, for example when I see constant behavior of lying, or negligence for security issues or not considering valid PRs and rewriting it to fit their paid plan and so on.
> I select them because they do the thing I want them to.
This is one of the dimensions when I pick the tools, I know Oracle produces nice products, but I don't want to get sued if I do something accidentally their lawyers dislike.
So, let's see here. Here we have a program, that is used to install scripts from source that has been targeted, and breached multiple times last few months, can run arbitrary code on millions or billions of user computer, servers. And, it was ported to another programming language, resulting in 1m LOC, in 7 days for publicity stunt of a LLM company
Even multiple people can not go through 1m lines of code for any kind of vulnerability in 7 days, let alone 'observe' more segfaults, OOMS, unsafe behavior, on who knows how many possible ways things can go wrong in this new condition.
Only guaranty is 99% tests passed, and the engineer who is paid by the same LLM company.
How in the world, any sane engineer would agree, this would be remotely a good idea to continue using this tool, for a chance that such a expensive change won't actually land in production?
Everything is politics, sorry to say. Even software engineering try as we might.
> feeling like worse software
Politics ;)
As far as I'm concerned Bun has been extremely irresponsible with this entire rewrite, and it calls into question their entire development philosophy. Any project that cares about stability and reliability should steer clear of Bun for a while.
> I will base that on data -- not a feeling I have.
and yet...
> If Bun starts having more bugs and feeling like worse software, I'll stop using it.
Is it not possible to judge that certain approach is more likely to bring unforseen controlable problems than another by analyzing how it works without assessing it's output? No "feeling" is needed
I believe you contradicted your first point by following it with "If Bun starts having more bugs and feeling like worse software"
...so you do use feelings in your calculation? To be clear, I have no problem with that and think there is some level of speculation you need to do when deciding what to rely on.
As a hypothetical, pretend that Bun added obfuscated binary blobs that get executed at build time. Well, your code still works and no effects show up at runtime. Are you going to keep using it or dump it based on the "feeling" that something isn't right?
Bug counts are numbers. Memory usage and performance are numbers. Eventually those numbers get so bad that you leave.
Well if you promise support you promise support.
You cannot take back a promise after you make it. So if you discover bugs later you cannot just leave.
This script is just a JavaScript helper to bring full YouTube support to some media download tool. It does not seem important to anyone that executing it using Bun is supported. They support the Deno and Node runtimes.
The rust rewrite isn’t even out of canary IIUC.
Isn't that what Bun/Anthropic did? A rewrite based on vibes?
Except "because we can" and the expectation that some kind of bug will be reduced and other metrics will not get worse
All Bun devs are happy to change programming language?
When their competition is already in rust and more mature
While using the LLM that is now paying their salaries. Kind of a conflict of interest
Even a major version upgrade is enough for me not to touch it for 6 months, let alone a full rewrite
Has Bun posted any analysis and shown the data?
> Has Bun posted any analysis and shown the data?
Jarred promised a blog post just like he promised to not merge the slop branch.
absolutely, and `its development seems to have taken a turn towards being fully vibe-coded` ungrounded claim confirms the hysteria, I'm afraid
The whole code base is a vibe coded rewrite, half a year after Bun was acquired by Anthropic.
I see lots of ground for that claim.
I apologize, may I ask you, do you use Bun? If yes, you probably do monitor the development of this project (I do, it sounds reasonable to track your tools/deps), probably familiar with Jared's coding style, decision making process, architecture nuances, previous choices? Do you have any issues opened/closed in Bun's repo? Were you satisfied with contributors' reaction? Do you feel you can trust devteam behind Bun?
I get it if you're trying to defend your buddy, but at the end of the day it's on software to justify itself to me. Not for me (or parent poster) to justify their refusal.
Once bitten twice shy, y'know. Maybe the first bite wasn't even from bun. If bun can't take this on the chin and come back stronger, maybe bun wasn't a good choice to begin with. I'm sure a future version of bun with a rebuilt reputation will have an easy time getting re-adopted by most projects that needed to play it safe during the transition.
There is no evidence that it was "vibe" coded. It was ported to Rust by an expert engineer using an AI tool using solid SWE practices.
1 million lines of code in 7 days = ~6000 lines of code to be reviewed per hour, 24 hours per day.
or... they just trust that their ai got it right, which to most people is "vibe coding".
How can you claim following SWE best practices if couldn't realistically even have read the code?
So transcoding doesn't work unless every line of code is read? That's not how transcoding is done in practice.
"Please follow best practices."
You're telling me that isn't good enough? You might need to head off to the VC reeducation camps.
the speed of the rewrite and various analyses of the resultant codebase provide ample evidence that it was vibe coded and solid SWE practices were ignored
nobody understands the Bun Rust codebase. I wouldn't risk my business on code understood by no person. who is responsible? who will take accountability?
nobody. into the trash with it.
It was not ported by an engineer. It was transpiled by an LLM and no engineer has ever seen those 1mloc.
In 7 days?
That's just agreeing with extra steps.
1 million lines of code written and approved, in 9 days proves without reasonable doubt it was vibe coded.
Those SWE practices were so solid that the rewrite was already rolled back!
What are you afraid of?
I'm afraid "we" tackle (agressively) the wrong problem, also making it's tough for the maintainers, who did nothing wrong (I have a lot of sympathy towards Bun's developers, they got a lot of ugly feedback within the last month). I don't think AI-written code is the problem at all. Human signs off the changeset the same way as it happened before. I don't care if Rust rewrite did happen using pipeline/harness and LLMs, if the maintainer takes responsibility, and in projects like Bun it happens "by default", I think.
I agree with you that AI-written code should not be a problem and tons of open-source projects have AI-written code right now. But do you really believe the way Bun rewrites and merges its code to master is the same as before? The change in rhetoric (from "don't overreact, it's just an experiment" to "merge it anyway"), the never-arrived blog post promised to explain the decision are concerning to me.
I really appreciate the maintainers' effort towards this awesome project. However, I think it is fair to be a little bit less confident with the current state of Bun.
[dead]
A codebase that no human understands.
Yeah this is a cringe way to weigh in on something completely unrelated to your project. Who cares if some random package supports Bun? Compat was always on Bun, anyway.
> This decision seems to based more in politics than engineering.
You are 100% right. This is a decision made on VIBES and not evidence. The proof is here:
> Bun was recently rewritten in Rust using Claude, and its development seems to have taken a turn towards being fully vibe-coded. This is alarming and disappointing for a number of reasons, and frankly it seems like a future headache that we'd prefer to avoid.
They haven't tested it, they haven't found a single problem. They just don't like AI code and they're clearly saying "the fact that the project tested every line of code and it passes all tests doesn't matter to us. The fact that it's vide coded by people who literally make coding LLMs also doesn't matter."
Pure ego, no data.
So a vibed decision to reject vibed code. Minus minus equals plus?
I think you should read what the bun devs published about their process. It's not just vibed.
Care to share a link? There are 0 posts on Bun blog, or the GitHub page README announcing/explaining the rational for the rewrite, or project direction
https://news.ycombinator.com/item?id=48073680
There's been lots of talk about it here and on his twitter and such.
[dead]
Why are some people so pressed about this decision? From my point of view, if you're truly a vibe code enthusiast wouldn't you be able to just vibe code your own better yt-dlp (or fork the existing one and do whatever you need to do with it)?
Indeed. I've heard a lot of words about how trivially easy vibe coding makes building software, and how just about anyone can build something in no time at all anymore. Even stuff about how people will vibe code one-off private software for everything at all times, and such.
There really shouldn't be a reason for vibe coders to complain about any software decisions. Vibe coding a personal fork you better agree with should be a piece of cake. Isn't that part of the vibe code promise?
What's more is yt-dlp already has plugin support for 3rd party interpreters. They're just saying they don't want to deal with supporting bun themselves and the infrastructure for anyone else do use whatever they want is already there.
This is just the standard misguided entitlement people feel towards other people's projects supported by other people's time and effort. It's continually outrageous to me how people feel they can just volunteer other people's time and effort to support their own wants. The people who do the work are entitled to make their decisions and if you don't like it fork it yourself. This has been the way of this ecosystem since it started.
yt-dlp is surprisingly hackable as is.
Because for a lot of AI fans (not all, I know), it's like a religion. They aren't content to live and let live and let history show whose approach to building software is better, they insist that everyone has to agree with them. I have that situation at my job and it drives me insane that honest technical disagreement isn't allowed when it comes to AI.
I see Bun’s Rust rewrite (esp the style how it was done) as a form of massive internet trolling for PR reasons. By making a bigger fuss about it, we’re feeding the troll
We desperately need some new terminology to describe using LLMs to support development work. "Vibe code" has a strict definition but no one really cares. I have a really hard time believing that the Rust port was 100% "vibed" the way the original definition was laid out.
It's a big slushy of emotions that I understand (both positive and negative) but it makes it so hard to actually tells what problem someone actually has when they just use "vibe coding" as a general LLM usage slur.
I'm using LLMs to assist my development and I'm measurably (in all the ways we engineers could possibly care about) doing better work faster.
Vibe coding indeed originally meant "give in to the vibes [...] and forget that the code even exists."
https://x.com/karpathy/status/1886192184808149383
In the case of this specific port, the port was done so fast that it is clear humans did not verify the soundness of the translation. It is not clear whether this manual verification will ever occur.
That being said, most software projects were already doing "vibe coding" by Dijkstra's standards long before AI showed up. Going on vibes and forgetting that correctness even exists ;)
Guaranteeing the correctness of complex code is difficult, but it will increasingly become non-optional as we now have a billion hackers in a data center.
---
Edit: "Bun's unreleased Rust port has 13,365 unsafe blocks"
https://news.ycombinator.com/item?id=48239790
Writing code is rarely the limiting factor in our work.
I think those studies have framing or methodological issue.
I agree the maintenance burden is probably being undervalued by developers in general, but there's just no way the work I do isn't faster. I just categorically couldn't have achieved the outputs I do now in the time windows I have. The software just wouldn't have existed in the world of 3 years ago and I did enough coding back then to say that with certainty.
Surely that argument is dead once someone has migrated a million lines of code in eight days.
Surely that reinforces the argument - there are now a million LOC in a different language, needing stunning amounts of work to validate it actually functions? Writing the code has never been the bottleneck.
There's no uncertainty here. Every day I ask myself how long something I did would have taken without it. The answer is always crystal clear. It's not hard or difficult at all.
Those studies have well known flaws. I'm measuring my output so I happen to know I'm not only going faster, but the quality is better.
I'm not vibe-measuring my output ;)
studies suggest nothing. i've released a massive number of features in the last year for several projects that i estimate would have taken me multiple years to put together in a much more mentally exhausting way.
Your drive-by comments are unwelcome. You can estimate all you want, but the data is collating, and it isn't within your worldview.
It is healthy to question results: That's good science.
This result wouldn't surprise me if the tooling was limited to, say, copilot :)
It would surprise me if it included tooling like Claude Code. Which seems unlikely, given its recency.
[dead]
[dead]
Being conservative with technology choices and only using Node LTS has paid dividends lol
I can’t help but read the logic as not being too far off from: “libfoo switched to being developed using emacs instead of vim so we can’t trust it anymore”
It’s not the same obviously, but here’s why I can’t help but view it analogously:
The only truth in software is whether it works or not for whatever your use case is. Even before AI, we couldn’t have known if the author of a piece of software was proceeding with rigor or just trying random stuff until it seemed to work.
In other words, we didn’t judge someone’s software by inspecting their methodology or what tools they used. Heck, we often ended up using software that had no test suite or where the test suite was junk! And so many of us who are fans of memory safety use tools written in C, and vice versa (I’m no Rust fan but I use plenty of tools written in Rust).
So yeah, the logic that goes, “I won’t use your stuff because I don’t approve of your use of AI” is about as believable to me as if you stopped using something because you didn’t like the authors choice of editor
I don't know how to tell you this, but people actually can and do, in fact, worry about the methods things come to be made with, and make decisions based on if they approve of that process or not. Otherwise the idea of free trade chocolate/coffee/other shit would not exist.
>I can’t help but read the logic as not being too far off from: “libfoo switched to being developed using emacs instead of vim so we can’t trust it anymore”
That's wild. You should read it as being nowhere in the same ballpark nor adjacent ballparks as that.
Yea for real. Like how is it possible to even formulate that as anywhere near the subject matter in any way, shape or form :S
People addicted to chatbots appear to be suffering from cognitive atrophy.
> I can’t help but read the logic as not being too far off from: “libfoo switched to being developed using emacs instead of vim so we can’t trust it anymore”
So let's say they up the ante and set up a cron job to rewrite the entire codebase in a new language on the first Monday of every month: from Rust to C++ to Go to Swift and back again.
For customers using the product, that's basically the same as a maintainer switching editors? Irrelevant detail?
Most people probably think the text editor used would have no meaningful effect on the code written.
I don't think many would say the same for LLMs.
Maybe vibe bun is just as good or better than old bun, but how would we know at this point?
> ...we couldn’t have known if the author of a piece of software was proceeding with rigor...we didn’t judge someone’s software by inspecting their methodology...
That's not true. First, some people do directly check whether a project has a level of rigor they are comfortable with before adopting it (or when deciding whether to continue using it). I personally do it, where it matters. Many more use reputation signals, which, while certainly not perfect, correlate, may be good enough, and are a lot easier than direct, manual reviews.
> Maybe vibe bun is just as good or better than old bun, but how would we know at this point?
By considering objective facts like efficiency, performance, error rates, security vulns etc. like we always do?
There is no such thing as "we always do" now.
We care about those things you listed and also the fact that code was written by (or exhaustively reviewed by) a sentient consciousness. It's just that the second thing has historically been implied. That's the difference you are experiencing.
These objective facts aren't known right now for vibe bun.
Someone would have to do a bunch of work to establish these things.
Do you mind if I vibecode a fresh vehicle control software for your car?
Don’t worry, it’ll just be in a different language.
I don't know how to feel about the Bun rewrite.
On one hand, it seems very scary to me, having most of your codebase unreviewed.
On the other hand, it passes their tests with few regressions from what I heard.
Maybe it's just because I don't have enough experience there, but I wouldn't trust my tests to this degree and completely rely on them without reading the code.
To be honest, I share primeagen's view that LLMs handle translating code from one language to another quite well. As far as I know, they converted the languages file by file. This is what led to such a high volume of `unsafe` code. Although, in any case let's be honest, this is causing, and will continue to cause, various issues. I find it easier to live with this point of view.
He was a software engineer at Netflix before turning to content creation. It is also clear watching his videos that he knows his thing. As an experienced programmer myself, I find his commentary to be way too relatable to be just bluff.
He may not be Don Knuth, Linus Torvalds, John Carmack or Fabrice Bellard. But he is definitely a serious programmer. That he livestreams doesn't make him less of a programmer.
Who cares what you think of someone else’s qualifications?
It’s just someone quoting someone to help ground their position.
What if it was a journalist writing about a security vulnerability then a programmer quoting them, would that count then?
If it doesn't matter, why did the previous poster mention them?
It's pretty clearly a type of argument called an "appeal to authority", where an authority is cited to add credibility to a position. It's usually considered a pretty weak form of argument, but it can be effective. So the credibility of the cited authority is relevant.
> This is what led to such a high volume of `unsafe` code
Which defeats the purpose of having it in rust.
That is incorrect.
Identifying where code is unsafe, is a qualitative improvement. Not guaranteed to be complete, but more complete than a language that does not focus on that concern. Moving forward, the benefits of Rust compound. The concern about AI is orthogonal to the concern about moving to Rust.
Now there are 2 versions[1] that can be instrumented, regardless of the misgivings about AI.
[1] Bun v1.3.14, released on May 13, 2026 (commit 0d9b296af) and current.
I think this is fine with the caveat that if it does turn out the rust rewrite works just as well as before they should start supporting it again.
Say what you will about Rust vs Zig as languages, the Zig toolchain is definitely the easier of the two to integrate into another project.
This doesn't really have anything to do with the merits of the languages themselves, but rather with the rewrite being entirely vibe coded. If it had been from Rust to Zig instead of from Zig to Rust, I expect the exact same response would have happened.
Mostly unfounded in my opinion. They took the _exact_ same strategy that go did when they moved from C Go to a Go based compiler.
First they essentially wrote a translator that preserved the C idioms (so it wasn't idiomatic go) until they had byte for byte output.
Then they started changing code one by one to be more Go-based.
Bun is doing the same. Right now it is mostly a one for one translation of the zig code. Over time they'll make it more idiomatic Rust.
So many people in the comments here are making assertions about the quality of the rust re-write but the point largely remains the same. There is no way you've read all million LOC in the time and reviewed to make sure it really is transpiled. It's not a criticism of the method, but the time and review process.
They foresee potential issues in the future, so they deprecate now? I mean, whatever lol do as you like, but that's an odd choice.
There is an implicit assumption that the other supported runtimes aren't being vibe-coded. Looking at commit metadata tells a different story.
This is such a knee jerk reaction.
Your bank has vibe coded their entire codebase into rust in a week.
The test suites passed so it's all good.
I think this HN submission provides little value and a lot more headache to the maintainers of FOSS project (you can already see a lot of brigading in the GitHub comments). IMHO HN shouldn’t allow submissions like this.
The "to vibe code or not to vibe code" holy war is now in full swing.
war implies "not vibe code" could win. that's impossible
There's literally nothing that LLMs can build that humans cannot. The only factor influencing people to use AI is time. They trade off a small amount of quality for a large amount of time savings. The tortoise and the hare parable comes to mind.
so why arent you using punch cards? are you pretending time is not the most important resource?
What does this use bun for? I thought this was a python project?
They need a JavaScript runtime to execute some challenges that certain pages present (like YouTube)
This title is wrong. It makes it sounds like Anthropic dropped support for and deprecated Bun.
Has bun really shipped using a million line vibecoded PR. I know they merged it, but merging something in a new dir doesn’t mean anything compared to what code is actually running for customers. It’s crazy if the vibecoded rust version is what’s running for customers and not just some experimental hack.
Except it's not vibecoded, it's litteraly the best prompt an LLM can ever get - literal code. If the whole thing ends up as a failure, then it will show that the king is naked.
zig is barely adopted relative to rust. totally reasonable to move to Rust, which isn't as risky of a bet. and you're not the guy having to find their zig memory leaks.
Someone should fork yt-dlp and rewrite it in Rust...and have it use bun exclusively
there could be recommended runtimes, but shouldn’t the runtime be user-configurable anyway?
There is no generic “JavaScript runtime” interface that runtimes would implement, therefore support must be tailored to the specific interfaces of existing runtimes.
At one point we had UMD[0], which effectively provided runtime-agnostic interface, but ES modules were incompatible with that.
Deno and Bun have decent Node compatibility, so couldn't Node APIs be used as the generic runtime interface?
[0]: https://github.com/umdjs/umd
There is another by Meta for react native. Forgot the name.
hermes
Google did something similar with golang. Of course it was a tool based rewrite and they did lots of tests but some bugs still emerged. People should stop being mad about a company that delivers a tool that is about shipping software faster. The world does not resolve around high quality software, the world resolves around things that might need a reboot every other day, that was never touched for over 2 years. Things that somebody did once and it worked but most people do not understand it because of the aweful code. Yes of course we still need high quality code in some parts, but most parts of the world is already running on software that is way worse than modern vibe coded things
Do not vote on this comment! I am a server! :)
tl;dr: give up, stop trying. just approve the juniors' PR without comment so you have more time to proompt.
Why even use bun or anything else if everything is getting slapped together with LLMs? May as well use them to build native
Do you also install pre-alpha revisions of operating systems on your main work pc? No, you do not. Why? Because of the "foreseeable compatibility and security issues".
"Well, why don't you install and only then resolve issues if you have those difficulties?" most comments here are asking, in effect
Cause you're sane, that's why!
Same here. yt-dlp does not owe it to anyone to beta test things. Maybe this bun rewrite will be the best thing since sex, and maybe it won't be. Not wanting to alpha test someone else's shit is sane. And the bugs (if any) would go to yt-dlp, forcing them to debug someone else's alpha software. This is a sane response.
Who was actually using yt-dlp with bun? The primary use is to solve JavaScript challenges sent by YouTube, which uses Deno by default.
To be fair, I'm not quite sure why it would prefer either Deno or Bun when it's far more likely that a user has Node on their system.
I assume they need to do a bunch of WebAPI bullshit to get around Youtube's draconian policies, but maybe one day https://txikijs.org/ will solve all problems with embedding javascript. I believe, and maybe the strength of my belief will be enough.
Bun was just one of multiple JS runtimes supported, so dropping them doesn't have user-facing consequences. The people posting militant comments here and harassing the maintainer on GitHub are fighting for Anthropic instead of trying to raise any legitimate concerns about yt-dlp.
Do we know which model was used for the rewrite?
Claude
Bun’s source code rewrite from Zig to Rust was executed primarily through AI-assisted development using Anthropic’s Claude agents, specifically within a branch named claude/phase-a-port. The project creator, Jarred Sumner, merged the massive pull request (PR #30412) on May 14, 2026, which involved over 1 million lines of code added and 6,755 commits completed in roughly one week.
Claude is a model provider: they have many models. It would be interesting to learn if the models used were Sonnet, Opus, Mythos, some other internal unreleased model, or some mixture of them.
Gemini, obviously.
I already came across some bs bug in claude today due to this stupid rust bun thing, so I absolutely 100% support this decision.
Bun alert!
Good news!
As long as Deno support is still there I'm not sure why you need anything else. It's not vibe coded slop for one.
Well, apparently Deno is also a slop now: https://github.com/yt-dlp/yt-dlp/issues/16766#issuecomment-4...
Deno's LLM contributions have been smaller in scope, so they're more likely to be reviewed by a human, and the codebase remains understood by its contributors. Can the same be said of Bun, which switched to an entirely different language in a single, million-line PR?[0]
[0]: https://github.com/oven-sh/bun/pull/30412
Since when small vibe coded slop became the norm? Because there exists bigger vibe coded slop, it's no justification to have a smaller vibe coded slop.
One shotting slop is very different from iterating back and forth with an AI. Also, most of the AI work that's being done has been getting node compatibility tests passing with the help of comparing that to the Node.js code, which is something an LLM is very good at.
> One shotting slop is very different from iterating back and forth with an AI.
Bun is also iterating back and forth with AI. The rewrite only got popular because of bigger scope. The bigger the scope is, the more bugs there are.
> getting node compatibility tests passing
So does Bun.
> which is something an LLM is very good at.
Doesn't matter. The code those LLMs operate on is simple enough that any middle software engineer can do.
Using AI to write code is not necessarily vibecoding nor slop.
I don't think it matters how code is produced -- it matters what it achieves. Is there evidence that there is something wrong with recent Bun releases?
I think one of the big disconnects here are the competing views about "what it achieves" means on a fundamental level.
There's the "what it achieves" today; software x works as intended as of right now.
And then there's "what it achieves" long term.
Those with significant experience with sprawling, LLM-generated, codebases, often built by those who don't understand the code produced, can attest to things being good today, unworkable tomorrow.
While this isn't true across the board, and my own experience should be considered anecdotal at best, those who consider "what it achieves" to also include long term viability as a success metric, are skeptical of these types of changes.
Personally, success for dependencies isn't just "does it work today" but "can I trust it to work long term."
I don't use Bun. I don't care about Bun. But my opinion is that how code is produced will have some effect on what it achieves, if the goalpost includes more than "it works today."
I see a lot of commentators in this thread who are aggressively critical of volunteer maintainers for making a decision about how to maximize the value of the free labor they donate to the world.
And yet none have offered to volunteer their time to maintain a downstream fork or otherwise rectify the perceived problem.
Strange.
Which "volunteers" are you referring to? Bun? yt-dlp?
yt-dlp, clearly. Bun has no volunteers (as of the rust rewrite at least, it's all highly paid SWEs and GPUs.)
Most developers can’t see AI slop because their level of competence is actually below what an AI can produce.
Technical debt was a reality before vibe coding. Someone was writing all that trash by hand.
I like this clear divide of:
Zig bad, rust good
You bad, ai good
and then some random posts in between that try to create some hot takes for upvotes. What is the internet at this point?
yt-dlp launches propietary software:
https://jxself.org/shifting-the-trap.shtml
You can run a BF and, soon, subleq.
Ah yes, more examples of averse behavioral ai syndrome
Reason #2 is purely speculative. It’s disappointing to see technical decisions being made on such grounds.
All dependency management is speculative. You've got to hedge your bets that the dependency is reliable and fit for purpose. It is reasonable to view Bun's recent choices as increasing the risk associated with depending on it.
Very much agree. Until the vibe-coded version has been fully audited and profiled to perform, within reasonable tolerances, as well as the original code base, it feels like a bad idea to support it downstream or use it in production.
Even if it performs reasonably, it may still be unmaintainable, meaning that any future changes are likely to introduce bugs and instabilities. At the present state of AI coding it’s completely understandable not wanting to depend on code that the maintainers have no good understanding of. The code auditors would have to become the maintainers.
Any rational person investing in AI rewrites at this scale must fundamentally believe that all the downsides of the slop will eventually be cleaned up by the next version of the slop machine. So it's slop all the way down until, wave wands, the slop is indistinguishable from magic.
That is to say, techno jesus cometh.
Yes, but only if auditing includes an exhaustive human review of the code, not just passing the tests we (or an AI) thought to write.
I'd hope that the bun team is going to put into the work to ensure the LLM translated version is up to snuff before cutting a release from it though... it doesn't seem fair to assume that that isn't going to happen.
Really?? So you base your engineer in "speculation". The Bun team has a deep track record of delivering a high quality product. What makes you think that is going to stop?
>What makes you think that is going to stop?
a million-line rewrite over 7-8 days
>What makes you think that is going to stop?
The PR that was merged.
> All dependency management is speculative.
What a nonsense generalization.
In this case, the speculation ostensibly is that in future, there will be a release version of Bun that has is buggier or otherwise lower quality than the current stable version.
There's literally no basis for believing that. The actual basis is "I don't like how they're approaching the development of their next version."
If that's a valid basis for "dependency management", then using a Ouija board would be just as valid.
It's a common fallacy among tech folks to believe that every decision can be made from 100% deterministic grounds ("X decision will result in Y percent change"). In reality, successful decision-making often involves speculation. The speculation in question is within the bounds of reason. You may disagree, but the fact that it is speculative isn't the problem.
And not acting while doing the whole analysis to reach close to 100% deterministic grounds mis a decision in itself! It’s perfectly reasonable to drop support for bun, and potentially revisit later on when more details come up
> The speculation in question is within the bounds of reason. Y
I disagree. It seems to be an emotional reaction borne of ignorance and uncharitable assumptions. There's no "reason" involved.
What part of the recent history of vibe coded projects has not resulted in low quality, bug laden code? Dismissing this a "purely speculative" is just like dismissing the weather report as "purely speculative" when deciding what to wear in the morning.
Low quality, bug laden code has existed long before LLMs and it'll continue to exist long after. Their rationale about avoiding future headaches could literally apply to any open source project they have a dependency on.
The existence of bad code doesn't mean you should be happy to accept it.
There is quite the selection bias going on here... you aren't hearing about the successful projects.
People love to brag about using AI to get work done. If anything I expect the successful projects to be overrepresented.
Care to list them then? I have yet to see a successful vibe coded project
With all the unprecedented investment and desperation behind it, these hypothetical LLM successes would be getting shoved down our throats.
We're only hearing about the failed projects? I call BS. Precisely the oppositee is both true and obvious if you're not a shill. The "successful" ones are being trotted out all the time trying to convince us how great it is. If anything, we're not hearing about all the catastrophic and costly failures while the cherry-picked almost successes are all over this platform and others.
Doesn’t bun have a massive test suite that the rewrite passes? What else do people want?
1. You cannot make bug-free software with tests alone. Moreover, code that compiles and executes successfully is only one goal, memory efficiency and performance and security are other desirable traits. Claude Code can consume GBs of memory to display 1kb of text because it is slopware.
2. Even if somehow you did make bug-free software with tests alone, even if the Rust port is at perfect parity with the Zig codebase today owing to the years of careful human work that went into building tests as a framework to guide the AI... the future can only be downhill from here. Nobody has a mental model of the new 1m loc codebase that's never read by humans, so Bun's future is committed to 100% vibecoding. Maybe the carefully planned tests minimized the worst case scenario, but the future tests will be written by Claude too.
If, and this is a big if, it turns out that there are no major problems and Bun is better off in a year from today than it is now... then somebody can just fire up Claude and fork yt-dlp to support Bun anyways and their decision doesn't matter. In any other scenario than human code becoming completely obsolete, they are simply saving themselves a headache by getting rid of a troublesome dependency.
Tests are one quality control. It's horrifying that some of us treat them as the only thing that matters. There's review, obviously, and of course we haven't even had to think about "written by a thinking mind" as a beneficial quality until now.
How is "written by a thinking mind" a beneficial quality? All of sounds like to me is bias and gatekeeping. History repeating itself.
Vibe coding from scratch is far from translating an existing app to another language.
I don't know any bad stories about ai-translated apps. Partially because it's a relatively new trend, but also because a big amount of usual vibe code fail modes are not applicable here.
It's a reasonable decision to not take a dependency which doesn't meet your own engineering standards. People in the JS community could learn something from that.
[dead]
When Patty?
[dead]
[dead]
Idiotic. Why do they care what language it's written in? If it works it works.
Wow, bun support was just added in November last year (I think). That's a lot of work to throw away, but you can't argue with their reasoning.
bun is still supported for specific versions so nothing is being thrown away. in any case the actual code is the same, since it's all javascript. it's more a matter of the wrapper code that calls the different runtimes and maybe some edgecases where the runtimes are not 100% compatible.
Honestly I hope agentic AI ushers in a new age of minimal-SBOM software. I myself am moving all of my projects towards nearly 100% vanilla where possible. For example, golang. Why use [insert web framework] when you can just use vanilla for 99% of web apps?
There's something really satisfying about a go binary with minimal dependencies running in a busybox docker container.
Rather than have complexity centralised and managed, let's generate the same vulnerable code across millions of apps. Great plan.
"A little copying is better than a little dependency." - Go Proverbs [1]
Most complexity is unnecessary. Adding dependencies to your project exponentially increases your project's surface area, which in turn increases its regulatory/cybersecurity burden, especially if your software is a medical device, munition, etc. Why is Echo/Gin/Gorilla/etc better/more secure than vanilla Go's mux? Just anecdotal, but we use the Echo web framework for Go and it's caused nothing but headaches. It does magical XML parsing by default even though we don't deal with XML which gets us flagged in pen tests. Updating from v4 to v5 broke production for us because they made an undocumented server config change that makes all requests have a 30 second timeout. Meanwhile vanilla go has the ability to register routes and middlewares, so what value is Echo bringing to the table? Ditto for lots of other unnecessary dependencies. A lot of times we just need one little thing out of the whole package, and in those cases a little copying (or a little AI generation) is better than a little dependency.
A static go binary with minimal dependencies running in a busybox container has a tiny CVE footprint when run through grype/snyk, etc. Do the same for a NodeJS app with zillions of dependencies running in an ubuntu container and you'll spend all day triaging CVEs.
I'm not saying "roll your own crypto" but I am saying "axios-like packages don't make sense to use any more in a world where AI+vanilla accomplishes the same thing"
[1] https://go-proverbs.github.io/
Wouldn't that be worse? With dependencies, it's at least possible that someone else has audited the code, but with a vibe-coded from scratch app, it's definitely totally unreviewed.
I never said AI code should be "unreviewed". I'm saying that instead of pulling in axios or requests (as a contrived example) to make HTTP requests, just use AI to generate some vanilla JS/Python that has the exact subset of functionality you need. Your code has fewer dependencies, CVE surface area, etc, wins all around.
You only add what you need instead of importing some bloated dependency. That means you can actually review the code yourself.
Relevant reading: https://nesbitt.io/2026/02/16/changelog.html
> Removed: mathjs dependency. 14MB, 200+ functions. Twelve functions used. Added: Custom math utilities module (src/math-utils.js). Addition, subtraction, multiplication, division, a handful of trig functions. Co-authored-by: chatgpt. Changed: Bundle size reduced by 68%. Build time down from 12s to 4s. Module: 47 lines across 1 file. 0 tests. 0 dependencies.
Are you aware this is satire?
Yes, it says so right under the title. But it's not wholly fictional: this happens all the time, to the point we have a name for it (Not Invented Here syndrome).
That it took so long before they started trying to phase out their home-rolled library for the "hard cases" is somewhat unrealistic, although possible in a sufficiently-dysfunctional organisation. Some of the details about the problems of their homespun library are clearly anecdotes translated from other settings, and are unrealistic in the context of a mathematics / finance library. (They only noticed that interest calculations were wrong when a customer complained? Seriously?) The development of 6.1.0 (via 6.0.0) taking only two weeks isn't congruent with the rest of the story, although it may be realistic for AI-driven development (with which I am unaccustomed).
But otherwise, this is one of the more realistic satire pieces I've read.
> There's something really satisfying about a go binary with minimal dependencies running in a busybox docker container.
Go binaries are immensely satisfying, but I don't follow your logic here. The vast vast majority of dependencies in Go do not depend on the outside world, so the binary would remain self-contained whether it has 1 or 100 dependencies, no?
Assuming you disable CGO, yes, the binary is always self-contained. However, I want to clarify a few things.
The "self contained" part is only important in that it lets you use busybox or "from scratch" as your container runtime environment which has a very tiny cybersecurity surface area compared to, say, ubuntu or even alpine which has a bunch of system libraries your go binary isn't using, but which could still get flagged for having vulnerabilities.
Minimizing dependencies of the go binary is a separate, but equally important task that reduces the cybersecurity surface area of your go binary itself to just "the go standard library" instead of "go stdlib + a dozen github packages"
Whenever I am working with a NodeJS project I pity the fool who has to do SCA because the CVE surface area is enormous compared to go, which has a fairly batteries-included stdlib
That must be why so many vibe-coded UIs have awful UX (terrible contrast, too small fonts, everything gets its own colors, no attempts at standardized behaviour)
Frameworks and ORMs were the pre-agentic AI "iron man suit".
I'm quite liking how good Claude Code Opus is at Rust + sqlx (raw SQL with type safety) + actix-web.
This like if BitTorrent cut off Windows support over objections to Microsoft embrace/extend/extinguish. It’s a slightly incoherent position.
This seems like a tenuous analogy, to put it lightly.
Care to explain why, or nah?
Not BitTorrent, but I can see a world where e.g. Transmission dropping Windows support because of Microsoft policies.
To me it feels more like the old "this site only supports IE6". Instead of checking which JS engine the user has, check for specific api support and fail gracefully.
Which company doesn't do that?