Hacker News Reader

Comment by gpm | Hacker News Reader

> 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.

View on HN

> 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.

Adding support again later is cheap.

Stopping maintaining and testing support for upcoming versions is cheaper than doing that work.

Sure it’s political but it is also just a sane approach, to stay away from such disruptive change and treat it as wait-and-see instead of tagging along for the ride. There is not really any technical upside to tagging along and promising support.

> Stopping maintaining and testing support for upcoming versions is cheaper than doing that work.

If it’s based on predictions of how some alpha software might turn out in the future then I don’t see how you can claim it’s cheaper.

If a bunch of new bug reports came in then you said no, then everyone would understand.

This is pretty obviously ideological otherwise. Which is fine, but we shouldn’t pretend otherwise because we might agree with it

I think it's perfectly rational to take a wait-and-see approach when a dependency has been completely rewritten from scratch.

That would still be rational if it had been rewritten by hand, and not by an LLM.

This isn't a wait and see approach, this is proactively removing it

It's "we support 4 JS backends, we don't have the capacity to support 5 currently". They're not dropping bun entirely, instead bumping the minimum bun version and not supporting "bunv2" because they don't want to be beta testers.

Has the team announced that they're breaking backwards compatibility, or that testing will be reduced?

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.

I suspect this thread won't go anywhere.

Something that's experimental can receive further changes and then no longer be considered experimental.

There could be some genuine discussion if you stop bending over backwards justifying YOLO prompting with strained logic.

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.

> Feel free to point out where my logic is wrong.

I already have, as have others, but

> 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.

Proactively removing work, yes.

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.

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 say it's random. But I do like referring to them as statistical code generators.

> 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."

> 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.

Wait, expecting all code to be verified and tested by a human is not engineering-driven but instead emotion-driven mindset???

What code is fully, or even primarily, tested by a human? Haven't you heard of automated testing suites, regression testing, conformance testing..?

Test code written by a human counts as "tested by a human". Also, most code is literally tested (manually) by humans in addition to automated tests. You are being pointlessly pedantic.

Bun has a test suite of tens of thousands of tests. For purely non-functional changes, like refactors or rewrites (e.g. a Rust rewrite) I rely primarily on test suites, not manual testing, in order to ensure that nothing regressed. I mean, sure, I am going to poke around, too, but the test suite is the encoding of thousands of obscure bugs and issues over years. There is no way my manual testing will be able to cover the same ground.

> Test code written by a human counts as "tested by a human".

Were Bun's tests generated by an LLM? If they were, were they read by a human afterwards to be validated?

Publicly based on my calculations[1] there only ~20k tests. I would say they are usual tests for the runtime. Constantly running on the CI much lesser amount. Average test count/line of code ratio drops after rewrite. And even before Node have denser tests count/LOC ratio

[1] https://kant2002.github.io/en/llm/2026/05/16/bun-pr-analysis...

If I were to mirror your tone, I'd ask you if you've ever heard of the basic courtesy of running your code manually yourself before you waste anyone else's time with it... Or whether you've heard about QA, or about making demos for Product or for customers...

Neither of these can be replaced by an automated test suite of any kind, and all of these are examples of good engineering practices that guarantee software quality.

Additionally, even if you don't (need to) adhere to the best engineering practices and instead rely solely on an automated test suite, the tests in this suite must be validated - read and understood - by a human in order to guarantee that they nail down the correct requirements.

> 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.

"Political" here means "I don't like it"

That's fair - I updated my comment a little. What I mean is that the decision was driven by an ideological basis, not an empirical one. Bun was written with AI, AI doesn't fit with my ideology, therefore I reject it. As opposed to Bun has these new problems X Y and Z, therefore I reject it.

The irony of this comment on an app that is:

- free and open source, which is an ideology, and that

- expands access to otherwise locked down media, which is again an ideological stance

That has nothing to do with what "politics" means but it's exactly how people have started using "political" to mean "idea I don't agree with".

