Top
Best
New

Posted by tamnd 3 hours ago

Bun support is now limited and deprecated(github.com)
211 points | 172 commentspage 3
the__alchemist 1 hour ago|
Bun alert!
potsandpans 1 hour ago||
Ah yes, more examples of averse behavioral ai syndrome
antonvs 2 hours ago||
Reason #2 is purely speculative. It’s disappointing to see technical decisions being made on such grounds.
smlavine 2 hours ago||
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.
popinman322 2 hours ago|||
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.
layer8 2 hours ago|||
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.
happytoexplain 2 hours ago||||
Yes, but only if auditing includes an exhaustive human review of the code, not just passing the tests we (or an AI) thought to write.
gpm 2 hours ago|||
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.
doug_durham 1 hour ago|||
Really?? So you base your engineer in "speculation". The Bun team has a deep track record of delivering a high quality product. What makes you think that is going to stop?
happytoexplain 2 hours ago|||
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.
dgellow 1 hour ago||
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
malfist 2 hours 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.
jhack 2 hours ago|||
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.
happytoexplain 2 hours ago||
The existence of bad code doesn't mean you should be happy to accept it.
cortesoft 2 hours ago||||
There is quite the selection bias going on here... you aren't hearing about the successful projects.
Dylan16807 2 hours ago|||
People love to brag about using AI to get work done. If anything I expect the successful projects to be overrepresented.
dawnerd 2 hours ago||||
Care to list them then? I have yet to see a successful vibe coded project
add-sub-mul-div 2 hours ago||||
With all the unprecedented investment and desperation behind it, these hypothetical LLM successes would be getting shoved down our throats.
asadotzler 1 hour 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.
nekzn 2 hours ago||||
Doesn’t bun have a massive test suite that the rewrite passes? What else do people want?
applfanboysbgon 2 hours ago|||
1. You cannot make bug-free software with tests alone. Moreover, code that compiles and executes successfully is only one goal, memory efficiency and performance and security 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 at perfect parity with the Zig codebase today owing to the years of careful human work that went into building tests as a framework to guide the AI... the future can only be downhill from here. Nobody has a mental model of the new 1m loc codebase that's never read by humans, so Bun's future is committed to 100% vibecoding. Maybe the carefully planned tests minimized the worst case scenario, but the future tests will be written by Claude too.

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

happytoexplain 2 hours ago|||
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.
skeledrew 1 hour ago||
How is "written by a thinking mind" a beneficial quality? All of sounds like to me is bias and gatekeeping. History repeating itself.
denidoman 2 hours ago|||
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.

mvdtnz 2 hours ago|||
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.
tuo-lei 2 hours ago||
[dead]
draw_down 2 hours ago||
[dead]
meindnoch 2 hours ago||
Good news!
mvdtnz 2 hours 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 2 hours 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.
umvi 2 hours 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.

xmodem 2 hours ago||
Rather than have complexity centralised and managed, let's generate the same vulnerable code across millions of apps. Great plan.
josephcsible 2 hours 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 2 hours ago||
You only add what you need instead of importing some bloated dependency. That means you can actually review the code yourself.
wizzwizz4 1 hour ago||
Relevant reading: 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 1 hour ago||
Are you aware this is satire?
wizzwizz4 54 minutes ago||
Yes, it says so right under the title. But it's not wholly fictional: this happens all the time, to the point we have a name for it (Not Invented Here syndrome).

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

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

c-hendricks 1 hour ago|||
That must be why so many vibe-coded UIs have awful UX (terrible contrast, too small fonts, everything gets its own colors, no attempts at standardized behaviour)
echelon 2 hours 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.

muglug 2 hours ago||
This like if BitTorrent cut off Windows support over objections to Microsoft embrace/extend/extinguish. It’s a slightly incoherent position.
happytoexplain 2 hours ago||
This seems like a tenuous analogy, to put it lightly.
pessimizer 2 hours ago||
Care to explain why, or nah?
garbagepatch 1 hour 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.
ivanjermakov 2 hours ago|||
Not BitTorrent, but I can see a world where e.g. Transmission dropping Windows support because of Microsoft policies.
IcyWindows 1 hour ago||
Which company doesn't do that?
merb 1 hour 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