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

141–150 of 646 posts

Re: Bun support is now limited and deprecated

#141

Post by negura »

johnfn wrote: post #73

This decision seems to based more in politics than engineering. Have you observed Bun have more segfaults, OOMs, etc, since the Rust rewrite? Have you noticed more security vulnerabilities? Have you seen more bugs? (Of course you haven't, the rewrite hasn't even landed yet.) It seems that you are making this decision because you get a bad feeling when thinking about AI involvement. I don't select my engineering tools…

> This decision seems to based more in politics than engineering.

I'm glad some engineers realize that technology is inseparable from politics. It always has been. All evil came from engineers who beleived they were above politics. Selecting the tool which got the job done/made the number go up/paid a paycheck is how we got Facebook, Google, Palantir, crypto, AI, techno-fascism and neo-feudalism. None of it would've have happened without engineers blindly applying their knowledge to achieve "purely" technical results, while ignoring the social consequences. With the hindsight of the last 20 years, anyone who still advocates for an irresponsible adoption of technology should be considered automatically suspect

Re: Bun support is now limited and deprecated

#142

Post by xmodem »

I see a lot of commentators in this thread who are aggressively critical of volunteer maintainers for making a decision about how to maximize the value of the free labor they donate to the world.

And yet none have offered to volunteer their time to maintain a downstream fork or otherwise rectify the perceived problem.

Strange.

Re: Bun support is now limited and deprecated

#143

Post by olzd »

wizzwizz4 wrote: post #78
Kiro wrote: post #52

Earlier quoted context omitted.

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

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 dependenci…

Are you aware this is satire?

Re: Bun support is now limited and deprecated

#144

Post by eddythompson80 »

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

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 you, you blackbox everything but the surface areas you need to touch. It's why there are 14 implementations of a background service 8 dependencies that do the same thing, 6 overlapping frameworks, a complete mismatch in style, approaches, etc. It doesn't really matter.

Re: Bun support is now limited and deprecated

#145

Post by johnfn »

gpm wrote: post #98
johnfn wrote: post #73

This decision seems to based more in politics than engineering. Have you observed Bun have more segfaults, OOMs, etc, since the Rust rewrite? Have you noticed more security vulnerabilities? Have you seen more bugs? (Of course you haven't, the rewrite hasn't even landed yet.) It seems that you are making this decision because you get a bad feeling when thinking about AI involvement. I don't select my engineering tools…

> Have you observed Bun have more segfaults, OOMs, etc, since the Rust rewrite? Have you noticed more security vulnerabilities? Have you seen more bugs? (Of course you haven't, the rewrite hasn't even landed yet.) On the flip side it's not on the yt-dlp authors to test Bun's new development process and see if it results in more segfaults, OOMs, security vulnerabilities, etc. In fact it would arguably be negligent to…

> 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 engineering decision. Saying "because they vibe coded we are dropping support for Bun" sounds political.

Re: Bun support is now limited and deprecated

#147

Post by b40d-48b2-979e »

doug_durham wrote: post #115
bhaak wrote: post #88

Earlier quoted context omitted.

The whole code base is a vibe coded rewrite, half a year after Bun was acquired by Anthropic. I see lots of ground for that claim.

There is no evidence that it was "vibe" coded. It was ported to Rust by an expert engineer using an AI tool using solid SWE practices.

Those SWE practices were so solid that the rewrite was already rolled back!

Re: Bun support is now limited and deprecated

#148

Post by rileymichael »

johnfn wrote: post #73

This decision seems to based more in politics than engineering. Have you observed Bun have more segfaults, OOMs, etc, since the Rust rewrite? Have you noticed more security vulnerabilities? Have you seen more bugs? (Of course you haven't, the rewrite hasn't even landed yet.) It seems that you are making this decision because you get a bad feeling when thinking about AI involvement. I don't select my engineering tools…

> I don't select my engineering tools because they give me a bad feeling - I select them because they do the thing I want them to. If Bun starts having more bugs and feeling like worse software, I'll stop using it. But I will base that on data -- not a feeling I have.

being reactive is fine if you can tolerate issues. otherwise, you need to be proactive -- don't wait for the train to hit you before you move off the tracks

Re: Bun support is now limited and deprecated

#149

Post by b40d-48b2-979e »

therepanic wrote: post #111

To be honest, I share primeagen's view that LLMs handle translating code from one language to another quite well. As far as I know, they converted the languages file by file. This is what led to such a high volume of `unsafe` code. Although, in any case let's be honest, this is causing, and will continue to cause, various issues. I find it easier to live with this point of view.

    primeagen's view
He's a content creator on youtube, a celebrity, not a serious programmer.

Re: Bun support is now limited and deprecated

#150

Post by c-hendricks »

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.

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