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. Jarred has done a lot of impressive stuff with Bun, and it seems unlikely he would ship this rewrite if it didn't meet his quality bar - I am willing to see him out here.

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.

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.

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.

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.

- free and open source, which is an ideology, and that

- expands access to otherwise locked down media, which is again an ideological stance

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.

[1]: https://news.ycombinator.com/item?id=47939579

Were Bun's tests generated by an LLM? If they were, were they read by a human afterwards to be validated?

[1] https://kant2002.github.io/en/llm/2026/05/16/bun-pr-analysis...

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.

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 believe, maliciously or innocently, you were.

What is politics without ideology?

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.

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.

this amounts to "i don't trust this dependency anymore, so i'm cutting it out for my own good"

that's fine

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.

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.

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.

Something that's experimental can receive further changes and then no longer be considered experimental.

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.

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.

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.

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

If they had decided to drop Bun for "AI assisted coding," that might strike me as a political decision.

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.

This is actually fascinating. How does my opinion matter? Should I join all the socials (this is my only form of social media) and stand on my soapbox and shout into the void? Do I need to express I care so others know I care and have picked a side and have opionions on evrything?

I do not care. My opinion does not matter. I can scream into all the voids. I can virtue signal until the heat death of the universe/until I die, it matters not. I don't have the desire to spend the limited emotional bandwidth on giving a flaming fuck about the world around me. I'm not that arrogant or self-centered to think anyone else cares.

“Learned helplessness” himself graced us with his presence.

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

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.

They can do absolutely what they want with their project especially when its majority decision. There can't be no doubt about that.

I do find it ironic you think this project is making rash decisions on no technical merit, and not Bun

To me, proving a vibe-coded piece of software is fit for purpose is much more difficult than if it is human-written, or LLM-assisted with a human reviewing all the generated code.

That’s as reasonable as it gets. Yt-dlp isn’t a beta testing grounds for hyperscalers.

It's not a rewrite exactly. Nobody wrote anything. Not a single human has even seen, much less understood those 1m lines.

Also I don't think it's wrong to use an action as an input to judging engineering character. That could be read as judging yt-dlp or judging bun but in this case I mean it's reasonable to judge bun's developers.

IDK if i'd personally judge this action quite so badly though. It depends how they went about it and what they proffessed to get out of it.

I am very much against letting llms think and decide for you, but I don't think it's so wrong for an actual coder to employ automation.

But if they are acting like it's magic and everything will be so much better after the magic llm uses the magic safe language... yeah that definitely gets the side eye. Or no eye. Just no longer interested in or concerned with their output.

Since this is being offered as the next release version while still being new and stuffed with unsafe, looks like it's the latter. So I'm with yt-dlp in this case.

It doesn't matter if the new code happens to be ok or not, it's still a problem that they got there by hoping a black box does the right thing. A black box that that no one wrote and no one understands, not just themselves.

