There is an implicit assumption that the other supported runtimes aren't being vibe-coded. Looking at commit metadata tells a different story.
Bun support is now limited and deprecated
311–320 of 646 posts
Re: Bun support is now limited and deprecated
#312Earlier quoted context omitted.
> It seems a bit unfortunate to me that they've apparently already intending to never support future releases instead of planning on re-evaluating in the future. On the other hand the yt-dlp developers definitely don't owe anyone anything. I think your final comment gets at it. If they said "OK, I am skeptical, so we're going to pause on updating to see how this Rust thing plays out" -- that sounds like a reasonable…
> Saying "because they vibe coded we are dropping support for Bun" sounds political. I disagree that this is a political stance. People based on their experiences have formed opinions on whether they trust that model of development or not. Bun having taking extreme measure of going 100% in within a week is itself extreme positioning from their side which will likely result in extreme reactions because depending on wh…
In all sincerity, what does political even mean in this context? ELI5, I’m a toddler when it comes to the politics of AI/LLMs.
Re: Bun support is now limited and deprecated
#313I 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
Pretty normal in many corporate cultures especially ones with high turnover. You get assigned to a team that's "maintaining" a 10 year old code base with few million LoC. The most senior person on the team has been there for a year or 2 and it's just business as usual. You don't know what those 1M+ lines are doing. No one does. It's not a passion of anyone to work on it. You just get a bunch of requirements handed to…
Sounds like a great explanation of why it does matter!
Re: Bun support is now limited and deprecated
#314Honestly 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.
> There's something really satisfying about a go binary with minimal dependencies running in a busybox docker container. Go binaries are immensely satisfying, but I don't follow your logic here. The vast vast majority of dependencies in Go do not depend on the outside world, so the binary would remain self-contained whether it has 1 or 100 dependencies, no?
Assuming you disable CGO, yes, the binary is always self-contained. However, I want to clarify a few things.
The "self contained" part is only important in that it lets you use busybox or "from scratch" as your container runtime environment which has a very tiny cybersecurity surface area compared to, say, ubuntu or even alpine which has a bunch of system libraries your go binary isn't using, but which could still get flagged for having vulnerabilities.
Minimizing dependencies of the go binary is a separate, but equally important task that reduces the cybersecurity surface area of your go binary itself to just "the go standard library" instead of "go stdlib + a dozen github packages"
Whenever I am working with a NodeJS project I pity the fool who has to do SCA because the CVE surface area is enormous compared to go, which has a fairly batteries-included stdlib
Re: Bun support is now limited and deprecated
#315Earlier quoted context omitted.
I'm certain that the maintainers of Bun have excellent understanding of their codebase. What makes you think that they don't? They wrote the code in the first place. They know the architecture. They know what pieces do what functions.
They did not write the rust code. AI wrote that code. Your response is side stepping the primary issue people have with the rewrite: no human has read and understood all the code AI wrote.
I had an actual look at the code, and because it's a translation it's not just straight up de novo slop. The bits I saw were fairly straightforward 1:1 translations, so the Bun developers should still be familiar with the overall structure and logic.
I still think it's mad, but not quite as mad as you might first think from the headlines.
Re: Bun support is now limited and deprecated
#316Earlier quoted context omitted.
> It seems a bit unfortunate to me that they've apparently already intending to never support future releases instead of planning on re-evaluating in the future. On the other hand the yt-dlp developers definitely don't owe anyone anything. I think your final comment gets at it. If they said "OK, I am skeptical, so we're going to pause on updating to see how this Rust thing plays out" -- that sounds like a reasonable…
> Saying "because they vibe coded we are dropping support for Bun" sounds political. I disagree that this is a political stance. People based on their experiences have formed opinions on whether they trust that model of development or not. Bun having taking extreme measure of going 100% in within a week is itself extreme positioning from their side which will likely result in extreme reactions because depending on wh…
I disagree as well, and wonder if the OP meant an emotional or ideological stance instead.
Re: Bun support is now limited and deprecated
#317Earlier quoted context omitted.
>> same people that made bun have made this decision Are they the same people though? Their interests, goals, environment, incentives, boss etc etc all changed after they got acquired by Anthropic. Its not uncommon for a big company to acquire a smaller one and completely destroy that product to serve the parent company's goal.
You can go read all the details on Jarred's X account - including the progress, how it was thought out, strategy, that they're aware that it looks like zig still, etc etc etc. Speaking of environment though, everyone neglects to mention that the Bun core team now has access to Claude Mythos. You think they haven't already run Mythos against this? So they have private access to the best cybersecurity scanner known to…
I've read the details, strategy, extensive test suite etc. I'm sorry, I don't think "they have access to Claude Mythos" is the rationale to it unless you truly believe the marketing 100%.
I think we'll just see how it all turns out. Maybe check back in a year or two on hwo it all goes. Anyone who says they "know" or are "very sure" this is the right path or wrong path is plain stupid IMO. Having seen how things work in big companies with high market visibility, I believe there is non-trivial chance this driven mostly as marketting stunt (particularly in current climate) and decision isn't purely based on best interest of Bun's future and longevity.
Re: Bun support is now limited and deprecated
#318Honestly 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.
I never said AI code should be "unreviewed". I'm saying that instead of pulling in axios or requests (as a contrived example) to make HTTP requests, just use AI to generate some vanilla JS/Python that has the exact subset of functionality you need. Your code has fewer dependencies, CVE surface area, etc, wins all around.
Re: Bun support is now limited and deprecated
#319This title is wrong. It makes it sounds like Anthropic dropped support for and deprecated Bun.
Re: Bun support is now limited and deprecated
#320Earlier quoted context omitted.
The worst part is that they basically didn't review the new code at all other than making sure it passes tests. We have no idea what could be lurking in the codebase now, and it's even all completely un-idiomatic, Zig-ish Rust.
I swear they did this as a marketing ploy. To set the precedent that these large refactors are okay to do, and ingrain it in the engineering zeitgeist.
Kind of reminds me how Google starting putting on automatic AI processing of YouTube videos and shorts around the time of AI generated video and images. Their processing gave the videos artifacts that made them look more AI generated, making it harder to discern AI generated images, maybe to make demand for their watermark products.