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.
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.
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.
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.
this amounts to "i don't trust this dependency anymore, so i'm cutting it out for my own good"
that's fine
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'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.
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.
> 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.
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.
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".
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.
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.
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.
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
That would still be rational if it had been rewritten by hand, and not by an LLM.
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.
If they had decided to drop Bun for "AI assisted coding," that might strike me as a political decision.
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).
