Hacker News Reader

Comment by antonvs | Hacker News Reader

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

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.

Any rational person investing in AI rewrites at this scale must fundamentally believe that all the downsides of the slop will eventually be cleaned up by the next version of the slop machine. So it's slop all the way down until, wave wands, the slop is indistinguishable from magic.

That is to say, techno jesus cometh.

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.

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.

> All dependency management is speculative.

What a nonsense generalization.

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

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

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

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?

>What makes you think that is going to stop?

a million-line rewrite over 7-8 days

>What makes you think that is going to stop?

The PR that was merged.

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

> The speculation in question is within the bounds of reason. Y

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

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.

The existence of bad code doesn't mean you should be happy to accept it.

Sometimes I step in dog poop. That doesn't mean I want to go to a dog park, find all the poop and roll around in it.

There is quite the selection bias going on here... you aren't hearing about the successful projects.

People love to brag about using AI to get work done. If anything I expect the successful projects to be overrepresented.

With all the unprecedented investment and desperation behind it, these hypothetical LLM successes would be getting shoved down our throats.

Care to list them then? I have yet to see a successful vibe coded project

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.

Doesn’t bun have a massive test suite that the rewrite passes? What else do people want?

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.

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.

How is "written by a thinking mind" a beneficial quality? All of sounds like to me is bias and gatekeeping. History repeating itself.

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.

Reply on news.ycombinator.com