15 ms·

Bun support is now limited and deprecated

594 points by tamnd 5mo ago

winrid 5mo ago
What does this use bun for? I thought this was a python project?
- aarroyoc 5mo ago
  They need a JavaScript runtime to execute some challenges that certain pages present (like YouTube)
  - tym0 5mo ago
    They used to have their own "youtube script interpreter" that was kind of fascinating. But yeah as you said they switched to proper js runtimes recently.
  - user34283 5mo ago
    What they don't need is hardcoding support for five JS package managers in their python files. 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.
- deleted 5mo ago
  [deleted]
hootz 5mo ago
Oh well, I really like using Bun and I get kinda sad about the turn they are taking after the Anthropic acquisition. I really want a good Node with batteries included, but I don't want it vibe coded.
- LoganDark 5mo ago
  I think it's hilarious how hopeful people were at the acquisition that Bun would be able to continue on mostly as it had been but then that all got completely thrown away and trashed. (Hilarious in the way that's terribly sad, of course.)
  - abnercoimbre 5mo ago
    It usually takes years for someone's values to be thrown out the window! How long was this one?
    - em-bee 5mo ago
      changing your employer tends to accelerate that if the new employer has different values.
    - htrp 5mo ago
      "It is difficult to get a man to understand something, when his salary depends upon his not understanding it"
    - wiseowise 5mo ago
      Give man a Claude subscription and he can work for a day, let Anthropic buy the man and he doesn’t need to work a day in his life anymore.
    - LtWorf 5mo ago
      I don't think the man had any values to begin with. https://news.ycombinator.com/item?id=48243990 https://news.ycombinator.com/item?id=48243990
  - vosper 5mo ago
    How has it been trashed? Does the Bun software not work anymore?
    - happytoexplain 5mo ago
antonvs 5mo ago
Reason #2 is purely speculative. It’s disappointing to see technical decisions being made on such grounds.
- malfist 5mo ago
  What part of the recent history of vibe coded projects has not resulted in low quality, bug laden code? Dismissing this a "purely speculative" is just like dismissing the weather report as "purely speculative" when deciding what to wear in the morning.
  - cortesoft 5mo ago
    There is quite the selection bias going on here... you aren't hearing about the successful projects.
    - dawnerd 5mo ago
      Care to list them then? I have yet to see a successful vibe coded project
    - Dylan16807 5mo ago
      People love to brag about using AI to get work done. If anything I expect the successful projects to be overrepresented.
    - add-sub-mul-div 5mo ago
      With all the unprecedented investment and desperation behind it, these hypothetical LLM successes would be getting shoved down our throats.
    - asadotzler 5mo ago
      We're only hearing about the failed projects? I call BS. Precisely the oppositee is both true and obvious if you're not a shill. The "successful" ones are being trotted out all the time trying to convince us how great it is. If anything, we're not hearing about all the catastrophic and costly failures while the cherry-picked almost successes are all over this platform and others.
fastball 5mo ago
The "to vibe code or not to vibe code" holy war is now in full swing.
- nh23423fefe 5mo ago
  war implies "not vibe code" could win. that's impossible
  - nish__ 5mo ago
    There's literally nothing that LLMs can build that humans cannot. The only factor influencing people to use AI is time. They trade off a small amount of quality for a large amount of time savings. The tortoise and the hare parable comes to mind.
    - nh23423fefe 5mo ago
      so why arent you using punch cards? are you pretending time is not the most important resource?
mvdtnz 5mo ago
Wow, bun support was just added in November last year (I think). That's a lot of work to throw away, but you can't argue with their reasoning.
- em-bee 5mo ago
  bun is still supported for specific versions so nothing is being thrown away. in any case the actual code is the same, since it's all javascript. it's more a matter of the wrapper code that calls the different runtimes and maybe some edgecases where the runtimes are not 100% compatible.
satvikpendem 5mo ago
As long as Deno support is still there I'm not sure why you need anything else. It's not vibe coded slop for one.
- blain 5mo ago
  Well, apparently Deno is also a slop now: https://github.com/yt-dlp/yt-dlp/issues/16766#issuecomment-4521794212 https://github.com/yt-dlp/yt-dlp/issues/16766#issuecomment-4...
  - sheept 5mo ago
    Deno's LLM contributions have been smaller in scope, so they're more likely to be reviewed by a human, and the codebase remains understood by its contributors. Can the same be said of Bun, which switched to an entirely different language in a single, million-line PR?[0] [0]: https://github.com/oven-sh/bun/pull/30412 https://github.com/oven-sh/bun/pull/30412
    - szmarczak 5mo ago
      Since when small vibe coded slop became the norm? Because there exists bigger vibe coded slop, it's no justification to have a smaller vibe coded slop.
      - dsherret 5mo ago
        One shotting slop is very different from iterating back and forth with an AI. Also, most of the AI work that's being done has been getting node compatibility tests passing with the help of comparing that to the Node.js code, which is something an LLM is very good at.
        szmarczak 5mo ago
        > One shotting slop is very different from iterating back and forth with an AI. 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.
umvi 5mo ago
Honestly I hope agentic AI ushers in a new age of minimal-SBOM software. I myself am moving all of my projects towards nearly 100% vanilla where possible. For example, golang. Why use [insert web framework] when you can just use vanilla for 99% of web apps? There's something really satisfying about a go binary with minimal dependencies running in a busybox docker container.
- echelon 5mo ago
  Frameworks and ORMs were the pre-agentic AI "iron man suit". I'm quite liking how good Claude Code Opus is at Rust + sqlx (raw SQL with type safety) + actix-web.
- josephcsible 5mo ago
  Wouldn't that be worse? With dependencies, it's at least possible that someone else has audited the code, but with a vibe-coded from scratch app, it's definitely totally unreviewed.
  - Kiro 5mo ago
    You only add what you need instead of importing some bloated dependency. That means you can actually review the code yourself.
    - wizzwizz4 5mo ago
      Relevant reading: https://nesbitt.io/2026/02/16/changelog.html https://nesbitt.io/2026/02/16/changelog.html > 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.
      - olzd 5mo ago
        Are you aware this is satire?
