Bun support is now limited and deprecated • Hacker News Board

Re: Bun support is now limited and deprecated

#201

Post by soledades » Fri, May 22, 2026, 8:45 PM UTC

gpm wrote: post #192

nesarkvechnep wrote: post #136

Earlier quoted context omitted.

Then Bun's rewrite is also political. They couldn't upstream their vibe coded "improvements" so in spite they decided to vibe a rewrite in Rust. The arguments for the rewrite were not backed by any data.

> They couldn't upstream their vibe coded "improvements" What are you talking about? There is no upstream rejecting contributions here. It's the original bun developers who vibe-ported it to rust and they absolutely could and did upstream their vibe coded changes because they are the upstream.

they're referring to the changes they tried to upstream to zig.

Re: Bun support is now limited and deprecated

#202

Post by egorfine » Fri, May 22, 2026, 8:45 PM UTC

apalmer wrote: post #131

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…

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…

> A full rewrite of 1 million loc is essentially a new runtime

It's not a rewrite exactly. Nobody wrote anything. Not a single human has even seen, much less understood those 1m lines.

Re: Bun support is now limited and deprecated

#203

Post by 627467 » Fri, May 22, 2026, 8:45 PM UTC

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 will base that on data -- not a feeling I have.

and yet...

> If Bun starts having more bugs and feeling like worse software, I'll stop using it.

Is it not possible to judge that certain approach is more likely to bring unforseen controlable problems than another by analyzing how it works without assessing it's output? No "feeling" is needed

Re: Bun support is now limited and deprecated

#204

Post by OptionX » Fri, May 22, 2026, 8:46 PM UTC

hexage1814 wrote: post #103

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

[flagged]

What are you talking about? How do you think food get to the supermarket? People put it there.

The entire chain from farm to table is managed and operated by humans.

Every automatization effort ever always had human oversight.

Its not the same thing as entrusting the entire codebase to overachieving markov-chain who has no concept of correctness over anything of sounding ok.

Honestly, saying the humans understanding codebase is a dead concept is the most techbro-ish I heard today.

Re: Bun support is now limited and deprecated

#205

Post by oaweoifjwpo » Fri, May 22, 2026, 8:46 PM UTC

johnfn wrote: post #191

gpm wrote: post #178

Earlier quoted context omitted.

> Saying "because they vibe coded we are dropping support for Bun" sounds political. I don't think "political" is necessarily a bad thing. Engaging in politics is how you shape the world. The mere act of writing and maintaining yt-dlp is quite political considering the context of IP law and enforcement that we live in. It happens that in this case that I'd disagree with their politics if that's why they are dropping…

That's not what I meant by political. I meant political in the more modern sense of "appealing to emotion rather than thought". EDIT: Everyone is rightfully calling me out that this doesn't make a lot of sense. What I meant is that the move is driven by ideology. I think there is a lot of overlap between politics and ideology, and an increasing amount of overlap between ideology and emotion. But it's fair enough to c…

> I meant political in the more modern sense of "appealing to emotion rather than thought".

I'm not familiar with this definition in any modern or archaic sense. Is there somewhere I can read about it? Just because a decision is not directly engineering related (which I'm not even convinced this is) doesn't mean that it's not thoughtful.

Re: Bun support is now limited and deprecated

#206

Post by egorfine » Fri, May 22, 2026, 8:47 PM UTC

johnfn wrote: post #114

fdsajfkldsfklds wrote: post #106

Earlier quoted context omitted.

A key element of engineering is projecting a current trajectory. Given that, it absolutely makes sense to avoid tools that give you a bad feeling. The easiest time to move away from a tool that will become a train wreck is before you've integrated it.

But what exactly are you projecting? Typically when people have said they have a bad feeling about something (imagine Next.js) it's because they are running into more bugs or they are seeing more production incidents. In this case there has been no chance to observe these things.

It's 1mloc that no human has seen. There is no possibility for that project to be reliable, at least initially.

Re: Bun support is now limited and deprecated

#207

Post by htrp » Fri, May 22, 2026, 8:47 PM UTC

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

But you do select your engineering tools on faith apparently.

Re: Bun support is now limited and deprecated

#208

Post by add-sub-mul-div » Fri, May 22, 2026, 8:48 PM UTC

johnfn wrote: post #191

gpm wrote: post #178

Earlier quoted context omitted.

> Saying "because they vibe coded we are dropping support for Bun" sounds political. I don't think "political" is necessarily a bad thing. Engaging in politics is how you shape the world. The mere act of writing and maintaining yt-dlp is quite political considering the context of IP law and enforcement that we live in. It happens that in this case that I'd disagree with their politics if that's why they are dropping…

That's not what I meant by political. I meant political in the more modern sense of "appealing to emotion rather than thought". EDIT: Everyone is rightfully calling me out that this doesn't make a lot of sense. What I meant is that the move is driven by ideology. I think there is a lot of overlap between politics and ideology, and an increasing amount of overlap between ideology and emotion. But it's fair enough to c…

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".

Re: Bun support is now limited and deprecated

#209

Post by tomjakubowski » Fri, May 22, 2026, 8:48 PM UTC

soledades wrote: post #201

gpm wrote: post #192

Earlier quoted context omitted.

> They couldn't upstream their vibe coded "improvements" What are you talking about? There is no upstream rejecting contributions here. It's the original bun developers who vibe-ported it to rust and they absolutely could and did upstream their vibe coded changes because they are the upstream.

they're referring to the changes they tried to upstream to zig.

To be fair, I don't know if the Bun team ever did try to upstream it. In their Twitter thread announcing their vibe-coded fork of the Zig compiler, they said they wouldn't bother trying to upstream their changes because of Zig's policy banning LLM-authored contributions. Still probably a calculated political move to cut ties with Zig and muster community support for a Rust rewrite. https://x.com/bunjavascript/status/2048428104893542781

Re: Bun support is now limited and deprecated

#210

Post by egorfine » Fri, May 22, 2026, 8:48 PM UTC

cizezsy wrote: post #107

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 think refactoring 1M lines of code into another language within 7 days and merging it to master is responsible. I won't make my code depend on it.

It's not refactoring. It's LLM transpiled.