gcc is a black box to me, but I know that someone wrote it and understands it (or some people collectively understand all it's parts), and I know that any time I want, I can choose to understand any part of it, and satisfy myself that it is doing something both sane and deterministic.

So a developer choosing to use gcc when it's a black box to them does not reflect badly on them to me.

But no one can say that about any llm or ai. So yeah, a developer choosing to use them, depending on exactly how, may reflect badly on them.

The same was true for cheap off-shore gig coding by humans too. I have tried to use them myself in the past, hire out for small generic programming jobs using those web sites where you put up some escrow money and post a job and people bid for it, you choose one, they do it and get paid from the escrow. I only tried about 3 times for the same small job and every time I git ridiculously shit (but technically functional) results.

These were humans 15-20 years ago, no possibility of hidden ai usage like today, and it's essentially the same dynamic of just hoping some magic will get you something good for cheap, and accepting any result that appears good as good.

If someone said that that's how they made their product, I would decide that product is probably pretty crap inside and no way should I buy it or invest in it as a dependency if I have any choice.

And that's humans not ai. The problem isn't really the ai, it's the judgement to use an ai that way.

If they said we will rereview in 1-6 months or whatever the whole discussion would be mute.

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

Given that part of their announcement is to keep supporting pre-rewrite versions of Bun, it implies to me that they are open to reconsider if the Bun team cleans up their act. I don't think it could get any more reasonable than that.

Bun shat on community and yet-dlp owed them free testing? No, sir.

Folks generally tolerate issues if they believe they’ll get better with time. I know I did for a while. If that confidence collapses, that’s not politics.

I don't see politics, I see frustrated maintainers of a hobby project that aren't particularly professional.

- A single bug about EJS, which was fixed almost a year ago and has never regressed.

- Frustration that Bun was rewritten in Rust, which "seems like a future headache" - i.e. no evidence of current issues, just something which they suspect might have issues in the future.

If you see more evidence of more bugs that weren't fixed almost a year ago I'd be curious to see it.

We've known for decades that machine-translated code is garbage, and should only be done as a last resort.

Seriously though, that's an overly-pedantic definition of a compiler. Broadly speaking, languages compile in a direction of decreasing abstraction. Crossing from one high-level abstraction to another is just asking for trouble, especially in this case where the target language makes very specific performance promises as long as certain abstractions are maintained.

What are you talking about? There is no upstream rejecting contributions here. It's the original bun developers who vibe-ported it to rust and they absolutely could and did upstream their vibe coded changes because they are the upstream.

https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...

Bun were so excited about their 4x speed improvement that they missed that Zig had already implemented it, plus other optimisations that were far larger.

Nothing in your link supports this assertion. Lots of things in your link support the exact opposite in fact, that the Bun team explicitly chose not to attempt to upstream the changes.

They may have been rejected for being vibe coded if they were original, but they were rejected for being pointless. The rust rewrite was because Bun was butt hurt that they didn't actually help.

If we're gonna fight, lets go xbox vs playstation. Javscript runtimes are a snoozefest.

What kind of code can't node run?

At the same time, his arguments in favor of Rust are sound, there is no doubt about that.

Yeah he never said that.

> This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.

And then fully merging into main in under 18 days is quite extreme

https://news.ycombinator.com/item?id=48019226

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.

I hate to be pedantic but for a whole host of environmental reasons, they are suboptimal, and it still incinerates money to lose a rocket during a flight test.

In case you aren't aware, the whole codebase of Bun did not explode into debris just because it hit a bug. They can just fix the bug and recompile.

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 am one of the old guys myself lol

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.

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

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.

I see lots of ground for that claim.

Once bitten twice shy, y'know. Maybe the first bite wasn't even from bun. If bun can't take this on the chin and come back stronger, maybe bun wasn't a good choice to begin with. I'm sure a future version of bun with a rebuilt reputation will have an easy time getting re-adopted by most projects that needed to play it safe during the transition.

You're telling me that isn't good enough? You might need to head off to the VC reeducation camps.

Somebody needs to have read deterministic code to even have a chance of noticing something being wrong.

This has not happened here.

or... they just trust that their ai got it right, which to most people is "vibe coding".

I really appreciate the maintainers' effort towards this awesome project. However, I think it is fair to be a little bit less confident with the current state of Bun.

Jarred promised a blog post just like he promised to not merge the slop branch.

Cool production? false

The 1M lines of code refactor by AI in a week or so then thrown into a production codebase... Yeah

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.

There's been lots of talk about it here and on his twitter and such.

So an OSS project now owes testing to hyperscalers? Lol!

Like rewriting Bun in Rust? Bun is a politically oriented project now, distancing yourself from it makes some engineering sense.

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

You cannot take back a promise after you make it. So if you discover bugs later you cannot just leave.

This script is just a JavaScript helper to bring full YouTube support to some media download tool. It does not seem important to anyone that executing it using Bun is supported. They support the Deno and Node runtimes.

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.

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

But you do select your engineering tools on faith apparently.

Can we at least try to be a bit more accurate and less hyperbolic?

I will continue to use Bun because the same people that made bun have made this decision. I trusted them one week ago. I have used bun for the past 2 years, and so have many others.

I'm not about to just assume they've become immature idiots yolo'ing stuff overnight. They're still the same people they were a week ago. Or two weeks ago.

Are they the same people though? Their interests, goals, environment, incentives, boss etc etc all changed after they got acquired by Anthropic. Its not uncommon for a big company to acquire a smaller one and completely destroy that product to serve the parent company's goal.

Speaking of environment though, everyone neglects to mention that the Bun core team now has access to Claude Mythos. You think they haven't already run Mythos against this? So they have private access to the best cybersecurity scanner known to man.

Suffice to say, I'm yet to see anything that really worries me in any major way with this.

I think we'll just see how it all turns out. Maybe check back in a year or two on hwo it all goes. Anyone who says they "know" or are "very sure" this is the right path or wrong path is plain stupid IMO. Having seen how things work in big companies with high market visibility, I believe there is non-trivial chance this driven mostly as marketting stunt (particularly in current climate) and decision isn't purely based on best interest of Bun's future and longevity.

thought out?

https://news.ycombinator.com/item?id=48019226

> This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.

I ain’t reading a single thing from the guy after this one.

Didn't they also change the tests to make the re-write pass?

I'm sure macOS has an extensive test suite that Apple runs as well, and yet still people suggest waiting a bit before adopting a new macOS release.

An extensive test suite can prove that you have regressions when you change the code, by showing you one or more newly-failing tests. However, it cannot prove that you don't have any regressions; it can only increase your confidence somewhat.

LLM generated code is garbage, not because it writes obvious errors. But because it lacks any kind of reasoning - Claude will gladly write you a solution for a problem you never had. Good luck fixing these kind of issues that will never be catched by tests.

> I'm not about to just assume they've become immature idiots yolo'ing stuff overnight. They're still the same people they were a week ago. Or two weeks ago.

They’ve literally sold out to Anthropic.

But this also isn't a fair comparison. The article doesn't say "let's wait 6 months", it says they are fully deprecating Bun. Those are two very different statements. I would have had no issue with the first.

And FWIW I think my viewpoint is the uncommon one. Look at all the responses to a previous thread about it [1] and see how many of them are negative. It's certainly a majority.

https://news.ycombinator.com/item?id=48133519

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.

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

So, great, if this dude wants to regress through the workforce to a level of engineering maturity I associate with a high school student, I don't wish to try to be the one to stop him. Doesn't mean I'm gonna follow him. It's possible to be smart enough to just not walk into the tarpit. He's going in, I'm not.

Regardless of the other aspects, this is a joke in any context I have been in since I started working in this field about 9 years ago.

Even as pure logic, you know they do what you want it to do only after you chose them. You can’t possibly be trying every option to the fullest capacity of your application.

You also converge on the “Jarred” aspect and the guy that made the decision in the title post has the opposite sentiment

Among tools that meet a technical expectation—especially for (often) superfluous activities like downloading videos—I pick one that feels right and costs the right amount, and that's the one that wins. Free + works + usable is an unbeatable combination.

However, I'd argue their decision is related to a peer dependency than it is itself one about an engineering tool, which is an assessment of the risk surface and potential cost associated with doing so. I already wasn't using bun at all, but if they stopped supporting whichever runtime I do use, I can either adapt or stop using yt-dlp, which I won't because this isn't a technical thing worth wasting much time on. This mild, recent change to recently introduced peer dependency integration is largely inconsequential, and I support the call to not waste time providing extra support if it hypothetically became necessary.

Those bad feelings are often your years of experience trying to tell you something.

> feeling like worse software

Politics ;)