maxloh 5mo ago
I understand their decision. How could the maintainers understand their codebase if most of it was not directly written by them? 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 https://github.com/oven-sh/bun/pull/30412
- thatxliner 5mo ago
  it's funny how the readme still says "written in Zig"
  - prmoustache 5mo ago
    If Claude isn't even able to correct the readme, I don't know how one can have hope it produces decent results.
  - sinpif 5mo ago
    Maybe it should say "designed in Zig" because most of the work & thinking was done using that language. The rewrite has no such history.
    - xeonmc 5mo ago
      Is that the new "Designed by Apple in California" equivalent of "Made in China" euphemism but for vibecodes?
      - sinpif 5mo ago
        More like "Designed by Apple in California, then copied as a cheap knockoff, never to be touched by a serious designer again".
- trollbridge 5mo ago
  Right. I now have responsibility for rather large codebases where the person who generated it with agentic tools (I'd say it's better than pure 'vibe coding') barely understands how it works. This is okay for unimportant parts of the codebase, but completely unacceptable for a critical piece of infrastructure where it really needs to be well thought out.
apitman 5mo ago
Say what you will about Rust vs Zig as languages, the Zig toolchain is definitely the easier of the two to integrate into another project.
- josephcsible 5mo ago
  This doesn't really have anything to do with the merits of the languages themselves, but rather with the rewrite being entirely vibe coded. If it had been from Rust to Zig instead of from Zig to Rust, I expect the exact same response would have happened.
  - atonse 5mo ago
    Mostly unfounded in my opinion. They took the _exact_ same strategy that go did when they moved from C Go to a Go based compiler. 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.
cabernal 5mo ago
there could be recommended runtimes, but shouldn’t the runtime be user-configurable anyway?
- layer8 5mo ago
  There is no generic “JavaScript runtime” interface that runtimes would implement, therefore support must be tailored to the specific interfaces of existing runtimes.
  - sheept 5mo ago
    At one point we had UMD[0], which effectively provided runtime-agnostic interface, but ES modules were incompatible with that. 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 https://github.com/umdjs/umd
- rob 5mo ago
  --js-runtimes [deno|node|bun|quickjs]
  - sroussey 5mo ago
    There is another by Meta for react native. Forgot the name.
    - nguyenkien 5mo ago
      hermes
draw_down 5mo ago
[dead]
meindnoch 5mo ago
Good news!
muglug 5mo ago
This like if BitTorrent cut off Windows support over objections to Microsoft embrace/extend/extinguish. It’s a slightly incoherent position.
- ivanjermakov 5mo ago
  Not BitTorrent, but I can see a world where e.g. Transmission dropping Windows support because of Microsoft policies.
- happytoexplain 5mo ago
  This seems like a tenuous analogy, to put it lightly.
  - pessimizer 5mo ago
    Care to explain why, or nah?
- IcyWindows 5mo ago
  Which company doesn't do that?
- garbagepatch 5mo ago
  To me it feels more like the old "this site only supports IE6". Instead of checking which JS engine the user has, check for specific api support and fail gracefully.
thot_experiment 5mo ago
I assume they need to do a bunch of WebAPI bullshit to get around Youtube's draconian policies, but maybe one day https://txikijs.org/ https://txikijs.org/ will solve all problems with embedding javascript. I believe, and maybe the strength of my belief will be enough.
- soraminazuki 5mo ago
  Bun was just one of multiple JS runtimes supported, so dropping them doesn't have user-facing consequences. The people posting militant comments here and harassing the maintainer on GitHub are fighting for Anthropic instead of trying to raise any legitimate concerns about yt-dlp.
deleted 5mo ago
[deleted]
deleted 5mo ago
[deleted]
johnfn 5mo ago
This decision seems to based more in politics than engineering. 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.) It seems that you are making this decision because you get a bad feeling when thinking about AI involvement. 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.
- leobuskin 5mo ago
  absolutely, and `its development seems to have taken a turn towards being fully vibe-coded` ungrounded claim confirms the hysteria, I'm afraid
  - cizezsy 5mo ago
    What are you afraid of?
    - nish__ 5mo ago
      A codebase that no human understands.
    - leobuskin 5mo ago
      I'm afraid "we" tackle (agressively) the wrong problem, also making it's tough for the maintainers, who did nothing wrong (I have a lot of sympathy towards Bun's developers, they got a lot of ugly feedback within the last month). I don't think AI-written code is the problem at all. Human signs off the changeset the same way as it happened before. I don't care if Rust rewrite did happen using pipeline/harness and LLMs, if the maintainer takes responsibility, and in projects like Bun it happens "by default", I think.
tln 5mo ago
This is about the rust conversion but that has not been released. > 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.
- atonse 5mo ago
  Yep, it's one thing if there was some project that saw severe regressions in Bun.rs and actually showed data about regressions. 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.
- port11 5mo ago
  They could at least wait a bit, test the new Bun for some weeks/months, have people read big chunks of the codebase. 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).
- tln 5mo ago
  I found this: bun upgrade --canary ...will install a very recent build, with version 1.4.0 I still hope there is a beta release.
adamtaylor_13 5mo ago
We desperately need some new terminology to describe using LLMs to support development work. "Vibe code" has a strict definition but no one really cares. I have a really hard time believing that the Rust port was 100% "vibed" the way the original definition was laid out. 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.
- b40d-48b2-979e 5mo ago
  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. Studies suggest you aren't any faster and may in fact be slower. It's difficult to study such a new tech, but even optimistically, empirical evidence is only showing a ~3% gain in some domains. Writing code is rarely the limiting factor in our work.
  - cdelsolar 5mo ago
    studies suggest nothing. i've released a massive number of features in the last year for several projects that i estimate would have taken me multiple years to put together in a much more mentally exhausting way.
    - b40d-48b2-979e 5mo ago
      Your drive-by comments are unwelcome. You can estimate all you want, but the data is collating, and it isn't within your worldview.
      - shard972 5mo ago
        [dead]
      - lanyard-textile 5mo ago
insanitybit 5mo ago
They foresee potential issues in the future, so they deprecate now? I mean, whatever lol do as you like, but that's an odd choice.
yanis_t 5mo ago
Do we know which model was used for the rewrite?
- geodel 5mo ago
  Gemini, obviously.
