> 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.
> 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.
What's wrong with yt-dlp - an app almost entirety driven by political stances - taking another one regarding llms?
> 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.
"Political" here means "I don't like 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.
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.
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.
[flagged]
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.
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.
That's a perfectly cromulent meaning of the word.
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.
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 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.
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.
> 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.