It is significantly easier to modify code that you personally wrote, or code that you have read and understood to fix an issue in previously. This is why the maintainers of a project change slowly over time and it takes a long time for new ones to get up to speed.

All of Bun has been rewritten by a tool. In a different language that maintainers may not be fully proficient in.

Even though the rewrite was done well, and even if we assume it's functionally equivalent to the old Zig code, there will still be future issues. And ALl of the maintainers are essentially now new hires who have never seen that code in their lives.

It's not "politics" to have an ounce of sense to foresee problems in such a project as a dependency.

What happened to

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

Who cares if you have a good feeling about this dude? There are obvious and clear conflicts of interest at play here. If you care at all about quality, you'll wait before adopting new releases until bugs get discovered/ironed out. Don't adopt based on some dude's reputation when that reputation was built under a very different incentive environment.

Project governance is very important on a project; the fact that Bun's authors bent the knee to their new owner shows where their priorities lie.

> Have you observed Bun have more segfaults, OOMs, etc, since the Rust rewrite? Have you noticed more security vulnerabilities? Have you seen more bugs?

I - them - are not going to sit around waiting for bugs to start crashing everything

> 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

Good thing that you don't run an open source project then, I would remove anyone's project from my dependencies who thinks like that.

Not caring about governance is how we end up with repeated supply chain attacks.

Will you use untrustworthy dependencies in your project, which has users? I think, no.

I don't know, but I feel that this is the case with yt-dlp.

And this is absolutely engineering - care about quality and security of your software, which is used by thousands of people

With that in mind, is there anything that yt-dlp uses the Bun runtime for which it can not use the other supported runtimes for? Similarly, perhaps the yt-dlp maintainers shouldn't keep supporting Bun just because it gives them a good feeling when every runtime incurs a maintenance cost.

That said, as a developer I skim over so much bullshit simply based on "bad feelings". I don't have time to evaluate every potentially useful technology in terms of whether it does what I want it to do, and no one else does either. It's clear to me that Bun is in an experimental phase of development and I think that's a good enough reason to move on if your use case is not.

Bun made a snap decision to merge 1M lines of unreviewed code within a week, including code generated moments before the merge. AI or not, that forces downstream users to cope with total unpredictability. This process bears no resemblance to science or engineering.

All the QA work you're demanding of yt-dlp is work Bun should've done. Trying to flip that responsibility proves your argument isn't grounded in engineering principles. And you sure made your feelings known in your comments for someone who claims not to let emotions affect technical decisions.

yt-dlp made a sane technical decision to drop a high-risk dependency. Not only is the Bun code now unpredictable, but the maintainer is too. The maintainer called the rewrite "experimental," then merged it within a week. If direct statements can flip overnight without warning or explanation, it's no wonder downstream projects want out. Especially when yt-dlp already supports alternative JS runtimes.

The argument that you somehow cant unless you go through trouble of testing it is way more "politics" and way less "engineering".

I have a t-shirt signed by THE Jarred himself, how much are you willing to pay for it? Comes with a month of free Claude max subscription.

It is impossible to review the entire rewritten codebase. There are just too many lines of code, 1 million lines to be exact [1].

[1]: https://github.com/oven-sh/bun/pull/30412

Isn't this suppose to be the most advanced model ever and you're telling me they can't just schedule a cron job that detects and repairs the zig version?

Really? Did they just completely admit that the great AI future can't secure a significant project repository?

The challenge is: They already were decoupled. They've forked Zig. If your desire is to make a bet on generated code and reasoning as the entire future of software development, as Jarred and Bun have; why would you chain yourself to the crazy political nightmare that is the Rust project, when you've already got a language & runtime that's treated you well, is forked, your contributors know well, etc? Literally: Why can't these issues be fixed within the context of BunZig? Why don't they want to own the whole stack?

It’s all the same just different syntax. Which, by the way, is why it looks ugly to rust developers. The devs wanted the code to look familiar to them.

I do think they should have called this 2.0 though. Would not feel such a rush (1.3.14 has a few regressions, and no one really cares because there are lots of small rust fires now).

Overall, the bigger issue is that bun chases shiny objects. But never finishes. Just look at test stuff. Most of vistest, but not all. Most of jest, but not all. Most of pnpm, but not all. Now we have image stuff, so most of sharp, but not all. dev server? Most of vite, but you guessed it… not all. Long running process… mostly like node but with memory leaks (and a motivation for rust I’m sure).

When I saw them posting about the Image routines my heart sank. Another shiny object. Coincided with test bugs so I moved to vitest completely.

With quite a peculiar set of supported formats different between operating systems.

As lots of large and small companies have shown, test suites can only find what you test for. Vibe coded test suites can find?

It does a reasonable job. Its also pretty good at writing regression tests when it fixes a bug.

Where LLMs struggle - or at least where claude struggles - is fixing the actual bugs. Its very good at getting the test suite to pass. But it cheats. It'll sometimes disable a test, or do some hacky workaround that makes the test pass that doesn't fix the underlying issue. It'll say "All done, the tests pass". But sometimes you really wish they didn't.

I'm wondering if it might be better to set up 2 agents adversarially for bug hunting. Give one agent the goal of finding as many bugs as possible (via tests and other techniques). And another agent has the goal of fixing the bugs.

I’ve tried all sorts of things to keep Claude from cheating, but the only one that works is to restrict access to the tests files, which obviously isn’t a real solution.

We recently had an “AI week” at work and I spent $1000 in tokens trying out different iterations of this.

That reminds me of Chris Reigrut's story from https://thedailywtf.com/articles/Holiday_Smorgasbord

Thanks for the chuckles!

>>> log.fatal("Aaaaarrrgghhhh");

Reminds me of working at a small Japanese company and someone had written a try-catch for retrieving a crucial bit of config that just logged "X missing. This is disuster." and terminated.