- Supermancho 5mo ago
  Claude 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.
  - tomjakubowski 5mo ago
    Claude is a model provider: they have many models. It would be interesting to learn if the models used were Sonnet, Opus, Mythos, some other internal unreleased model, or some mixture of them.
sashank_1509 5mo ago
Has bun really shipped using a million line vibecoded PR. I know they merged it, but merging something in a new dir doesn’t mean anything compared to what code is actually running for customers. It’s crazy if the vibecoded rust version is what’s running for customers and not just some experimental hack.
- BoneShard 5mo ago
  Except it's not vibecoded, it's litteraly the best prompt an LLM can ever get - literal code. If the whole thing ends up as a failure, then it will show that the king is naked.
merb 5mo ago
Google did something similar with golang. Of course it was a tool based rewrite and they did lots of tests but some bugs still emerged. People should stop being mad about a company that delivers a tool that is about shipping software faster. The world does not resolve around high quality software, the world resolves around things that might need a reboot every other day, that was never touched for over 2 years. Things that somebody did once and it worked but most people do not understand it because of the aweful code. Yes of course we still need high quality code in some parts, but most parts of the world is already running on software that is way worse than modern vibe coded things
- dogleash 5mo ago
  tl;dr: give up, stop trying. just approve the juniors' PR without comment so you have more time to proompt.
- registeredcorn 5mo ago
  Do not vote on this comment! I am a server! :)
therepanic 5mo ago
To be honest, I share primeagen's view that LLMs handle translating code from one language to another quite well. As far as I know, they converted the languages file by file. This is what led to such a high volume of `unsafe` code. Although, in any case let's be honest, this is causing, and will continue to cause, various issues. I find it easier to live with this point of view.
- b40d-48b2-979e 5mo ago
  primeagen's view He's a content creator on youtube, a celebrity, not a serious programmer.
  - love2read 5mo ago
    Who cares what you think of someone else’s qualifications? 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?
    - jmull 5mo ago
      If it doesn't matter, why did the previous poster mention them? 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.
  - GuB-42 5mo ago
    He was a software engineer at Netflix before turning to content creation. It is also clear watching his videos that he knows his thing. As an experienced programmer myself, I find his commentary to be way too relatable to be just bluff. 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.
    - deleted 5mo ago
