Top
Best
New

Posted by tamnd 3 hours ago

Bun support is now limited and deprecated(github.com)
159 points | 99 commentspage 2
fastball 1 hour ago||
The "to vibe code or not to vibe code" holy war is now in full swing.
nh23423fefe 1 hour ago|
war implies "not vibe code" could win. that's impossible
nish__ 49 minutes 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.
thot_experiment 1 hour 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/ will solve all problems with embedding javascript. I believe, and maybe the strength of my belief will be enough.
satvikpendem 1 hour 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 1 hour ago|
Well, apparently Deno is also a slop now: https://github.com/yt-dlp/yt-dlp/issues/16766#issuecomment-4...
sheept 1 hour 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

szmarczak 57 minutes 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.
charcircuit 1 hour ago|||
Using AI to write code is not necessarily vibecoding nor slop.
cabernal 1 hour ago||
there could be recommended runtimes, but shouldn’t the runtime be user-configurable anyway?
layer8 1 hour 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 1 hour 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

rob 1 hour ago||

   --js-runtimes [deno|node|bun|quickjs]
sroussey 1 hour ago||
There is another by Meta for react native. Forgot the name.
nguyenkien 40 minutes ago||
hermes
meindnoch 1 hour ago||
Good news!
antonvs 2 hours ago||
Reason #2 is purely speculative. It’s disappointing to see technical decisions being made on such grounds.
smlavine 1 hour 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 1 hour 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 1 hour 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 1 hour 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 1 hour 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 44 minutes 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 1 hour 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 1 hour 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 1 hour 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 1 hour ago||
The existence of bad code doesn't mean you should be happy to accept it.
cortesoft 1 hour ago||||
There is quite the selection bias going on here... you aren't hearing about the successful projects.
Dylan16807 1 hour ago|||
People love to brag about using AI to get work done. If anything I expect the successful projects to be overrepresented.
dawnerd 1 hour ago||||
Care to list them then? I have yet to see a successful vibe coded project
add-sub-mul-div 1 hour 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 1 hour ago||||
Doesn’t bun have a massive test suite that the rewrite passes? What else do people want?
applfanboysbgon 1 hour 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 1 hour 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 30 minutes 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 1 hour 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 1 hour 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 1 hour ago||
[dead]
draw_down 1 hour ago||
[dead]
mvdtnz 1 hour 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 1 hour 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.
More comments...