What if there was some malicious code within the 1 million lines?

The problem is trust... About nobody has the time and the resources to read 1 million lines of code, keep everything in their head and derive whether there are problems...

1. Are we positive the AI didn't cheat when getting some or most of them to pass? Are we sure it didn't just cheat on even 1 percent of them?

2. Are we positive that the AI didn't introduce bugs that the tests didn't think about because there was no need to think about that before (because actual people understood the code)? And therefore, those things go untested, and nobody can write good competent tests for them because nobody understands the code in the first place.

Not really. At some point the technical debt accumulates and the only option is to trash it all and start over.

The only party that profits here are the cloud token providers.

I think you are not understanding the new paradigm. The idea that 'humans are going to understand the codebase' is dead. Codebases will be maintained and reviewed by AI. You might think this is bad, but in many aspects of human history, we have traded understanding for convenience—that's the reason why we buy food at the supermarket instead of hunting for our meal. This has happened in every area of humanity, and it seems foolish to think that code generation would be immune.

Again, you might think this is a bad thing, but it’s simply how humanity has been functioning. 'Oh, but who is going to maintain this?' AI. 'Oh, but what if one day that's not possible?' Well, what if one day the electricity goes out due to solar flame or whatever? You get it?

You could always take a job on a cattle ranch or an abattoir or meat-packing plant, or watch a How It's Made documentary, and get some understanding of how the sausage gets made and put on the supermarket shelf for your convenience. This was also true as we built abstractions in computer technology: you could start off learning a high level language, then learn a lower level one, then study or build an operating system kernel, a compiler, an assembler, machine code, and then crack some books on microprocessor architecture and signal processing. You could always "go deeper" if you wanted to. And there is a payoff: understanding at a deeper level helps you get things done better at the higher levels (e.g.: understanding the concept of memory hierarchy helps you lay out data structures to make code faster).

There is no such step for slop-coded codebases: you become entirely dependent on a context-limited LLM to have a shot at even approximating some understanding. The proponents of this style will tell you, don't look at the code. It's the antithesis of every other abstraction we've built in computing.

Perhaps more productively, you treat the slop as a black box and build something understandable around it.

This is also why the notion that developers in the future will be committing LLM prompts in English to repositories instead of code written in a programming language is so foolish. I am saying this as someone who uses LLMs quite a lot to help with generating and understanding code.

Understanding every corner of your codebase is overrated. LLMs, properly harnessed, are good enough.

The entire chain from farm to table is managed and operated by humans.

Every automatization effort ever always had human oversight.

Its not the same thing as entrusting the entire codebase to overachieving markov-chain who has no concept of correctness over anything of sounding ok.

Honestly, saying the humans understanding codebase is a dead concept is the most techbro-ish I heard today.

Large LLM-written code is called slop for a reason. It's hard to understand because oftentimes it does not follow human logic.

It does matter, that's why those people quit because it's such a shitshow, progress happens at a glacial pace, more and more defects and slowdowns keep being created even if they have a big QA department/teams and the users are probably trapped because the software is the only thing in town, the bosses are the ones that makes the purchase decisions, or the it comes attached to big and/or expensive machines and they can't just buy another one for another X years.

It is not immediate process, but it is a thing.

The code base itself has never and will never matter in the big picture

Clearing my throat: I am the first person to tell everyone on the team (repeatedly, until they are sick of hearing it) that the users, use cases, and organizational objectives are always more important than the technology.

But, in "the big picture" - the Linux codebase doesn't matter? The codebase that powers AWS doesn't matter? Hell, the Microsoft Office codebase doesn't matter? Look at what's happening to Windows when they treat it like the codebase doesn't matter.

For a tech org, the codebase is the reification of all of your objectives, all of your knowledge about your users and use cases and processes. Long term, a mature codebase plus people who understand it is one of the most valuable things you have. When orgs don't realize this, when they treat their workers and their work product as disposable commodities, we call this "enshittification."

This is a massive codebase created within a week or so ago, no one can say what it will do till it does.

I still think it's mad, but not quite as mad as you might first think from the headlines.

Who wants to review a brand new codebase for free?

https://bun.com/blog/bun-joins-anthropic

With zero reviews and no one even reading the code, there's zero confidence. For all we know, the new Bun could contain a change that causes JS file reads to return a novel for a very specific filename, and the tests people keep pointing to, intended to downplay the malpractice, would never catch it. Tests cannot cover every contrived scenario that normal human beings would never think of writing.

Well, they didn't really need to. A complete rewrite is effectively a different project. You may feel comfortable using a new project in prod, but most people are not.

Project A: used in production for 3 years - high trust.

Project B: Has yet to be used in production - low trust.

IDGAF about automated tests, let other users shake out the inevitable bugs that show up in prod and after a few years of stability, then we'll see.

To me, it's not about whether humans reviewed the code or not (they didn't), it's more about "here's this brand-new shiny codebase of ~1m Sloc, of which exactly zero lines has been used in prod".

To create a PR, I need to test it manually. But the only true test is to survive production usage for a while. That’s where edge cases become normal occurrences.

10 engineers each reviewing 5,000 LoC a day for 20 days can do it.

And that is being highly conservative with the estimate. A good chunk of the the code is probably highly trivial boilerplate one can easily skim over in minutes.

You'd be just looking at both files, side by side, to make sure nothing was lost in translation or newly introduced.

In old days we chose between Turbo/Borland C, Quick C and GCC. We didn't think them same or trust blindly even if we didn't know how they worked.

The best developers hand optimized assembly for sub routines which they knew compilers were not good at, the rest of us sure didn't understand how any of it worked, but nonetheless felt the differences and chose with dollars and usage .

If you have enough tests at what point does AI rewriting software in a different language become close enough to ‘deterministic’? Maybe never, maybe not.