xmodem 5mo ago
I see a lot of commentators in this thread who are aggressively critical of volunteer maintainers for making a decision about how to maximize the value of the free labor they donate to the world. And yet none have offered to volunteer their time to maintain a downstream fork or otherwise rectify the perceived problem. Strange.
- Jblx2 5mo ago
  Which "volunteers" are you referring to? Bun? yt-dlp?
  - tredre3 5mo ago
    yt-dlp, clearly. Bun has no volunteers (as of the rust rewrite at least, it's all highly paid SWEs and GPUs.)
the__alchemist 5mo ago
Bun alert!
getcrunk 5mo ago
It’s not like they are discriminating on someone’s race or religion. If they don’t want a major vibe coded surface, do they even have to defend that? It’s part their “artistic” license as developers. Or did we forget software inherently is opinionated
- karel-3d 5mo ago
  exactly... and it's not like it's hard to fork and just raise the minimum version. It will probably be just one number somewhere (I haven't actually looked.) if it works, it will keep working. they just don't want to support and maintain it and solve issues.
- dbalatero 5mo ago
  Given some posters on the GitHub issue, I get the sense some people feel their religion is being violated.
  - BoorishBears 5mo ago
    You don't even have to leave this site: when the original Bun rewrite posts were made, an incredible number of comments were focused, not on Bun, but on Jarred, who I'm assured is a complete rockstar and would never harm Bun. 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.
- deleted 5mo ago
  [deleted]
- gkfasdfasdf 5mo ago
  Yes, it’s actually similar to discriminating based on race or religion, in the sense that it’s an arbitrary, meaningless criterion to discriminate on. If the Rust Bun port is better in every measurable way — passes all tests, has the same performance or better, and fixes existing bugs — then who cares what language it’s written in or how it was implemented? The point is that it’s higher quality. If you don’t trust the Bun team when they release a Rust version and give it their stamp of approval, why did you trust them when they released the Zig version two weeks ago? It makes no logical sense, and it makes the yt-dlp devs look foolish.
sharts 5mo ago
Why even use bun or anything else if everything is getting slapped together with LLMs? May as well use them to build native
potsandpans 5mo ago
[flagged]
anthk 5mo ago
yt-dlp launches propietary software: https://jxself.org/shifting-the-trap.shtml https://jxself.org/shifting-the-trap.shtml You can run a BF and, soon, subleq.
5G_activated 5mo ago
Who was actually using yt-dlp with bun? The primary use is to solve JavaScript challenges sent by YouTube, which uses Deno by default. 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.
- hurfdurf 5mo ago
  https://github.com/yt-dlp/yt-dlp/wiki/EJS https://github.com/yt-dlp/yt-dlp/wiki/EJS Read the "Notes" sections for details.
gkfasdfasdf 5mo ago
Idiotic. Why do they care what language it's written in? If it works it works.
pizlonator 5mo ago
I can’t help but read the logic as not being too far off from: “libfoo switched to being developed using emacs instead of vim so we can’t trust it anymore” 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
- jmull 5mo ago
  Most people probably think the text editor used would have no meaningful effect on the code written. 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.
  - padjo 5mo ago
    > Maybe vibe bun is just as good or better than old bun, but how would we know at this point? By considering objective facts like efficiency, performance, error rates, security vulns etc. like we always do?
    - happytoexplain 5mo ago
zipy124 5mo ago
So many people in the comments here are making assertions about the quality of the rust re-write but the point largely remains the same. There is no way you've read all million LOC in the time and reviewed to make sure it really is transpiled. It's not a criticism of the method, but the time and review process.
mawadev 5mo ago
I like this clear divide of: 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?
ungovernableCat 5mo ago
Why are some people so pressed about this decision? From my point of view, if you're truly a vibe code enthusiast wouldn't you be able to just vibe code your own better yt-dlp (or fork the existing one and do whatever you need to do with it)?
- terminalbraid 5mo ago
  What's more is yt-dlp already has plugin support for 3rd party interpreters. They're just saying they don't want to deal with supporting bun themselves and the infrastructure for anyone else do use whatever they want is already there. 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.
- bigstrat2003 5mo ago
  Because for a lot of AI fans (not all, I know), it's like a religion. They aren't content to live and let live and let history show whose approach to building software is better, they insist that everyone has to agree with them. I have that situation at my job and it drives me insane that honest technical disagreement isn't allowed when it comes to AI.
- 48terry 5mo ago
  Indeed. I've heard a lot of words about how trivially easy vibe coding makes building software, and how just about anyone can build something in no time at all anymore. Even stuff about how people will vibe code one-off private software for everything at all times, and such. 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?
- user34283 5mo ago
  I speculate that I could indeed "vibe code" a better JS build integration because what they have does not make sense at a first look. 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.
kelipso 5mo ago
I already came across some bs bug in claude today due to this stupid rust bun thing, so I absolutely 100% support this decision.
ozten 5mo ago
There is an implicit assumption that the other supported runtimes aren't being vibe-coded. Looking at commit metadata tells a different story.
jpambrun 5mo ago
This title is wrong. It makes it sounds like Anthropic dropped support for and deprecated Bun.
toyetic 5mo ago
I think this is fine with the caveat that if it does turn out the rust rewrite works just as well as before they should start supporting it again.
ChoGGi 5mo ago
Your bank has vibe coded their entire codebase into rust in a week. The test suites passed so it's all good.
- ronsor 5mo ago
  Can't be worse than COBOL
nimchimpsky 5mo ago
[dead]
vcryan 5mo ago
I don't think it matters how code is produced -- it matters what it achieves. Is there evidence that there is something wrong with recent Bun releases?
- davidee 5mo ago
  I think one of the big disconnects here are the competing views about "what it achieves" means on a fundamental level. 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."
LelouBil 5mo ago
I don't know how to feel about the Bun rewrite. 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.
- cybercatgurrl 5mo ago
  congratulations, in a sea of politics and ideology you have a sensible take. i think a wait and see approach is reasonable here
elzbardico 5mo ago
Most developers can’t see AI slop because their level of competence is actually below what an AI can produce. Technical debt was a reality before vibe coding. Someone was writing all that trash by hand.
- szmarczak 5mo ago
  I got banned from yt-dlp for stating that Deno is vibe coded and that AIs are responsible for 54% commits since Feb 01. Also see https://news.ycombinator.com/item?id=48241873 https://news.ycombinator.com/item?id=48241873 > 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 https://news.ycombinator.com/item?id=45034496
gkfasdfasdf 5mo ago
Someone should fork yt-dlp and rewrite it in Rust...and have it use bun exclusively
dmitrygr 5mo ago
Do you also install pre-alpha revisions of operating systems on your main work pc? No, you do not. Why? Because of the "foreseeable compatibility and security issues". "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.
mmorrell0 5mo ago
zig is barely adopted relative to rust. totally reasonable to move to Rust, which isn't as risky of a bet. and you're not the guy having to find their zig memory leaks.
boramalper 5mo ago
I think this HN submission provides little value and a lot more headache to the maintainers of FOSS project (you can already see a lot of brigading in the GitHub comments). IMHO HN shouldn’t allow submissions like this.
indianwashlet 5mo ago
When Patty?
warpech 5mo ago
I see Bun’s Rust rewrite (esp the style how it was done) as a form of massive internet trolling for PR reasons. By making a bigger fuss about it, we’re feeding the troll
- wiseowise 5mo ago
  They are. Just wait until Jarred releases his blogpost and Anthropic marketing machine kicks in.
  - egorfine 5mo ago
    He promised the blog post just like he (almost) promised to not merge the slop branch
Aeolun 5mo ago
This is such a knee jerk reaction.
- account42 5mo ago
  Yes, a slop rewrite into a competing language because you can't get your slop changes to the original language merged is a knee jerk reaction.
qwm 5mo ago
Being conservative with technology choices and only using Node LTS has paid dividends lol
feverzsj 5mo ago
Bun is pretty much doomed. No one except anthropic will use it.
throwaway27448 5mo ago
Can anyone explain why bun was used to begin with?
- user34283 5mo ago
  Or better yet, can someone explain why they build JS from python scripts with manual support for each package manager and a lockfile for each? Obviously the JS build should happen outside of Python and use one package manager instead of attempting to support them all.
- hurfdurf 5mo ago
  Processing the YouTube-scripts to get to the video addresses. It was never the default option for that purpose, which is deno.
  - throwaway27448 5mo ago
    but isn't this just javascript?? Where is the standard interpreter?
wiseowise 5mo ago
Lol! Fuck around and find out. There were dozens, “well, if you don’t like it – don’t use it”, “they don’t owe you anything”, “it’s their project”, etc., etc. Nice to see the consequences.
- soraminazuki 5mo ago
  And now those people are berating yt-dlp maintainers. Turns out their real demand was blind loyalty, not acceptance of any fair principle.
alloysmila 5mo ago
Most people who use/used bun have never read bun's code. Then why does it matter who/what wrote the code? 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.
- nicce 5mo ago
  > Then why does it matter who/what wrote the code? You trust for someones expertice.
  - tcfhgj 5mo ago
    like the one of Jarred-Sumner, whos responsible for the rewrite?
    - carlos-menezes 5mo ago
      Claude is responsible for the rewrite.
rldjbpin 5mo ago
bun was never the recommended js runtime when they first announced its need for yt support [1]. in fact they recommended deno over all, even regular node. 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 https://news.ycombinator.com/item?id=45898407
- account42 5mo ago
  > these runtimes are only used to bypass certain blockers 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.
danborn26 5mo ago
Maintaining compatibility with multiple runtimes adds too much friction for a core tool like yt-dlp. Dropping Bun seems like the right call to keep development focused.
insane_dreamer 5mo ago
This makes a lot of sense. 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.
mik09 5mo ago
[dead]
BOplaid 5mo ago
Fuck AI
harrisaydin77 5mo ago
[flagged]
account42 5mo ago
Glad to sea that yt-dp continues to be run by competent and reasonable people. Can't imagine what my web experience would be like without it since it has become almost as essential as an ad blocker due to the failure of web browsers to implement adequate native video streaming support and the resulting mess of shitty javascript-based mess of page-specific video players.

594 points by tamnd 5mo ago

winrid 5mo ago

What does this use bun for? I thought this was a python project?

aarroyoc 5mo ago
They need a JavaScript runtime to execute some challenges that certain pages present (like YouTube)
- tym0 5mo ago
  They used to have their own "youtube script interpreter" that was kind of fascinating. But yeah as you said they switched to proper js runtimes recently.
- user34283 5mo ago
  What they don't need is hardcoding support for five JS package managers in their python files. 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.
deleted 5mo ago
[deleted]

hootz 5mo ago

Oh well, I really like using Bun and I get kinda sad about the turn they are taking after the Anthropic acquisition. I really want a good Node with batteries included, but I don't want it vibe coded.

LoganDark 5mo ago
I think it's hilarious how hopeful people were at the acquisition that Bun would be able to continue on mostly as it had been but then that all got completely thrown away and trashed. (Hilarious in the way that's terribly sad, of course.)
- abnercoimbre 5mo ago
  It usually takes years for someone's values to be thrown out the window! How long was this one?
  - em-bee 5mo ago
    changing your employer tends to accelerate that if the new employer has different values.
  - htrp 5mo ago
    "It is difficult to get a man to understand something, when his salary depends upon his not understanding it"
  - wiseowise 5mo ago
    Give man a Claude subscription and he can work for a day, let Anthropic buy the man and he doesn’t need to work a day in his life anymore.
  - LtWorf 5mo ago
    I don't think the man had any values to begin with. https://news.ycombinator.com/item?id=48243990 https://news.ycombinator.com/item?id=48243990
- vosper 5mo ago
  How has it been trashed? Does the Bun software not work anymore?
  - happytoexplain 5mo ago

antonvs 5mo ago

Reason #2 is purely speculative. It’s disappointing to see technical decisions being made on such grounds.

malfist 5mo ago
What part of the recent history of vibe coded projects has not resulted in low quality, bug laden code? Dismissing this a "purely speculative" is just like dismissing the weather report as "purely speculative" when deciding what to wear in the morning.
- cortesoft 5mo ago
  There is quite the selection bias going on here... you aren't hearing about the successful projects.
  - dawnerd 5mo ago
    Care to list them then? I have yet to see a successful vibe coded project
  - Dylan16807 5mo ago
    People love to brag about using AI to get work done. If anything I expect the successful projects to be overrepresented.
  - add-sub-mul-div 5mo ago
    With all the unprecedented investment and desperation behind it, these hypothetical LLM successes would be getting shoved down our throats.
  - asadotzler 5mo ago
    We're only hearing about the failed projects? I call BS. Precisely the oppositee is both true and obvious if you're not a shill. The "successful" ones are being trotted out all the time trying to convince us how great it is. If anything, we're not hearing about all the catastrophic and costly failures while the cherry-picked almost successes are all over this platform and others.

fastball 5mo ago

The "to vibe code or not to vibe code" holy war is now in full swing.

nh23423fefe 5mo ago
war implies "not vibe code" could win. that's impossible
- nish__ 5mo ago
  There's literally nothing that LLMs can build that humans cannot. The only factor influencing people to use AI is time. They trade off a small amount of quality for a large amount of time savings. The tortoise and the hare parable comes to mind.
  - nh23423fefe 5mo ago
    so why arent you using punch cards? are you pretending time is not the most important resource?

mvdtnz 5mo ago

Wow, bun support was just added in November last year (I think). That's a lot of work to throw away, but you can't argue with their reasoning.

em-bee 5mo ago
bun is still supported for specific versions so nothing is being thrown away. in any case the actual code is the same, since it's all javascript. it's more a matter of the wrapper code that calls the different runtimes and maybe some edgecases where the runtimes are not 100% compatible.

satvikpendem 5mo ago

As long as Deno support is still there I'm not sure why you need anything else. It's not vibe coded slop for one.

blain 5mo ago
Well, apparently Deno is also a slop now: https://github.com/yt-dlp/yt-dlp/issues/16766#issuecomment-4521794212 https://github.com/yt-dlp/yt-dlp/issues/16766#issuecomment-4...
- sheept 5mo ago
  Deno's LLM contributions have been smaller in scope, so they're more likely to be reviewed by a human, and the codebase remains understood by its contributors. Can the same be said of Bun, which switched to an entirely different language in a single, million-line PR?[0] [0]: https://github.com/oven-sh/bun/pull/30412 https://github.com/oven-sh/bun/pull/30412
  - szmarczak 5mo ago
    Since when small vibe coded slop became the norm? Because there exists bigger vibe coded slop, it's no justification to have a smaller vibe coded slop.
    - dsherret 5mo ago
      One shotting slop is very different from iterating back and forth with an AI. Also, most of the AI work that's being done has been getting node compatibility tests passing with the help of comparing that to the Node.js code, which is something an LLM is very good at.
      - szmarczak 5mo ago
        > One shotting slop is very different from iterating back and forth with an AI. 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.

umvi 5mo ago

Honestly I hope agentic AI ushers in a new age of minimal-SBOM software. I myself am moving all of my projects towards nearly 100% vanilla where possible. For example, golang. Why use [insert web framework] when you can just use vanilla for 99% of web apps? There's something really satisfying about a go binary with minimal dependencies running in a busybox docker container.

echelon 5mo ago
Frameworks and ORMs were the pre-agentic AI "iron man suit". I'm quite liking how good Claude Code Opus is at Rust + sqlx (raw SQL with type safety) + actix-web.
josephcsible 5mo ago
Wouldn't that be worse? With dependencies, it's at least possible that someone else has audited the code, but with a vibe-coded from scratch app, it's definitely totally unreviewed.
- Kiro 5mo ago
  You only add what you need instead of importing some bloated dependency. That means you can actually review the code yourself.
  - wizzwizz4 5mo ago
    Relevant reading: https://nesbitt.io/2026/02/16/changelog.html https://nesbitt.io/2026/02/16/changelog.html > 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.
    - olzd 5mo ago
      Are you aware this is satire?

maxloh 5mo ago

I understand their decision. How could the maintainers understand their codebase if most of it was not directly written by them? 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 https://github.com/oven-sh/bun/pull/30412

thatxliner 5mo ago
it's funny how the readme still says "written in Zig"
- prmoustache 5mo ago
  If Claude isn't even able to correct the readme, I don't know how one can have hope it produces decent results.
- sinpif 5mo ago
  Maybe it should say "designed in Zig" because most of the work & thinking was done using that language. The rewrite has no such history.
  - xeonmc 5mo ago
    Is that the new "Designed by Apple in California" equivalent of "Made in China" euphemism but for vibecodes?
    - sinpif 5mo ago
      More like "Designed by Apple in California, then copied as a cheap knockoff, never to be touched by a serious designer again".
trollbridge 5mo ago
Right. I now have responsibility for rather large codebases where the person who generated it with agentic tools (I'd say it's better than pure 'vibe coding') barely understands how it works. This is okay for unimportant parts of the codebase, but completely unacceptable for a critical piece of infrastructure where it really needs to be well thought out.

apitman 5mo ago

Say what you will about Rust vs Zig as languages, the Zig toolchain is definitely the easier of the two to integrate into another project.

josephcsible 5mo ago
This doesn't really have anything to do with the merits of the languages themselves, but rather with the rewrite being entirely vibe coded. If it had been from Rust to Zig instead of from Zig to Rust, I expect the exact same response would have happened.
- atonse 5mo ago
  Mostly unfounded in my opinion. They took the _exact_ same strategy that go did when they moved from C Go to a Go based compiler. 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.

cabernal 5mo ago

there could be recommended runtimes, but shouldn’t the runtime be user-configurable anyway?

layer8 5mo ago
There is no generic “JavaScript runtime” interface that runtimes would implement, therefore support must be tailored to the specific interfaces of existing runtimes.
- sheept 5mo ago
  At one point we had UMD[0], which effectively provided runtime-agnostic interface, but ES modules were incompatible with that. 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 https://github.com/umdjs/umd
rob 5mo ago
--js-runtimes [deno|node|bun|quickjs]
- sroussey 5mo ago
  There is another by Meta for react native. Forgot the name.
  - nguyenkien 5mo ago
    hermes

draw_down 5mo ago

[dead]

meindnoch 5mo ago

Good news!

muglug 5mo ago

This like if BitTorrent cut off Windows support over objections to Microsoft embrace/extend/extinguish. It’s a slightly incoherent position.

ivanjermakov 5mo ago
Not BitTorrent, but I can see a world where e.g. Transmission dropping Windows support because of Microsoft policies.
happytoexplain 5mo ago
This seems like a tenuous analogy, to put it lightly.
- pessimizer 5mo ago
  Care to explain why, or nah?
IcyWindows 5mo ago
Which company doesn't do that?
garbagepatch 5mo ago
To me it feels more like the old "this site only supports IE6". Instead of checking which JS engine the user has, check for specific api support and fail gracefully.

thot_experiment 5mo ago

I assume they need to do a bunch of WebAPI bullshit to get around Youtube's draconian policies, but maybe one day https://txikijs.org/ https://txikijs.org/ will solve all problems with embedding javascript. I believe, and maybe the strength of my belief will be enough.

soraminazuki 5mo ago
Bun was just one of multiple JS runtimes supported, so dropping them doesn't have user-facing consequences. The people posting militant comments here and harassing the maintainer on GitHub are fighting for Anthropic instead of trying to raise any legitimate concerns about yt-dlp.

deleted 5mo ago

[deleted]

deleted 5mo ago

[deleted]

johnfn 5mo ago

This decision seems to based more in politics than engineering. 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.) It seems that you are making this decision because you get a bad feeling when thinking about AI involvement. 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.

