Live data from Hacker News

Bun support is now limited and deprecated

github.com

321–330 of 646 posts

Re: Bun support is now limited and deprecated

#321
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…

As far as I'm concerned Bun has been extremely irresponsible with this entire rewrite, and it calls into question their entire development philosophy. Any project that cares about stability and reliability should steer clear of Bun for a while.

Re: Bun support is now limited and deprecated

#322
post #301

Earlier quoted context omitted.

Bun has a test suite of tens of thousands of tests. For purely non-functional changes, like refactors or rewrites (e.g. a Rust rewrite) I rely primarily on test suites, not manual testing, in order to ensure that nothing regressed. I mean, sure, I am going to poke around, too, but the test suite is the encoding of thousands of obscure bugs and issues over years. There is no way my manual testing will be able to cover…

> Test code written by a human counts as "tested by a human". Were Bun's tests generated by an LLM? If they were, were they read by a human afterwards to be validated?

Publicly based on my calculations[1] there only ~20k tests. I would say they are usual tests for the runtime. Constantly running on the CI much lesser amount. Average test count/line of code ratio drops after rewrite. And even before Node have denser tests count/LOC ratio

[1] https://kant2002.github.io/en/llm/2026/05/16/bun-pr-analysis...

Re: Bun support is now limited and deprecated

#323
post #301

Earlier quoted context omitted.

Test code written by a human counts as "tested by a human". Also, most code is literally tested (manually) by humans in addition to automated tests. You are being pointlessly pedantic.

Bun has a test suite of tens of thousands of tests. For purely non-functional changes, like refactors or rewrites (e.g. a Rust rewrite) I rely primarily on test suites, not manual testing, in order to ensure that nothing regressed. I mean, sure, I am going to poke around, too, but the test suite is the encoding of thousands of obscure bugs and issues over years. There is no way my manual testing will be able to cover…

[deleted]

Re: Bun support is now limited and deprecated

#324

Earlier quoted context omitted.

> Saying "because they vibe coded we are dropping support for Bun" sounds political. I disagree that this is a political stance. People based on their experiences have formed opinions on whether they trust that model of development or not. Bun having taking extreme measure of going 100% in within a week is itself extreme positioning from their side which will likely result in extreme reactions because depending on wh…

In all sincerity, what does political even mean in this context? ELI5, I’m a toddler when it comes to the politics of AI/LLMs.

Its a polarizing world with AI. There are fanboys drinking the kool-aid blindly listening to whatever Sammy/Dario/... say as gospel, and on other side there are haters who again blindly reject the fact that these AI tools can be actually be useful. I think that's what the politics is.

Re: Bun support is now limited and deprecated

#325
post #152
post #90

Earlier quoted context omitted.

a vibecoded rewrite right after being acquired is not political?

Is it so unthinkable to people on "hacker" news that someone might want to try a cool experiment like rewriting an entire repo into Rust?

Most commenters here don't have an issue with Rust.

The 1M lines of code refactor by AI in a week or so then thrown into a production codebase... Yeah

Re: Bun support is now limited and deprecated

#326
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…

Everything is politics, sorry to say. Even software engineering try as we might.

> feeling like worse software

Politics ;)

Re: Bun support is now limited and deprecated

#327
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

I'm very skeptic that they read the entire codebase of Bun prior.

Re: Bun support is now limited and deprecated

#328
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

I don’t think changing from zig to rust suddenly means that don’t know what a certain file contains or how it works or how it relates to other files. It’s all the same just different syntax. Which, by the way, is why it looks ugly to rust developers. The devs wanted the code to look familiar to them. I do think they should have called this 2.0 though. Would not feel such a rush (1.3.14 has a few regressions, and no o…

I assume most of the complaints about the massive rewrite are in regards to AI, not Rust.

As lots of large and small companies have shown, test suites can only find what you test for. Vibe coded test suites can find?

Re: Bun support is now limited and deprecated

#329
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 not impossible, or even that hard to review the entire rewritten codebase.

10 engineers each reviewing 5,000 LoC a day for 20 days can do it.

And that is being highly conservative with the estimate. A good chunk of the the code is probably highly trivial boilerplate one can easily skim over in minutes.

Re: Bun support is now limited and deprecated

#330

Earlier quoted context omitted.

They did not write the rust code. AI wrote that code. Your response is side stepping the primary issue people have with the rewrite: no human has read and understood all the code AI wrote.

I agree but would propose the weaker argument: no set of human contributors have, put together, read and understood all the code. Even in artisanal-coded projects of sufficient size, it's rare that any one human has read and understood all of it.

The million or so lines of the original code has been "battle tested" for what it's worth.

This is a massive codebase created within a week or so ago, no one can say what it will do till it does.

Post reply on HN