Counterpoint: I look back at code I wrote a few years ago and just take it on faith that I knew what I was doing at some point. That's still better than never knowing, but it requires faith--faith in a human, vs. faith in an LLM.

More importantly, it's not the same thing at all. All the code in windows (at least until recently) was written by humans, understood by humans and reviewed by humans. And that code has stood the test of time, proven its value and stability in the wild, on billions of systems. The fact that the current maintainers haven't needed to understand or replace the code is some indication of the code's quality.

Almost none of Bun's rust code has been even seen by a human, and it's only about two weeks old.

I'm somewhat willing to accept vibe-coded code if it's either absolutely non-critical, well reviewed, or maybe in the long term if it's proven itself. But not two week old code.

But I think the comparison is closer than you are making it sound. I sincerely doubt the Windows codebase was all written by humans, let alone reviewed. And my understanding is that the code is being regularly rewritten and replaced because of how flawed it is, it's just a massive undertaking.

Also if you look at their investment in AI-driven code rewriting into Rust, my bet would be that some modern Windows code itself is being vibe-coded.

It is far easier to understand some part of the various NT source code leaks than it is to understand Claude code leak

All of which was battle-tested on millions, if not billions, of devices over 40 years. The new Bun is effectively a different project than it was a month ago, with next to no prod use.

I have no problem having a dependency on a 40 year/billions of use software, I do have misgivings about a dependency on a project that has never been used in prod, and was only written last week.

There are countless reasons that this is a very bad thing for consumers of Bun. First and foremost you've instantly lost any and all assurance that it works the way it's supposed to. Every project has load-bearing bugs that may or may not still exist. Can you trust the core behavior is the same?

If the Bun maintainers are willing to completely replace their core product over the span of a week, how is anyone supposed to rely on it? What's preventing another rewrite in a few more weeks?

If you want to position your product as a dependency, it needs to be stable and reliable. Throwing away a million lines of code and replacing the entire product overnight is pretty much the polar opposite of stable and reliable.

It has nothing to do with AI rewriting the code, it's the reckless abandon and wild disregard for consumers that is the problem. It's literally a rug pull.

I feel this argument is not valid, especially for large code bases.

Documentation and code quality is what is important, not who wrote the code.

To be clear, I'm not implying support for the merge. I am against this whole YOLO approach to engineering. Just curious how the switch is going since I haven't seen any news since the merge announcement.

The name? No.

The author? No.

The test suite? No, testing is hard and most projects don't do enough of it.

The code? Not really, code can be rewritten.

The history of the program being executed by its users? Ding ding ding. Yes, it's this one.

Bun no longer exists. What exists now is a program that has the potential to be Bun but at this time is not Bun because it has no history of being executed as Bun.

If the rewrite has been done piece-by-piece or over a longer time period then this history could have been built up over time. As such we will have to wait a while for Bun to exist again.

Name being the same or not, it's what it is in reality (for better or worse)

you could write a great program and never run it. does that mean the program does now not exist? or that it is not a new, unique thing?

if anything, the essence of a program is made up by all of the things you mentioned!

If by machine translation you mean something like transpiling, that's a technology that has been proven over decades, and the translators were written by hand with some attempt at formal correctness and guarantees. Translating with LLM is much newer and subject to the errors LLMs can create, such as hallucination. And I think a lot of people would still be nervous about translating an entire project of that many lines, even with the best pre-AI translators.

Any software engineer that still rejects the concept of agentic coding is frankly NGMI. If you still see AI this way, you simply never bothered to update your priors, which is just not survivable in this career. I do hope you're already independently wealthy.

> I do hope you're already independently wealthy.

Nah, I'm good. I'll be selling llama.cpp slop to people like you when I retire.

And what are you referring to as "behavior"?

BUT.

"Ignore anything but actual problems" is a terrible stance to take generally for software and dependency selection. Incidents are fairly sparse, process is much easier to observe. So if you can find connections between process and incident possibility, that's a very reasonable heuristic. And it's easy to find examples of overaggressive LLM usage introducing problems into software.

The vast majority of new software is written using AI. The problem is not that it is written by AI, but rather than some people treat it like a black box. It is entirely possible to use AI to write code and verify that it is correct. Even Linus Torvalds is allowing AI generated code into the Linux kernel as long as it's managed properly.

How on earth does this follow? It's common, so it should be accepted without scrutiny?

>The problem is not that it is written by AI, but rather than some people treat it like a black box.

Yes, and guns don't kill people. Obviously the issue has two facets. It would be irrational to say "AI is flawless" or "humans are flawless".

Allowing genAI code does not imply blindly trusting genAI code.

>as long as it's managed properly.

Correct. Hence the issue. This was vibe-coding by even the strictest definitions of the term. Vibe-coding is, by definition, not "properly managed".

As far as testing - yes, they do have a test suite that it was checked against during the rewrite, but that still means that any behaviour that wasn't strictly tested for by that suite could have changed and it would still pass.

Not even 10 percent is. Good lord. Go outside and touch grass.