leobuskin 5mo ago
absolutely, and `its development seems to have taken a turn towards being fully vibe-coded` ungrounded claim confirms the hysteria, I'm afraid
- cizezsy 5mo ago
  What are you afraid of?
  - nish__ 5mo ago
    A codebase that no human understands.
  - leobuskin 5mo ago
    I'm afraid "we" tackle (agressively) the wrong problem, also making it's tough for the maintainers, who did nothing wrong (I have a lot of sympathy towards Bun's developers, they got a lot of ugly feedback within the last month). I don't think AI-written code is the problem at all. Human signs off the changeset the same way as it happened before. I don't care if Rust rewrite did happen using pipeline/harness and LLMs, if the maintainer takes responsibility, and in projects like Bun it happens "by default", I think.

tln 5mo ago

This is about the rust conversion but that has not been released. > 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.

atonse 5mo ago
Yep, it's one thing if there was some project that saw severe regressions in Bun.rs and actually showed data about regressions. 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.
port11 5mo ago
They could at least wait a bit, test the new Bun for some weeks/months, have people read big chunks of the codebase. 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).
tln 5mo ago
I found this: bun upgrade --canary ...will install a very recent build, with version 1.4.0 I still hope there is a beta release.

adamtaylor_13 5mo ago

We desperately need some new terminology to describe using LLMs to support development work. "Vibe code" has a strict definition but no one really cares. I have a really hard time believing that the Rust port was 100% "vibed" the way the original definition was laid out. 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.

