Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bun support is now limited and deprecated

github.com

Post reply on HN
Print view View original

51–60 of 646 posts

Re: Bun support is now limited and deprecated

#51

Post by gpm »

colordrops wrote: post #47
hootz wrote: post #2

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.

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?

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?

Re: Bun support is now limited and deprecated

#52

Post by Kiro »

josephcsible wrote: post #34
umvi wrote: post #11

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.

You only add what you need instead of importing some bloated dependency. That means you can actually review the code yourself.

Re: Bun support is now limited and deprecated

#53

Post by layer8 »

popinman322 wrote: post #17
smlavine wrote: post #6

Earlier quoted context omitted.

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.

Re: Bun support is now limited and deprecated

#54

Post by hootz »

colordrops wrote: post #47
hootz wrote: post #2

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.

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.

Re: Bun support is now limited and deprecated

#55

Post by applfanboysbgon »

nekzn wrote: post #24
malfist wrote: post #4

Earlier quoted context omitted.

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.

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.

Re: Bun support is now limited and deprecated

#56

Post by thatxliner »

maxloh wrote: post #12

I 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

it's funny how the readme still says "written in Zig"

Re: Bun support is now limited and deprecated

#59

Post by pessimizer »

happytoexplain wrote: post #44
muglug wrote: post #36

This like if BitTorrent cut off Windows support over objections to Microsoft embrace/extend/extinguish. It’s a slightly incoherent position.

This seems like a tenuous analogy, to put it lightly.

Care to explain why, or nah?

Re: Bun support is now limited and deprecated

#60

Post by dgellow »

happytoexplain wrote: post #10
antonvs wrote: post #3

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

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
Post reply on HN