(Hilarious in the way that's terribly sad, of course.)

https://news.ycombinator.com/item?id=48243990

Not even the same tests, as far as I can tell. That million-line PR touches a lot of test cases...

So just maintain Bun fork of yt-dop, problem solved.

Nobody knows.

Or did we forget software inherently is opinionated

if it works, it will keep working. they just don't want to support and maintain it and solve issues.

Unfortunately, his followers don't realize that something like a batteries-included runtime is a huge commitment to build on top of, and governance you can trust matters as much, if not more, than the lines of code.

The way this has been handled is just baffling. A Rust rewrite is supposed to be a freebie for hype, and even an AI rewrite could have been interesting if approached more scientifically and transparently... but instead the opposite of that happened.

I think you cannot make this comparison because Rust version wasn’t in fact written by the Bun team. It wasn’t even read by them.

Not really an argument on its merits.

Claude says it’s all good though so what could go wrong

I’m no AI hater, but there’s a limit to how much trust I give it and the Bun rewrite is well beyond that limit.

I think the issue is, we understand our own usage of it, and respect the boundaries of what's possible and what needs to be done to use these tools properly.

But we don't know how the other guy is using it.

We don't know if they're being responsible, and using it in a safe manner.

If they are: great. But if they aren't, we're opening ourselves up to all kinds of security shenanigans.

It's one of those things where we're only going to be okay with it, if we're the ones using it. But that also means other people will be suspect of our code.

It's really a no win scenario, except for inside each of own little bubbles.

It was used to write 1 million lines of code in a week.

Yes it was translating an existing codebase, but still there’s no way that is a safe transition.

Would you ship that at your job? I definitely would not

Bun has very loudly defected from the former category to the latter.

Yt-dlp devs made a good call. If Claude is good enough to rewrite millions of lines of Bun, it is good enough to maintain Bun fork of yt-dlp. And since Bun is part of Anthropic, they can afford it too.

It's a big slushy of emotions that I understand (both positive and negative) but it makes it so hard to actually tells what problem someone actually has when they just use "vibe coding" as a general LLM usage slur.

I'm using LLMs to assist my development and I'm measurably (in all the ways we engineers could possibly care about) doing better work faster.

https://x.com/karpathy/status/1886192184808149383

In the case of this specific port, the port was done so fast that it is clear humans did not verify the soundness of the translation. It is not clear whether this manual verification will ever occur.

That being said, most software projects were already doing "vibe coding" by Dijkstra's standards long before AI showed up. Going on vibes and forgetting that correctness even exists ;)

Guaranteeing the correctness of complex code is difficult, but it will increasingly become non-optional as we now have a billion hackers in a data center.

---

Edit: "Bun's unreleased Rust port has 13,365 unsafe blocks"

https://news.ycombinator.com/item?id=48239790

    I'm using LLMs to assist my development and I'm measurably (in all the ways we
    engineers could possibly care about) doing better work faster.

Writing code is rarely the limiting factor in our work.

This result wouldn't surprise me if the tooling was limited to, say, copilot :)

It would surprise me if it included tooling like Claude Code. Which seems unlikely, given its recency.

I'm not vibe-measuring my output ;)

I agree the maintenance burden is probably being undervalued by developers in general, but there's just no way the work I do isn't faster. I just categorically couldn't have achieved the outputs I do now in the time windows I have. The software just wouldn't have existed in the world of 3 years ago and I did enough coding back then to say that with certainty.

I know it's anecdotal, but I have so much data from my own experiences and those of my peers that I know these new tools are here to stay. It also makes me believe that those studies are either flawed or out of date.

> Due to foreseeable compatibility and security issues

Hmm, Zig bun crashes plenty.

I wish yt-dlp linked to detail on why there are foreseeable compatibility issues. Both projects have test suites, in an ideal world they would allow fast rewrites. Maybe they want to limit inflaming the situation, but if they have spotted some specific issues it would be good to see.

I hope Bun.rs is 1.4 or even 2.0 and not a minor release, with some alpha/beta releases.

But it's been available for a week. And so far, seems like crickets on actual data on any regressions. It's more "I just don't like this!" style grumbling.

It should be a major release indeed, and communicated as such, with full accountability of the migration beyond an “all tests pass”. A major tool should move slower, be tested longer, more thoroughly, since it’s used my millions.

It’s reminiscent of JavaScript world, where something is in beta for mere days (e.g. Expo’s short release cycle).

    bun upgrade --canary

I still hope there is a beta release.

First they essentially wrote a translator that preserved the C idioms (so it wasn't idiomatic go) until they had byte for byte output.

Then they started changing code one by one to be more Go-based.

Bun is doing the same. Right now it is mostly a one for one translation of the zig code. Over time they'll make it more idiomatic Rust.

    primeagen's view

It’s just someone quoting someone to help ground their position.

What if it was a journalist writing about a security vulnerability then a programmer quoting them, would that count then?

It's pretty clearly a type of argument called an "appeal to authority", where an authority is cited to add credibility to a position. It's usually considered a pretty weak form of argument, but it can be effective. So the credibility of the cited authority is relevant.

He may not be Don Knuth, Linus Torvalds, John Carmack or Fabrice Bellard. But he is definitely a serious programmer. That he livestreams doesn't make him less of a programmer.

Which defeats the purpose of having it in rust.

Identifying where code is unsafe, is a qualitative improvement. Not guaranteed to be complete, but more complete than a language that does not focus on that concern. Moving forward, the benefits of Rust compound. The concern about AI is orthogonal to the concern about moving to Rust.

Now there are 2 versions[1] that can be instrumented, regardless of the misgivings about AI.

[1] Bun v1.3.14, released on May 13, 2026 (commit 0d9b296af) and current.

> Identifying where code is unsafe, is a qualitative improvement

Agree. There was no need to merge that slop into master though.

In the post the maintainer says that an older version of bun "results in the ejs lockfile being ignored".

The reason is that they never committed the necessary lockfile despite listing "support" for that bun version.

They have separate lockfiles for other package manager versions: bun.lock, deno.lock, package-lock.json, pnpm-lock.yaml.

This part of the comment is also interesting: "which is a significant security concern for users when considering all of the recent npm supply chain attacks".

If you would set up a proper build for the JS artifact instead of committing four lockfiles to your repository, users would not be as exposed to npm supply chain attacks.

Deno and Bun have decent Node compatibility, so couldn't Node APIs be used as the generic runtime interface?

[0]: https://github.com/umdjs/umd

   --js-runtimes [deno|node|bun|quickjs]

Bun’s source code rewrite from Zig to Rust was executed primarily through AI-assisted development using Anthropic’s Claude agents, specifically within a branch named claude/phase-a-port. The project creator, Jarred Sumner, merged the massive pull request (PR #30412) on May 14, 2026, which involved over 1 million lines of code added and 6,755 commits completed in roughly one week.

And yet none have offered to volunteer their time to maintain a downstream fork or otherwise rectify the perceived problem.

Strange.

[0]: https://github.com/oven-sh/bun/pull/30412

Bun is also iterating back and forth with AI. The rewrite only got popular because of bigger scope. The bigger the scope is, the more bugs there are.

> getting node compatibility tests passing

So does Bun.

> which is something an LLM is very good at.

Doesn't matter. The code those LLMs operate on is simple enough that any middle software engineer can do.

That is to say, techno jesus cometh.

The PR that was merged.

a million-line rewrite over 7-8 days

What a nonsense generalization.

In this case, the speculation ostensibly is that in future, there will be a release version of Bun that has is buggier or otherwise lower quality than the current stable version.

There's literally no basis for believing that. The actual basis is "I don't like how they're approaching the development of their next version."

If that's a valid basis for "dependency management", then using a Ouija board would be just as valid.

I disagree. It seems to be an emotional reaction borne of ignorance and uncharitable assumptions. There's no "reason" involved.

2. Even if somehow you did make bug-free software with tests alone, even if the Rust port is at perfect parity with the Zig codebase today owing to the years of careful human work that went into building tests as a framework to guide the AI... the future can only be downhill from here. Nobody has a mental model of the new 1m loc codebase that's never read by humans, so Bun's future is committed to 100% vibecoding. Maybe the carefully planned tests minimized the worst case scenario, but the future tests will be written by Claude too.

If, and this is a big if, it turns out that there are no major problems and Bun is better off in a year from today than it is now... then somebody can just fire up Claude and fork yt-dlp to support Bun anyways and their decision doesn't matter. In any other scenario than human code becoming completely obsolete, they are simply saving themselves a headache by getting rid of a troublesome dependency.

I don't know any bad stories about ai-translated apps. Partially because it's a relatively new trend, but also because a big amount of usual vibe code fail modes are not applicable here.

There's something really satisfying about a go binary with minimal dependencies running in a busybox docker container.

Most complexity is unnecessary. Adding dependencies to your project exponentially increases your project's surface area, which in turn increases its regulatory/cybersecurity burden, especially if your software is a medical device, munition, etc. Why is Echo/Gin/Gorilla/etc better/more secure than vanilla Go's mux? Just anecdotal, but we use the Echo web framework for Go and it's caused nothing but headaches. It does magical XML parsing by default even though we don't deal with XML which gets us flagged in pen tests. Updating from v4 to v5 broke production for us because they made an undocumented server config change that makes all requests have a 30 second timeout. Meanwhile vanilla go has the ability to register routes and middlewares, so what value is Echo bringing to the table? Ditto for lots of other unnecessary dependencies. A lot of times we just need one little thing out of the whole package, and in those cases a little copying (or a little AI generation) is better than a little dependency.

A static go binary with minimal dependencies running in a busybox container has a tiny CVE footprint when run through grype/snyk, etc. Do the same for a NodeJS app with zillions of dependencies running in an ubuntu container and you'll spend all day triaging CVEs.

I'm not saying "roll your own crypto" but I am saying "axios-like packages don't make sense to use any more in a world where AI+vanilla accomplishes the same thing"

[1] https://go-proverbs.github.io/

> Removed: mathjs dependency. 14MB, 200+ functions. Twelve functions used. Added: Custom math utilities module (src/math-utils.js). Addition, subtraction, multiplication, division, a handful of trig functions. Co-authored-by: chatgpt. Changed: Bundle size reduced by 68%. Build time down from 12s to 4s. Module: 47 lines across 1 file. 0 tests. 0 dependencies.

That it took so long before they started trying to phase out their home-rolled library for the "hard cases" is somewhat unrealistic, although possible in a sufficiently-dysfunctional organisation. Some of the details about the problems of their homespun library are clearly anecdotes translated from other settings, and are unrealistic in the context of a mathematics / finance library. (They only noticed that interest calculations were wrong when a customer complained? Seriously?) The development of 6.1.0 (via 6.0.0) taking only two weeks isn't congruent with the rest of the story, although it may be realistic for AI-driven development (with which I am unaccustomed).

But otherwise, this is one of the more realistic satire pieces I've read.

I'm quite liking how good Claude Code Opus is at Rust + sqlx (raw SQL with type safety) + actix-web.

Go binaries are immensely satisfying, but I don't follow your logic here. The vast vast majority of dependencies in Go do not depend on the outside world, so the binary would remain self-contained whether it has 1 or 100 dependencies, no?

The "self contained" part is only important in that it lets you use busybox or "from scratch" as your container runtime environment which has a very tiny cybersecurity surface area compared to, say, ubuntu or even alpine which has a bunch of system libraries your go binary isn't using, but which could still get flagged for having vulnerabilities.

Minimizing dependencies of the go binary is a separate, but equally important task that reduces the cybersecurity surface area of your go binary itself to just "the go standard library" instead of "go stdlib + a dozen github packages"

Whenever I am working with a NodeJS project I pity the fool who has to do SCA because the CVE surface area is enormous compared to go, which has a fairly batteries-included stdlib

https://jxself.org/shifting-the-trap.shtml

You can run a BF and, soon, subleq.

To be fair, I'm not quite sure why it would prefer either Deno or Bun when it's far more likely that a user has Node on their system.

Read the "Notes" sections for details.

It’s not the same obviously, but here’s why I can’t help but view it analogously:

The only truth in software is whether it works or not for whatever your use case is. Even before AI, we couldn’t have known if the author of a piece of software was proceeding with rigor or just trying random stuff until it seemed to work.

In other words, we didn’t judge someone’s software by inspecting their methodology or what tools they used. Heck, we often ended up using software that had no test suite or where the test suite was junk! And so many of us who are fans of memory safety use tools written in C, and vice versa (I’m no Rust fan but I use plenty of tools written in Rust).

So yeah, the logic that goes, “I won’t use your stuff because I don’t approve of your use of AI” is about as believable to me as if you stopped using something because you didn’t like the authors choice of editor

That's wild. You should read it as being nowhere in the same ballpark nor adjacent ballparks as that.

C’mon, pal.

So let's say they up the ante and set up a cron job to rewrite the entire codebase in a new language on the first Monday of every month: from Rust to C++ to Go to Swift and back again.

For customers using the product, that's basically the same as a maintainer switching editors? Irrelevant detail?

I don't think many would say the same for LLMs.

Maybe vibe bun is just as good or better than old bun, but how would we know at this point?

> ...we couldn’t have known if the author of a piece of software was proceeding with rigor...we didn’t judge someone’s software by inspecting their methodology...

That's not true. First, some people do directly check whether a project has a level of rigor they are comfortable with before adopting it (or when deciding whether to continue using it). I personally do it, where it matters. Many more use reputation signals, which, while certainly not perfect, correlate, may be good enough, and are a lot easier than direct, manual reviews.

By considering objective facts like efficiency, performance, error rates, security vulns etc. like we always do?

We care about those things you listed and also the fact that code was written by (or exhaustively reviewed by) a sentient consciousness. It's just that the second thing has historically been implied. That's the difference you are experiencing.

Someone would have to do a bunch of work to establish these things.

Don’t worry, it’ll just be in a different language.

Zig bad, rust good

You bad, ai good

and then some random posts in between that try to create some hot takes for upvotes. What is the internet at this point?

This is just the standard misguided entitlement people feel towards other people's projects supported by other people's time and effort. It's continually outrageous to me how people feel they can just volunteer other people's time and effort to support their own wants. The people who do the work are entitled to make their decisions and if you don't like it fork it yourself. This has been the way of this ecosystem since it started.

yt-dlp is surprisingly hackable as is.

There really shouldn't be a reason for vibe coders to complain about any software decisions. Vibe coding a personal fork you better agree with should be a piece of cake. Isn't that part of the vibe code promise?

It appears they mixed JS building into their python project, aiming to support multiple package managers which are executed from their python script.

This explains the otherwise non-sensical explanation about bun < v2 ignoring the lockfile: they use a separate lockfile for each package manager. They did not check in one for bun v1, which they claimed to support, consequently it is not using a lockfile.

That's not how JS packaging normally works. I would set up a separate folder for the JS project, and use one package manager to build the project, like anyone else does.

Publish the package to npm, or bundle the tarball with your python program.

I guess the permission model of the JS runtime could be another topic, but at least they would have their build fixed without worrying about Node dependency resolution and package managers in their Python code.

The test suites passed so it's all good.

There's the "what it achieves" today; software x works as intended as of right now.

And then there's "what it achieves" long term.

Those with significant experience with sprawling, LLM-generated, codebases, often built by those who don't understand the code produced, can attest to things being good today, unworkable tomorrow.

While this isn't true across the board, and my own experience should be considered anecdotal at best, those who consider "what it achieves" to also include long term viability as a success metric, are skeptical of these types of changes.

Personally, success for dependencies isn't just "does it work today" but "can I trust it to work long term."

I don't use Bun. I don't care about Bun. But my opinion is that how code is produced will have some effect on what it achieves, if the goalpost includes more than "it works today."

On one hand, it seems very scary to me, having most of your codebase unreviewed.

On the other hand, it passes their tests with few regressions from what I heard.

Maybe it's just because I don't have enough experience there, but I wouldn't trust my tests to this degree and completely rely on them without reading the code.

Technical debt was a reality before vibe coding. Someone was writing all that trash by hand.

> Someone was writing all that trash by hand.

And reading code written by AI isn't the same as reading code written by a real expert person.

There still exists the difference of quality of the written code and people who use AIs are lazy enough to accept code with vulnerabilities - see https://news.ycombinator.com/item?id=45034496

"Well, why don't you install and only then resolve issues if you have those difficulties?" most comments here are asking, in effect

Cause you're sane, that's why!

Same here. yt-dlp does not owe it to anyone to beta test things. Maybe this bun rewrite will be the best thing since sex, and maybe it won't be. Not wanting to alpha test someone else's shit is sane. And the bugs (if any) would go to yt-dlp, forcing them to debug someone else's alpha software. This is a sane response.

Obviously the JS build should happen outside of Python and use one package manager instead of attempting to support them all.

And to be honest bun's zig codebase (especially in the early days) was neither "clean" nor "idiomatic" but the tool worked and people used it.

You trust for someones expertice.

depending on the environment of choice, these runtimes are only used to bypass certain blockers. it is not that deep.

[1] https://news.ycombinator.com/item?id=45898407

That's underplaying it quite a bit. They are needed for non-gimped resolutions on the certain little video service that the project is named after, and will be needed in more cases for it in the future.

I don't use Bun, but we (and many others) depend heavily on numpy. It's been around for decades and heavily battle tested. If someone came out with a new version of numpy vibe-code rewritten in a week, with assurances that "all tests pass", do you think we would adopt it? Absolutely not. We would have no confidence that there aren't some latent bugs or that we can fully trust the results.

It has nothing to do with AI having rewritten it, it has to do with being battle tested over time. If a team of humans had rewritten it in a week, I wouldn't trust or use it either. Maybe after a year of it being widely adopted. Not before.