b40d-48b2-979e 5mo ago
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. Studies suggest you aren't any faster and may in fact be slower. It's difficult to study such a new tech, but even optimistically, empirical evidence is only showing a ~3% gain in some domains. Writing code is rarely the limiting factor in our work.
- cdelsolar 5mo ago
  studies suggest nothing. i've released a massive number of features in the last year for several projects that i estimate would have taken me multiple years to put together in a much more mentally exhausting way.
  - b40d-48b2-979e 5mo ago
    Your drive-by comments are unwelcome. You can estimate all you want, but the data is collating, and it isn't within your worldview.
    - shard972 5mo ago
      [dead]
    - lanyard-textile 5mo ago

insanitybit 5mo ago

They foresee potential issues in the future, so they deprecate now? I mean, whatever lol do as you like, but that's an odd choice.

yanis_t 5mo ago

Do we know which model was used for the rewrite?

geodel 5mo ago
Gemini, obviously.
Supermancho 5mo ago
Claude 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.
- tomjakubowski 5mo ago
  Claude is a model provider: they have many models. It would be interesting to learn if the models used were Sonnet, Opus, Mythos, some other internal unreleased model, or some mixture of them.

sashank_1509 5mo ago

Has bun really shipped using a million line vibecoded PR. I know they merged it, but merging something in a new dir doesn’t mean anything compared to what code is actually running for customers. It’s crazy if the vibecoded rust version is what’s running for customers and not just some experimental hack.

