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.