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.
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.
> 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?
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.
>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.
Completely regardless of how the code was written or even if anyone understands it thoroughly, they replaced the entire running codebase in a week. The entire project was one thing and is now something different.
There are countless reasons that this is a very bad thing for consumers of Bun. First and foremost you've instantly lost any and all assurance that it works the way it's supposed to. Every project has load-bearing bugs that may or may not still exist. Can you trust the core behavior is the same?
If the Bun maintainers are willing to completely replace their core product over the span of a week, how is anyone supposed to rely on it? What's preventing another rewrite in a few more weeks?
If you want to position your product as a dependency, it needs to be stable and reliable. Throwing away a million lines of code and replacing the entire product overnight is pretty much the polar opposite of stable and reliable.
It has nothing to do with AI rewriting the code, it's the reckless abandon and wild disregard for consumers that is the problem. It's literally a rug pull.
I 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.
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.
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.
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.
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?
> 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.
> 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
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.
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.
> 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?
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.
> 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 - 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.
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.
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.
> 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.
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.
> 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.
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.
> 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.
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.
> 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.
I have a t-shirt signed by THE Jarred himself, how much are you willing to pay for it? Comes with a month of free Claude max subscription.
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.
They could at least wait a bit, test the new Bun for some weeks/months, have people read big chunks of the codebase.
It should be a major release indeed, and communicated as such, with full accountability of the migration beyond an “all tests pass”. A major tool should move slower, be tested longer, more thoroughly, since it’s used my millions.
It’s reminiscent of JavaScript world, where something is in beta for mere days (e.g. Expo’s short release cycle).
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.
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.
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.
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
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.
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.
129 comments
[ 3.3 ms ] story [ 81.5 ms ] threadThere'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?
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
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.
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.
There are countless reasons that this is a very bad thing for consumers of Bun. First and foremost you've instantly lost any and all assurance that it works the way it's supposed to. Every project has load-bearing bugs that may or may not still exist. Can you trust the core behavior is the same?
If the Bun maintainers are willing to completely replace their core product over the span of a week, how is anyone supposed to rely on it? What's preventing another rewrite in a few more weeks?
If you want to position your product as a dependency, it needs to be stable and reliable. Throwing away a million lines of code and replacing the entire product overnight is pretty much the polar opposite of stable and reliable.
It has nothing to do with AI rewriting the code, it's the reckless abandon and wild disregard for consumers that is the problem. It's literally a rug pull.
I feel this argument is not valid, especially for large code bases.
Documentation and code quality is what is important, not who wrote the code.
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.
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.
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.
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?
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?
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.
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
But you do select your engineering tools on faith apparently.
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.
Your argument could go other way too. Why haven't they landed if they're so confident with the change?
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.
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
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.
Those bad feelings are often your years of experience trying to tell you something.
> feeling like worse software
Politics ;)
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.
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.
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.
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
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.
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.
The argument that you somehow cant unless you go through trouble of testing it is way more "politics" and way less "engineering".
I have a t-shirt signed by THE Jarred himself, how much are you willing to pay for it? Comes with a month of free Claude max subscription.
> 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.
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.
It should be a major release indeed, and communicated as such, with full accountability of the migration beyond an “all tests pass”. A major tool should move slower, be tested longer, more thoroughly, since it’s used my millions.
It’s reminiscent of JavaScript world, where something is in beta for mere days (e.g. Expo’s short release cycle).
I still hope there is a beta release.
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.
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.
Which defeats the purpose of having it in rust.
And yet none have offered to volunteer their time to maintain a downstream fork or otherwise rectify the perceived problem.
Strange.