BoneShard 5mo ago
Except it's not vibecoded, it's litteraly the best prompt an LLM can ever get - literal code. If the whole thing ends up as a failure, then it will show that the king is naked.

merb 5mo ago

Google did something similar with golang. Of course it was a tool based rewrite and they did lots of tests but some bugs still emerged. People should stop being mad about a company that delivers a tool that is about shipping software faster. The world does not resolve around high quality software, the world resolves around things that might need a reboot every other day, that was never touched for over 2 years. Things that somebody did once and it worked but most people do not understand it because of the aweful code. Yes of course we still need high quality code in some parts, but most parts of the world is already running on software that is way worse than modern vibe coded things

dogleash 5mo ago
tl;dr: give up, stop trying. just approve the juniors' PR without comment so you have more time to proompt.
registeredcorn 5mo ago
Do not vote on this comment! I am a server! :)

therepanic 5mo ago

To be honest, I share primeagen's view that LLMs handle translating code from one language to another quite well. As far as I know, they converted the languages file by file. This is what led to such a high volume of `unsafe` code. Although, in any case let's be honest, this is causing, and will continue to cause, various issues. I find it easier to live with this point of view.

b40d-48b2-979e 5mo ago
primeagen's view He's a content creator on youtube, a celebrity, not a serious programmer.
- love2read 5mo ago
  Who cares what you think of someone else’s qualifications? 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?
  - jmull 5mo ago
    If it doesn't matter, why did the previous poster mention them? 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.
- GuB-42 5mo ago
  He was a software engineer at Netflix before turning to content creation. It is also clear watching his videos that he knows his thing. As an experienced programmer myself, I find his commentary to be way too relatable to be just bluff. 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.
  - deleted 5mo ago

xmodem 5mo ago

I see a lot of commentators in this thread who are aggressively critical of volunteer maintainers for making a decision about how to maximize the value of the free labor they donate to the world. And yet none have offered to volunteer their time to maintain a downstream fork or otherwise rectify the perceived problem. Strange.

