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.
If you wait for more segfaults, OOMs and other issues, than you have failed to avoid the problem. In my opinion this direction is correct and history will show who's right.
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.
Have there been any significant issues caused by the vibecoded translation?
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.
IMO the source of the new code is less important than the sheer volume of it. Bun does not need to be entirely rewritten; certainly not over a period of a week, possibly not even over a period of a year. Stability is hard-fought and battle-tested. Everyone has a plan until they get punched in the face; and every repository has passing tests until it runs production code.
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.)
They literally threw out every line of code that existed before and rewrote it in a completely different language, seemingly on a whim. That's how it was trashed, in the very literal sense that all of the existing project was tossed in the trash in favor of a completely brand new code base. That's a big deal even if you ignore the coding agent aspects.
Unless specific issues have been identified that were introduced by it being "vibe coded", isn't a reaction to reject it outright without actually checking the ground truth just exhibiting the behavior you are criticizing?
It's just a trust issue. Have you seen the absolute state of the Claude Code CLI development? I don't want that to suddenly happen to Bun after I've already used it for production stuff.
The ground truth is that the new maintainers can’t possibly have a good understanding of the many millions of lines of vibe-translated code. Even assuming that the code happens to work okay in its current state, the lack of understanding means a high risk that its continuing maintenance won’t result in a satisfactory level of reliability.
I don't see any hypocrisy in the comment you are criticizing. The behavior they are criticizing appears to be vibe coding. How is rejecting something for being vibe coding "exhibiting the behavior" of vibe coding?
In a million line code base, its infeasible to check ground truth. That's the point.
Anthropic took a mature and trusted project, threw it in a blender, and served the sloppy mess back out to the public.
Who would want their project to be held responsible for the million lines of code that even its vendor can no longer vouch for.
Maybe the new code will prove itself to be mature and worthy again someday, but that's going to take a long time and a lot of eyes. It's now completely reasomable to just move on from the project until that happens.
I'm not sure what "exhibiting the behavior you are criticizing" would even mean here.
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.
So it was possible to write ~2 million lines of (mostly) zig, but it's not possible to review ~1 million lines of rust, even though the same test suite included in those 2 million lines of zig can still be used? I'm not convinced the rewrite is a good idea and will work out, but I'm equally unconvinced by your argument.
I don’t think changing from zig to rust suddenly means that don’t know what a certain file contains or how it works or how it relates to other files.
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.
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.
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.
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.
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.
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/ will solve all problems with embedding javascript. I believe, and maybe the strength of my belief will be enough.
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.
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.
There is no generic “JavaScript runtime” interface that runtimes would implement, therefore support must be tailored to the specific interfaces of existing runtimes.
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]
All dependency management is speculative. You've got to hedge your bets that the dependency is reliable and fit for purpose. It is reasonable to view Bun's recent choices as increasing the risk associated with depending on it.
Very much agree. Until the vibe-coded version has been fully audited and profiled to perform, within reasonable tolerances, as well as the original code base, it feels like a bad idea to support it downstream or use it in production.
Even if it performs reasonably, it may still be unmaintainable, meaning that any future changes are likely to introduce bugs and instabilities. At the present state of AI coding it’s completely understandable not wanting to depend on code that the maintainers have no good understanding of. The code auditors would have to become the maintainers.
I'd hope that the bun team is going to put into the work to ensure the LLM translated version is up to snuff before cutting a release from it though... it doesn't seem fair to assume that that isn't going to happen.
It's a common fallacy among tech folks to believe that every decision can be made from 100% deterministic grounds ("X decision will result in Y percent change"). In reality, successful decision-making often involves speculation. The speculation in question is within the bounds of reason. You may disagree, but the fact that it is speculative isn't the problem.
And not acting while doing the whole analysis to reach close to 100% deterministic grounds mis a decision in itself! It’s perfectly reasonable to drop support for bun, and potentially revisit later on when more details come up
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.
Low quality, bug laden code has existed long before LLMs and it'll continue to exist long after. Their rationale about avoiding future headaches could literally apply to any open source project they have a dependency on.
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.
1. You cannot make bug-free software with tests alone. Also, code that compiles and executes successfully is only one goal, memory efficiency and performance are other desirable traits. Claude Code can consume GBs of memory to display 1kb of text because it is slopware.
2. Even if somehow you did make bug-free software with tests alone, even if the Rust port is perfect 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 a human, 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.
Tests are one quality control. It's horrifying that some of us treat them as the only thing that matters. There's review, obviously, and of course we haven't even had to think about "written by a thinking mind" as a beneficial quality until now.
Vibe coding from scratch is far from translating an existing app to another language.
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.
It's a reasonable decision to not take a dependency which doesn't meet your own engineering standards. People in the JS community could learn something from that.
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.
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.
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.
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.
(Hilarious in the way that's terribly sad, of course.)
Nobody knows.
Anthropic took a mature and trusted project, threw it in a blender, and served the sloppy mess back out to the public.
Who would want their project to be held responsible for the million lines of code that even its vendor can no longer vouch for.
Maybe the new code will prove itself to be mature and worthy again someday, but that's going to take a long time and a lot of eyes. It's now completely reasomable to just move on from the project until that happens.
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.
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
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.
> 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.
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.
There's something really satisfying about a go binary with minimal dependencies running in a busybox docker container.
> 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.
I'm quite liking how good Claude Code Opus is at Rust + sqlx (raw SQL with type safety) + actix-web.
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
[0]: https://github.com/oven-sh/bun/pull/30412
2. Even if somehow you did make bug-free software with tests alone, even if the Rust port is perfect 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 a human, 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.