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

281–290 of 646 posts

Re: Bun support is now limited and deprecated

#281

Post by happytoexplain »

johnfn wrote: post #280
add-sub-mul-div wrote: post #208

Earlier quoted context omitted.

That has nothing to do with what "politics" means but it's exactly how people have started using "political" to mean "idea I don't agree with".

I think there is a lot of overlap between politics and ideology, and an increasing amount of overlap between ideology and emotion. I think it's fair to call me out for skipping a step, but I wasn't using it to mean "idea I don't agree with".

>I wasn't using it to mean "idea I don't agree with".

I believe, maliciously or innocently, you were.

Re: Bun support is now limited and deprecated

#282

Post by Pay08 »

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.

The other side of this is that as far as I'm aware, Bun support in yt-dlp was always experimental. They mainly use Deno.

Re: Bun support is now limited and deprecated

#284

Post by tatjam »

johnfn wrote: post #139
apalmer wrote: post #131

Earlier quoted context omitted.

It's not really political. Or let me rephrase possibly yt-dl is being political. VUT the concept of 'not adopting a core dependency until it has been widely used in production for 6 months - a year.', is not a political on general. A full rewrite of 1 million loc is essentially a new runtime that has the same ABI as the previous and for many downstream consumers it's not something they are comfortable taking a produc…

I think your stance is more reasonable than the one in the article, TBH. If yt-dlp said something like "We're going to wait 6 months on the Rust rewrite", that would be reasonable. But instead it says something more like we think that Bun is vibe-coded, so we don't want to use it any more. That seems less reasonable.

Welp, I mean once the Rust rewrite is merged, isn't it vibecoded? Fair enough, it was vibecoded from a pretty detailed Zig specification :)

Re: Bun support is now limited and deprecated

#285

Post by tomjakubowski »

Supermancho wrote: post #277
yanis_t wrote: post #89

Do we know which model was used for the rewrite?

Claude Bun’s source code rewrite from Zig to Rust was executed primarily through AI-assisted development using Anthropic’s Claude agents, specifically within a branch named claude/phase-a-port. The project creator, Jarred Sumner, merged the massive pull request (PR #30412) on May 14, 2026, which involved over 1 million lines of code added and 6,755 commits completed in roughly one week.

Claude is a model provider: they have many models. It would be interesting to learn if the models used were Sonnet, Opus, Mythos, some other internal unreleased model, or some mixture of them.

Re: Bun support is now limited and deprecated

#286

Post by conartist6 »

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 wouldn't call it politics. I've seen enough people aim a gun at their foot and pull the trigger. They'll never thank you for stopping them, they just want to be left alone while they do it.

So, great, if this dude wants to regress through the workforce to a level of engineering maturity I associate with a high school student, I don't wish to try to be the one to stop him. Doesn't mean I'm gonna follow him. It's possible to be smart enough to just not walk into the tarpit. He's going in, I'm not.

Re: Bun support is now limited and deprecated

#287

Post by teaearlgraycold »

atonse wrote: post #234
kqp wrote: post #223

Earlier quoted context omitted.

Every single macOS update the top comments are about giving it six months to stabilize, but when a program’s biggest ever rewrite involves a lot of AI, the top comment is calling you irrational if you don’t YOLO it, and probably a jerk, too.

YOLO? Bun has an extensive test suite and this implementation passed the test suite. Can we at least try to be a bit more accurate and less hyperbolic? I will continue to use Bun because the same people that made bun have made this decision. I trusted them one week ago. I have used bun for the past 2 years, and so have many others. I'm not about to just assume they've become immature idiots yolo'ing stuff overnight.…

Presumably MacOS has an extensive test suite that it is passing before each disastrous release. Tests matter, but they aren’t the entire story.

Re: Bun support is now limited and deprecated

#288

Post by zipy124 »

So many people in the comments here are making assertions about the quality of the rust re-write but the point largely remains the same. There is no way you've read all million LOC in the time and reviewed to make sure it really is transpiled. It's not a criticism of the method, but the time and review process.

Re: Bun support is now limited and deprecated

#289

Post by Pay08 »

xdennis wrote: post #274
atonse wrote: post #234

Earlier quoted context omitted.

YOLO? Bun has an extensive test suite and this implementation passed the test suite. Can we at least try to be a bit more accurate and less hyperbolic? I will continue to use Bun because the same people that made bun have made this decision. I trusted them one week ago. I have used bun for the past 2 years, and so have many others. I'm not about to just assume they've become immature idiots yolo'ing stuff overnight.…

> this implementation passed the test suite Didn't they also change the tests to make the re-write pass?

They did, but they also reverted most of those changes.

Re: Bun support is now limited and deprecated

#290

Post by john_strinlai »

doug_durham wrote: post #130
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.

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

Post reply on HN