Jblx2 5mo ago
Which "volunteers" are you referring to? Bun? yt-dlp?
- tredre3 5mo ago
  yt-dlp, clearly. Bun has no volunteers (as of the rust rewrite at least, it's all highly paid SWEs and GPUs.)

the__alchemist 5mo ago

Bun alert!

getcrunk 5mo ago

It’s not like they are discriminating on someone’s race or religion. If they don’t want a major vibe coded surface, do they even have to defend that? It’s part their “artistic” license as developers. Or did we forget software inherently is opinionated

karel-3d 5mo ago
exactly... and it's not like it's hard to fork and just raise the minimum version. It will probably be just one number somewhere (I haven't actually looked.) if it works, it will keep working. they just don't want to support and maintain it and solve issues.
dbalatero 5mo ago
Given some posters on the GitHub issue, I get the sense some people feel their religion is being violated.
- BoorishBears 5mo ago
  You don't even have to leave this site: when the original Bun rewrite posts were made, an incredible number of comments were focused, not on Bun, but on Jarred, who I'm assured is a complete rockstar and would never harm Bun. 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.
deleted 5mo ago
[deleted]
gkfasdfasdf 5mo ago
Yes, it’s actually similar to discriminating based on race or religion, in the sense that it’s an arbitrary, meaningless criterion to discriminate on. If the Rust Bun port is better in every measurable way — passes all tests, has the same performance or better, and fixes existing bugs — then who cares what language it’s written in or how it was implemented? The point is that it’s higher quality. If you don’t trust the Bun team when they release a Rust version and give it their stamp of approval, why did you trust them when they released the Zig version two weeks ago? It makes no logical sense, and it makes the yt-dlp devs look foolish.

sharts 5mo ago

Why even use bun or anything else if everything is getting slapped together with LLMs? May as well use them to build native

potsandpans 5mo ago

[flagged]

anthk 5mo ago

yt-dlp launches propietary software: https://jxself.org/shifting-the-trap.shtml https://jxself.org/shifting-the-trap.shtml You can run a BF and, soon, subleq.

5G_activated 5mo ago

Who was actually using yt-dlp with bun? The primary use is to solve JavaScript challenges sent by YouTube, which uses Deno by default. 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.

hurfdurf 5mo ago
https://github.com/yt-dlp/yt-dlp/wiki/EJS https://github.com/yt-dlp/yt-dlp/wiki/EJS Read the "Notes" sections for details.

gkfasdfasdf 5mo ago

Idiotic. Why do they care what language it's written in? If it works it works.

pizlonator 5mo ago

I can’t help but read the logic as not being too far off from: “libfoo switched to being developed using emacs instead of vim so we can’t trust it anymore” 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

jmull 5mo ago
Most people probably think the text editor used would have no meaningful effect on the code written. 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.
- padjo 5mo ago
  > Maybe vibe bun is just as good or better than old bun, but how would we know at this point? By considering objective facts like efficiency, performance, error rates, security vulns etc. like we always do?
  - happytoexplain 5mo ago

zipy124 5mo ago

So many people in the comments here are making assertions about the quality of the rust re-write but the point largely remains the same. There is no way you've read all million LOC in the time and reviewed to make sure it really is transpiled. It's not a criticism of the method, but the time and review process.

mawadev 5mo ago

I like this clear divide of: 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?

ungovernableCat 5mo ago

Why are some people so pressed about this decision? From my point of view, if you're truly a vibe code enthusiast wouldn't you be able to just vibe code your own better yt-dlp (or fork the existing one and do whatever you need to do with it)?

terminalbraid 5mo ago
What's more is yt-dlp already has plugin support for 3rd party interpreters. They're just saying they don't want to deal with supporting bun themselves and the infrastructure for anyone else do use whatever they want is already there. 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.
bigstrat2003 5mo ago
Because for a lot of AI fans (not all, I know), it's like a religion. They aren't content to live and let live and let history show whose approach to building software is better, they insist that everyone has to agree with them. I have that situation at my job and it drives me insane that honest technical disagreement isn't allowed when it comes to AI.
48terry 5mo ago
Indeed. I've heard a lot of words about how trivially easy vibe coding makes building software, and how just about anyone can build something in no time at all anymore. Even stuff about how people will vibe code one-off private software for everything at all times, and such. 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?
user34283 5mo ago
I speculate that I could indeed "vibe code" a better JS build integration because what they have does not make sense at a first look. 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.

kelipso 5mo ago

I already came across some bs bug in claude today due to this stupid rust bun thing, so I absolutely 100% support this decision.

ozten 5mo ago

There is an implicit assumption that the other supported runtimes aren't being vibe-coded. Looking at commit metadata tells a different story.

jpambrun 5mo ago

This title is wrong. It makes it sounds like Anthropic dropped support for and deprecated Bun.

toyetic 5mo ago

I think this is fine with the caveat that if it does turn out the rust rewrite works just as well as before they should start supporting it again.

ChoGGi 5mo ago

Your bank has vibe coded their entire codebase into rust in a week. The test suites passed so it's all good.

ronsor 5mo ago
Can't be worse than COBOL

nimchimpsky 5mo ago

[dead]

vcryan 5mo ago

I don't think it matters how code is produced -- it matters what it achieves. Is there evidence that there is something wrong with recent Bun releases?

davidee 5mo ago
I think one of the big disconnects here are the competing views about "what it achieves" means on a fundamental level. 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."

LelouBil 5mo ago

I don't know how to feel about the Bun rewrite. 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.

cybercatgurrl 5mo ago
congratulations, in a sea of politics and ideology you have a sensible take. i think a wait and see approach is reasonable here

elzbardico 5mo ago

Most developers can’t see AI slop because their level of competence is actually below what an AI can produce. Technical debt was a reality before vibe coding. Someone was writing all that trash by hand.

szmarczak 5mo ago
I got banned from yt-dlp for stating that Deno is vibe coded and that AIs are responsible for 54% commits since Feb 01. Also see https://news.ycombinator.com/item?id=48241873 https://news.ycombinator.com/item?id=48241873 > 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 https://news.ycombinator.com/item?id=45034496

gkfasdfasdf 5mo ago

Someone should fork yt-dlp and rewrite it in Rust...and have it use bun exclusively

dmitrygr 5mo ago

Do you also install pre-alpha revisions of operating systems on your main work pc? No, you do not. Why? Because of the "foreseeable compatibility and security issues". "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.

mmorrell0 5mo ago

zig is barely adopted relative to rust. totally reasonable to move to Rust, which isn't as risky of a bet. and you're not the guy having to find their zig memory leaks.

boramalper 5mo ago

I think this HN submission provides little value and a lot more headache to the maintainers of FOSS project (you can already see a lot of brigading in the GitHub comments). IMHO HN shouldn’t allow submissions like this.

indianwashlet 5mo ago

When Patty?

warpech 5mo ago

I see Bun’s Rust rewrite (esp the style how it was done) as a form of massive internet trolling for PR reasons. By making a bigger fuss about it, we’re feeding the troll

wiseowise 5mo ago
They are. Just wait until Jarred releases his blogpost and Anthropic marketing machine kicks in.
- egorfine 5mo ago
  He promised the blog post just like he (almost) promised to not merge the slop branch

Aeolun 5mo ago

This is such a knee jerk reaction.

account42 5mo ago
Yes, a slop rewrite into a competing language because you can't get your slop changes to the original language merged is a knee jerk reaction.

qwm 5mo ago

Being conservative with technology choices and only using Node LTS has paid dividends lol

feverzsj 5mo ago

Bun is pretty much doomed. No one except anthropic will use it.

throwaway27448 5mo ago

Can anyone explain why bun was used to begin with?

user34283 5mo ago
Or better yet, can someone explain why they build JS from python scripts with manual support for each package manager and a lockfile for each? Obviously the JS build should happen outside of Python and use one package manager instead of attempting to support them all.
hurfdurf 5mo ago
Processing the YouTube-scripts to get to the video addresses. It was never the default option for that purpose, which is deno.
- throwaway27448 5mo ago
  but isn't this just javascript?? Where is the standard interpreter?

wiseowise 5mo ago

Lol! Fuck around and find out. There were dozens, “well, if you don’t like it – don’t use it”, “they don’t owe you anything”, “it’s their project”, etc., etc. Nice to see the consequences.

soraminazuki 5mo ago
And now those people are berating yt-dlp maintainers. Turns out their real demand was blind loyalty, not acceptance of any fair principle.

alloysmila 5mo ago

Most people who use/used bun have never read bun's code. Then why does it matter who/what wrote the code? 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.

nicce 5mo ago
> Then why does it matter who/what wrote the code? You trust for someones expertice.
- tcfhgj 5mo ago
  like the one of Jarred-Sumner, whos responsible for the rewrite?
  - carlos-menezes 5mo ago
    Claude is responsible for the rewrite.

rldjbpin 5mo ago

bun was never the recommended js runtime when they first announced its need for yt support [1]. in fact they recommended deno over all, even regular node. 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 https://news.ycombinator.com/item?id=45898407

account42 5mo ago
> these runtimes are only used to bypass certain blockers 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.

danborn26 5mo ago

Maintaining compatibility with multiple runtimes adds too much friction for a core tool like yt-dlp. Dropping Bun seems like the right call to keep development focused.

insane_dreamer 5mo ago

This makes a lot of sense. 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.

mik09 5mo ago

[dead]

BOplaid 5mo ago

Fuck AI

harrisaydin77 5mo ago

[flagged]

account42 5mo ago

Glad to sea that yt-dp continues to be run by competent and reasonable people. Can't imagine what my web experience would be like without it since it has become almost as essential as an ad blocker due to the failure of web browsers to implement adequate native video streaming support and the resulting mess of shitty javascript-based mess of page-specific video players.