> 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's not really political. Or let me rephrase possibly yt-dl is being political. VUT the concept of 'not adopting a core dependency until it has been widely used in production for 6 months - a year.', is not a political on general. A full rewrite of 1 million loc is essentially a new runtime that has the same ABI as the previous and for many downstream consumers it's not something they are comfortable taking a production dependency on. If for sale of argument BUn was fully rewritten by hand would be the same situation. I personally think this kind of decision is pretty standard, I also personally think the Bun LLM rewrite will be of good quality overall, but I certainly would not bet my product/company on it. I want to be the one making the risky changes on my software not being forced into it by downstream deps.

Not sure what seems "political" about this.

When deciding to support a given thing, you have to make a determination as to whether it's worth the effort or not.

You don't simply ignore unknowns. That effectively means assigning the unknowns zero cost, which is unlikely to turn out to be true. Generally, the more unknowns, the higher the risk, and the higher the risk, the higher the estimated cost.

There are a lot of unknowns about vibe bun right now.

One effective strategy for dealing with unknowns is to turn them into knowns if you can. Here, that probably means waiting to see how vibe bun turns out.

If it turns out to be stable and highly compatible, at some point in the future, they can always pick up support then.

If you wait for more segfaults, OOMs and other issues, than you have failed to avoid the problem. In my opinion this direction is correct and history will show who's right.

A key element of engineering is projecting a current trajectory. Given that, it absolutely makes sense to avoid tools that give you a bad feeling. The easiest time to move away from a tool that will become a train wreck is before you've integrated it.

Then Bun's rewrite is also political. They couldn't upstream their vibe coded "improvements" so in spite they decided to vibe a rewrite in Rust. The arguments for the rewrite were not backed by any data.

Every single macOS update the top comments are about giving it six months to stabilize, but when a program’s biggest ever rewrite involves a lot of AI, the top comment is calling you irrational if you don’t YOLO it, and probably a jerk, too.

FYI in case you aren't aware, the rewrite was shipped, and then had to be reverted due to issues being discovered. That's "Jarred's high quality bar" you're so confident in.

Why wait?

Seems reasonable to preemptively drop support and let someone else either suffer the fallout, or get proven wrong and just pick up support again. It's not for a lack of people motivated by IA. Unless the motivation is more "use my IA generated content" than "actually consume IA generated content", of course.

“... it seems unlikely he would ship this rewrite if it didn’t meet his quality bar” is every bit as vibes-based as the decision you are critiquing.

Every decision is made with imperfect information about the tool, its future, and your current/future needs. This is a normal type of engineering decision.

Bun being replaced entirely with stochastically generated code is red flag (regardless of whether it was or not). But Bun was also acquired by a huge corporation, which has been classically a huge red flag. Both of these are plenty of reason for yt-dlp not to support Bun.

In either case, this seems like a niche use case. I've used yt-dlp for years and I've never used Bun with it. If Anthropic really wants their recent acquisition to be supported in yt-dlp, it can fork it and support it itself.

I don't think refactoring 1M lines of code into another language within 7 days and merging it to master is responsible. I won't make my code depend on it.

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

Your argument could go other way too. Why haven't they landed if they're so confident with the change?

Anyone who merges such a huge PR of ai generated code doesn’t deserve trust. This is a real black box now, even for the developer himself.

> I don't select my engineering tools because they give me a bad feeling - I select them because they do the thing I want them to. If Bun starts having more bugs and feeling like worse software, I'll stop using it. But I will base that on data -- not a feeling I have.

being reactive is fine if you can tolerate issues. otherwise, you need to be proactive -- don't wait for the train to hit you before you move off the tracks

>I don't select my engineering tools because they give me a bad feeling

But you do select your engineering tools on faith apparently.

a vibecoded rewrite right after being acquired is not political?

> This decision seems to based more in politics than engineering.

