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

▲

johnfn an hour ago | parent [-]

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

▲

cmiles74 11 minutes ago | parent | next [-]

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.

▲

gpm an hour ago | parent | prev | next [-]

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

▲

johnfn 29 minutes ago | parent [-]

That's not what I meant by political. I meant political in the more modern sense of "appealing to emotion rather than thought".

▲

oaweoifjwpo 17 minutes ago | parent | next [-]

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

▲

wgjordan 13 minutes ago | parent | prev | next [-]

That's a perfectly cromulent meaning of the word.

▲

phoronixrly 21 minutes ago | parent | prev | next [-]

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

	▲	zephen 7 minutes ago \| parent [-]
		[flagged]

▲

add-sub-mul-div 16 minutes ago | parent | prev [-]

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

▲

fmbb an hour ago | parent | prev | next [-]

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.

	▲	dmix 6 minutes ago \| parent [-]
		> 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

▲

oytis an hour ago | parent | prev [-]

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

	▲	rho_soul_kg_m3 21 minutes ago \| parent [-]
		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.