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.
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.
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.
> 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.
“Learned helplessness” himself graced us with his presence.
> 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.
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.
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.
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.
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.
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
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.
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.
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."
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.
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.
No, the team mislead people by claiming the rewrite was experimental only to merge 1M lines of unreviewed code merely days later. Responsible software developers don't operate on blind trust, and both the Bun code and the maintainers are highly unpredictable at this point. That's more than sufficient technical grounds to drop an optional and replaceable dependency, especially since there are no user-facing consequences beyond the bruised egos of a cult following that demands blind loyalty to its tech‑bro leaders.
Who did they mislead? A few days later it was no longer experimental and it became the main dev branch as they decided it would be the way forward for development (see the blog post on why). No stable release has been declared yet.
Here was the Bun team's message on merge:
> It passes Bun's pre-existing test suite on all platforms (and fixes several memory leaks and flaky tests), the binary size shrinks by 3 MB - 8 MB, the benchmarks are between neutral and faster - and most importantly, we now have compiler-assisted tools for catching & preventing memory bugs, which have costed the team an enormous amount of development & debugging time over the years.
>
> The codebase is otherwise largely the same. The same architecture, the same data structures. Bun still uses few 3rd party libraries. No async rust.
"Who did they mislead? They just changed their minds a few days later and words aren't what you think they mean. Here's the team's PR statement containing assertions about the 1M lines of code they never reviewed."
It's unfortunate that this is what some call "engineering" while labeling actual science and engineering as "politics."
yt-dlp is under no obligation to keep using a dependency from vendors that instantly flip flop and re-frame their own words and actions. That's what actual due diligence and responsible engineering looks like.
Feel free to point out where my logic is wrong. It sounds like you think they've made a stable release already? None of the new code is sent to users yet. It's a direct translation without relying on major AI decisions. I'm happy to call them cowboys if they make a release with lousy testing.
> It sounds like you think they've made a stable release already?
What's the point if you keep refusing to acknowledge the issue and tossing out theories about how I and others might be wrong, just to see what sticks?
> None of the new code is sent to users yet.
So? The decision to adopt was already made and the code was merged without planning, without considering downstream impacts, and without proper inspection. People who won't read their own code before merging won't read it after. But many of you don't even see this as an issue. So again, what's the point in trying to point all of this out?
Also you yourself said the experiment is over. You can't have it both ways.
> It's a direct translation without relying on major AI decisions.
Because the genie said so? That sounds lacking in scientific rigor, but
> I'm happy to call them cowboys if they make a release with lousy testing.
Oh right, that the test passes is proof that the new code is debuggable, maintainable, architecturally sound, semantically equivalent to the old code, and non-disruptive for downstream users. Apparently testing has leapt centuries ahead in the past two weeks or so.
Testing is a broader term covering multiple things, up to and including the decision of when you have enough confidence in the system to declare it stable. The test pass rate was an early bar for merging into dev, not release.
The translation did not change the architecture: it was a 1:1 translation with even the same internal data structures. Rust written in a zig-like way, with the original Zig still available as reference. AI can make an absolute mess when making architectural decisions, but translation like this plays to the strength of current AI, especially when moving to a stricter language.
The code being in the dev branch means that they now are open to community feedback and testing, and no date is set on it being declared stable. We'll see how the team handles it.
I don’t thing maintaining and testing support for an extra runtime is free.
It is by definition cheaper to not support extra runtimes like Kaluma, Elsa, WinterJS. Adding support is not just the initial work of adapting CI and writing policies, maintenance and support is ongoing work.
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.
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).
“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.
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 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.
> 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.
> 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. We are adding a support ceiling of version 1.3.14, as that is the last release built from the original zig codebase.
That’s as reasonable as it gets. Yt-dlp isn’t a beta testing grounds for hyperscalers.
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.
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.
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".
- A single bug about EJS, which was fixed almost a year ago and has never regressed.
- Frustration that Bun was rewritten in Rust, which "seems like a future headache" - i.e. no evidence of current issues, just something which they suspect might have issues in the future.
If you see more evidence of more bugs that weren't fixed almost a year ago I'd be curious to see it.
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.
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.
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
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.
Nothing in your link supports this assertion. Lots of things in your link support the exact opposite in fact, that the Bun team explicitly chose not to attempt to upstream the changes.
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.
> 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.
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.
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.
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.
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.
> 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.
> This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.
I ain’t reading a single thing from the guy after this one.
> 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.
My argument wasn't that the test suite was perfect, my argument was that this is far from "YOLO" - this is a textbook example of being able to do bigger refactors, etc when you have an extensive test suite.
They can have 100% coverage for all I care, you don’t push 1 mil loc change and call it a day.
> 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.
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.
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.
> 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.
I've decided to stop making analogies on HN because, instead of focusing on the helpful part, people always take them way too far and then act as if they invalidated your original point.
In case you aren't aware, the whole codebase of Bun did not explode into debris just because it hit a bug. They can just fix the bug and recompile.
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.
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.
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.
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.
> This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.
Is your reading comprehension poor? Where in that does it say it had no chance of being merged? Do you understand what an experiment and what the purpose of an experiment is ?
Of course he's not writing a legal contract, but to go from saying:
> This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.
And then fully merging into main in under 18 days is quite extreme
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.
> 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.
> 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.
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.
This is a good example of what many private companies are doing, and the rude awakening they’re in for with token price hikes and vendor lock in. It’s like Oracle all over again
> 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.
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.
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.
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.
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 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 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.
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. 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.
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.
> 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
> 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 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?
> 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
A merge to main itself is pretty substantial, especially a week after saying, "[This] code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely."
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.
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?
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.
> 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."
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
> 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 an OSS project now owes testing to hyperscalers? Lol!
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.