I'm glad some engineers realize that technology is inseparable from politics. It always has been. All evil came from engineers who beleived they were above politics. Selecting the tool which got the job done/made the number go up/paid a paycheck is how we got Facebook, Google, Palantir, crypto, AI, techno-fascism and neo-feudalism. None of it would've have happened without engineers blindly applying their knowledge to achieve "purely" technical results, while ignoring the social consequences. With the hindsight of the last 20 years, anyone who still advocates for an irresponsible adoption of technology should be considered automatically suspect

You may not want to take part in politics, but politics wants to take a part in you.

I have no idea how that’s what you get from this. I don’t want my project using any tech that decides to take 6 days to rewrite the entire library with AI. That is at its core an engineering decision.

No healthy engineering team is going to do that. And I’d want to distance myself as far as I could from a project that behaves like that.

Yeah this is a cringe way to weigh in on something completely unrelated to your project. Who cares if some random package supports Bun? Compat was always on Bun, anyway.

> I don't select my engineering tools because they give me a bad feeling

I do, for example when I see constant behavior of lying, or negligence for security issues or not considering valid PRs and rewriting it to fit their paid plan and so on.

> I select them because they do the thing I want them to.

This is one of the dimensions when I pick the tools, I know Oracle produces nice products, but I don't want to get sued if I do something accidentally their lawyers dislike.

Isn't that what Bun/Anthropic did? A rewrite based on vibes?

Except "because we can" and the expectation that some kind of bug will be reduced and other metrics will not get worse

All Bun devs are happy to change programming language?

When their competition is already in rust and more mature

While using the LLM that is now paying their salaries. Kind of a conflict of interest

Even a major version upgrade is enough for me not to touch it for 6 months, let alone a full rewrite

Has Bun posted any analysis and shown the data?

> I will base that on data -- not a feeling I have.

and yet...

> If Bun starts having more bugs and feeling like worse software, I'll stop using it.

Is it not possible to judge that certain approach is more likely to bring unforseen controlable problems than another by analyzing how it works without assessing it's output? No "feeling" is needed

So, let's see here. Here we have a program, that is used to install scripts from source that has been targeted, and breached multiple times last few months, can run arbitrary code on millions or billions of user computer, servers. And, it was ported to another programming language, resulting in 1m LOC, in 7 days for publicity stunt of a LLM company

Even multiple people can not go through 1m lines of code for any kind of vulnerability in 7 days, let alone 'observe' more segfaults, OOMS, unsafe behavior, on who knows how many possible ways things can go wrong in this new condition.

Only guaranty is 99% tests passed, and the engineer who is paid by the same LLM company.

How in the world, any sane engineer would agree, this would be remotely a good idea to continue using this tool, for a chance that such a expensive change won't actually land in production?

I believe you contradicted your first point by following it with "If Bun starts having more bugs and feeling like worse software"

...so you do use feelings in your calculation? To be clear, I have no problem with that and think there is some level of speculation you need to do when deciding what to rely on.

As a hypothetical, pretend that Bun added obfuscated binary blobs that get executed at build time. Well, your code still works and no effects show up at runtime. Are you going to keep using it or dump it based on the "feeling" that something isn't right?

absolutely, and `its development seems to have taken a turn towards being fully vibe-coded` ungrounded claim confirms the hysteria, I'm afraid

> This decision seems to based more in politics than engineering.

You are 100% right. This is a decision made on VIBES and not evidence. The proof is here:

> Bun was recently rewritten in Rust using Claude, and its development seems to have taken a turn towards being fully vibe-coded. This is alarming and disappointing for a number of reasons, and frankly it seems like a future headache that we'd prefer to avoid.

They haven't tested it, they haven't found a single problem. They just don't like AI code and they're clearly saying "the fact that the project tested every line of code and it passes all tests doesn't matter to us. The fact that it's vide coded by people who literally make coding LLMs also doesn't matter."

Pure ego, no data.