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.
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.
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
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.
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
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.
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.
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.
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.
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.
> 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 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.
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.
> 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.
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.
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.
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.
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.
> 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."
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.
> 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 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?
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.
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.
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.
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.
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?
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.
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.
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.)
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.
That's not even the worst part though, the worst part is 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.
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.
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.
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.
>how could the maintainers understand their codebase if most of it was not directly written by them
I think you are not understanding the new paradigm. The idea that 'humans are going to understand the codebase' is dead. Codebases will be maintained and reviewed by AI. You might think this is bad, but 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. This has happened in every area of humanity, and it seems foolish to think that code generation would be immune.
Again, you might think this is a bad thing, but it’s simply how humanity has been functioning. 'Oh, but who is going to maintain this?' AI. 'Oh, but what if one day that's not possible?' Well, what if one day the electricity goes out due to solar flame or whatever? You get it?
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
There is no generic “JavaScript runtime” interface that runtimes would implement, therefore support must be tailored to the specific interfaces of existing runtimes.
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.
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.
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.
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?
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
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.
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.
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.
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.
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.
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)
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.
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.
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