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

261–270 of 646 posts

Re: Bun support is now limited and deprecated

#261

Post by cheesefck »

burnte wrote: post #154
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. You are 100% right. This is a decision made on VIBES and not evidence. The proof is here: > Bun was recently rewritten in Rust using Claude, and its development seems to have taken a turn towards being fully vibe-coded. This is alarming and disappointing for a number of reasons, and frankly it seems like a future headache that we'd prefer to avoid. The…

[dead]

Re: Bun support is now limited and deprecated

#262

Post by tredre3 »

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.

> There's something really satisfying about a go binary with minimal dependencies running in a busybox docker container.

Go binaries are immensely satisfying, but I don't follow your logic here. The vast vast majority of dependencies in Go do not depend on the outside world, so the binary would remain self-contained whether it has 1 or 100 dependencies, no?

Re: Bun support is now limited and deprecated

#263

Post by jmull »

pizlonator wrote: post #245

I can’t help but read the logic as not being too far off from: “libfoo switched to being developed using emacs instead of vim so we can’t trust it anymore” It’s not the same obviously, but here’s why I can’t help but view it analogously: The only truth in software is whether it works or not for whatever your use case is. Even before AI, we couldn’t have known if the author of a piece of software was proceeding with r…

Most people probably think the text editor used would have no meaningful effect on the code written.

I don't think many would say the same for LLMs.

Maybe vibe bun is just as good or better than old bun, but how would we know at this point?

> ...we couldn’t have known if the author of a piece of software was proceeding with rigor...we didn’t judge someone’s software by inspecting their methodology...

That's not true. First, some people do directly check whether a project has a level of rigor they are comfortable with before adopting it (or when deciding whether to continue using it). I personally do it, where it matters. Many more use reputation signals, which, while certainly not perfect, correlate, may be good enough, and are a lot easier than direct, manual reviews.

Re: Bun support is now limited and deprecated

#264

Post by john_strinlai »

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.

1 million lines of code in 7 days = ~6000 lines of code to be reviewed per hour, 24 hours per day.

or... they just trust that their ai got it right, which to most people is "vibe coding".

Re: Bun support is now limited and deprecated

#265

Post by ajyoon »

oaweoifjwpo wrote: post #205
johnfn wrote: post #191

Earlier quoted context omitted.

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.

"Political" here means "I don't like it"

Re: Bun support is now limited and deprecated

#266

Post by awesome_dude »

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…

Humans have always appealed to emotion - as part of their logical process.

Fear (emotion) is used (advantageously) to force us to check that something isn't going to break us

In this instance fear is being used to ensure that yt-dlp is not exposed to (genuine) concerns about the quality of bun that is openly being built making use of tools we as a whole know is problematic.

I agree with you that the statements are a bit over the top (that's an emotional response to their statements btw) and that (eventually) you would /hope/ that bun gets to a point where it's got some genuine reliability from a users perspective.

Edit: I see your edit to explain that the issue is ideology - but unfortunately (perhaps) that's not an improved stance - ideology has to guide us when we just don't know - it's a heuristic.

Re: Bun support is now limited and deprecated

#267

Post by johnfn »

oaweoifjwpo wrote: post #205
johnfn wrote: post #191

Earlier quoted context omitted.

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.

That's fair - I updated my comment a little. What I mean is that the decision was driven by an ideological basis, not an empirical one. Bun was written with AI, AI doesn't fit with my ideology, therefore I reject it. As opposed to Bun has these new problems X Y and Z, therefore I reject it.

Re: Bun support is now limited and deprecated

#268

Post by gryn »

eddythompson80 wrote: post #144
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…

> It doesn't really matter.

It does matter, that's why those people quit because it's such a shitshow, progress happens at a glacial pace, more and more defects and slowdowns keep being created even if they have a big QA department/teams and the users are probably trapped because the software is the only thing in town, the bosses are the ones that makes the purchase decisions, or the it comes attached to big and/or expensive machines and they can't just buy another one for another X years.

Re: Bun support is now limited and deprecated

#269

Post by atonse »

truncate wrote: post #257
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.…

>> same people that made bun have made this decision Are they the same people though? Their interests, goals, environment, incentives, boss etc etc all changed after they got acquired by Anthropic. Its not uncommon for a big company to acquire a smaller one and completely destroy that product to serve the parent company's goal.

You can go read all the details on Jarred's X account - including the progress, how it was thought out, strategy, that they're aware that it looks like zig still, etc etc etc.

Speaking of environment though, everyone neglects to mention that the Bun core team now has access to Claude Mythos. You think they haven't already run Mythos against this? So they have private access to the best cybersecurity scanner known to man.

Suffice to say, I'm yet to see anything that really worries me in any major way with this.

Re: Bun support is now limited and deprecated

#270

Post by Supermancho »

egorfine wrote: post #241
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.

> This is what led to such a high volume of `unsafe` code Which defeats the purpose of having it in rust.

That is incorrect.

Identifying where code is unsafe, is a qualitative improvement. Not guaranteed to be complete, but more complete than a language that does not focus on that concern. Moving forward, the benefits of Rust compound. The concern about AI is orthogonal to the concern about moving to Rust.

Now there are 2 versions[1] that can be instrumented, regardless of the misgivings about AI.

[1] Bun v1.3.14, released on May 13, 2026 (commit 0d9b296af) and current.

Post reply on HN