I think there is a lot of overlap between politics and ideology, and an increasing amount of overlap between ideology and emotion.

I think it's fair to call me out for skipping a step, but I wasn't using it to mean "idea I don't agree with".

>I wasn't using it to mean "idea I don't agree with".

I believe, maliciously or innocently, you were.

> I think there is a lot of overlap between politics and ideology

What is politics without ideology?

Power struggle. Lying about manager from other team so that you look better. That sort of thing is regularly called politics.

Interesting that you think there is no ideology involved in that kind of politics writ small.

In software engineering the word has also long meant "a decision not made purely on technical terms"

That's a perfectly cromulent meaning of the word.

I can't see how this counts as "political" or "ideological" by your definition unless you believe that emotion can't exist as part of any decision, in which case you should give up interacting with human beings entirely.

Regardless, the decision was 99% logical. In fact, even the emotional parts are laudable. For example, I love software. That's an emotion. If you disagree with that foundation, we will fundamentally never be able to converse with each other about what's best for software.

The opposite of political would be someone saying "I have observed that Bun has X, Y and Z bugs -- therefore we are no longer support it". An example of this is the recent announcement that Ghostty is leaving GitHub[1]. Compare and contrast the rationale:

> I've felt this way for a long time, but for the past month I've kept a journal where I put an "X" next to every date where a GitHub outage has negatively impacted my ability to work2. Almost every day has an X. On the day I am writing this post, I've been unable to do any PR review for ~2 hours because there is a GitHub Actions outage3. This is no longer a place for serious work if it just blocks you out for hours per day, every day.

That isn't ideological in the slightest. Count the X's, and move off once you see too many.

[1]: https://news.ycombinator.com/item?id=47939579

But unless you're doing that for every service you use (and not just the ones that annoy you), that's still the same logic. Deciding to count something is just as "political" (as you put it) as choosing to not count something.

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.

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.

vibe coding isn't a political topic lol

this amounts to "i don't trust this dependency anymore, so i'm cutting it out for my own good"

that's fine

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.

> 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.

In all sincerity, what does political even mean in this context? ELI5, I’m a toddler when it comes to the politics of AI/LLMs.

Its a polarizing world with AI. There are fanboys drinking the kool-aid blindly listening to whatever Sammy/Dario/... say as gospel, and on other side there are haters who again blindly reject the fact that these AI tools can be actually be useful. I think that's what the politics is.

Yes - exactly! I honestly thought I was going crazy when a bunch of people were saying that this decision wasn't political in the slightest.

I’m tracking the polarity of the whole movement, I didn’t understand how politics was attached. I desperately don’t want the whole thing to become a left vs right disaster. We have enough of those.

You might not like it but you actually live in a world with other people and building technology often affects their lives and they have opinions on it. For AI a lot of that impact has been negative.

I don't have the emotional energy to care, actually.

This is actually fascinating. How does my opinion matter? Should I join all the socials (this is my only form of social media) and stand on my soapbox and shout into the void? Do I need to express I care so others know I care and have picked a side and have opionions on evrything?

I do not care. My opinion does not matter. I can scream into all the voids. I can virtue signal until the heat death of the universe/until I die, it matters not. I don't have the desire to spend the limited emotional bandwidth on giving a flaming fuck about the world around me. I'm not that arrogant or self-centered to think anyone else cares.

Engineers not caring is what leads to people working for scumbags who build socially poisonous technology.

What if I told you I was a stay-at-home dad?

> 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.

if you call picking your battles wisely “learned helplessness” then yea

What a useless response.

I disagree as well, and wonder if the OP meant an emotional or ideological stance instead.

Yes - this is indeed what I meant, thanks.

That wasn't my read, though. I think if they don't want to go with the vibe-coded version then they have to go with the last release before that. And presumably that last release won't be updated (except with the vibe-coded version). Therefore it makes sense to deprecate.

What's wrong with yt-dlp - an app almost entirety driven by political stances - taking another one regarding llms?

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.

“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.

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.

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).

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.

Reply on news.ycombinator.com