Live data from Hacker News

Bun support is now limited and deprecated

github.com

121–130 of 646 posts

Re: Bun support is now limited and deprecated

#121
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.

That's just agreeing with extra steps.

Re: Bun support is now limited and deprecated

#122
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 certain that the maintainers of Bun have excellent understanding of their codebase. What makes you think that they don't? They wrote the code in the first place. They know the architecture. They know what pieces do what functions.

Re: Bun support is now limited and deprecated

#123
post #101
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…

FYI in case you aren't aware, the rewrite was shipped, and then had to be reverted due to issues being discovered. That's "Jarred's high quality bar" you're so confident in.

News to me… share a link?

Re: Bun support is now limited and deprecated

#124
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]

THIS time it’s different.

Re: Bun support is now limited and deprecated

#125
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 believe you contradicted your first point by following it with "If Bun starts having more bugs and feeling like worse software" ...so you do use feelings in your calculation? To be clear, I have no problem with that and think there is some level of speculation you need to do when deciding what to rely on. As a hypothetical, pretend that Bun added obfuscated binary blobs that get executed at build time. Well, your c…

Bug counts are numbers. Memory usage and performance are numbers. Eventually those numbers get so bad that you leave.

Re: Bun support is now limited and deprecated

#126
post #114

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.

Engineering decisions and the resulting output.

We've known for decades that machine-translated code is garbage, and should only be done as a last resort.

Re: Bun support is now limited and deprecated

#127
post #49

Earlier quoted context omitted.

They literally threw out every line of code that existed before and rewrote it in a completely different language, seemingly on a whim. That's how it was trashed, in the very literal sense that all of the existing project was tossed in the trash in favor of a completely brand new code base. That's a big deal even if you ignore the coding agent aspects.

The worst part is that they basically didn't review the new code at all other than making sure it passes tests. We have no idea what could be lurking in the codebase now, and it's even all completely un-idiomatic, Zig-ish Rust.

I swear they did this as a marketing ploy. To set the precedent that these large refactors are okay to do, and ingrain it in the engineering zeitgeist.

Re: Bun support is now limited and deprecated

#128
post #101
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…

FYI in case you aren't aware, the rewrite was shipped, and then had to be reverted due to issues being discovered. That's "Jarred's high quality bar" you're so confident in.

The whole point of having canary builds is that they're unstable. That's why they're called canary. Rockets failing in test flights isn't a bad thing.

Re: Bun support is now limited and deprecated

#129
post #88

Earlier quoted context omitted.

absolutely, and `its development seems to have taken a turn towards being fully vibe-coded` ungrounded claim confirms the hysteria, I'm afraid

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.

I apologize, may I ask you, do you use Bun? If yes, you probably do monitor the development of this project (I do, it sounds reasonable to track your tools/deps), probably familiar with Jared's coding style, decision making process, architecture nuances, previous choices? Do you have any issues opened/closed in Bun's repo? Were you satisfied with contributors' reaction? Do you feel you can trust devteam behind Bun?

Re: Bun support is now limited and deprecated

#130
post #6
post #3

Reason #2 is purely speculative. It’s disappointing to see technical decisions being made on such grounds.

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