Live data from Hacker News

Bun support is now limited and deprecated

github.com

221–230 of 646 posts

Re: Bun support is now limited and deprecated

#221
post #2

Oh well, I really like using Bun and I get kinda sad about the turn they are taking after the Anthropic acquisition. I really want a good Node with batteries included, but I don't want it vibe coded.

Have there been any significant issues caused by the vibecoded translation? To be clear, I'm not implying support for the merge. I am against this whole YOLO approach to engineering. Just curious how the switch is going since I haven't seen any news since the merge announcement.

Epistemically: if it can be so easily vibecoded to rust, why can't it be vibecoded to be reparted? Isn't the great and Almight AI unable to parse and repair Zig? Identify it's weak points and route around it?

Re: Bun support is now limited and deprecated

#222
post #142

I see a lot of commentators in this thread who are aggressively critical of volunteer maintainers for making a decision about how to maximize the value of the free labor they donate to the world. And yet none have offered to volunteer their time to maintain a downstream fork or otherwise rectify the perceived problem. Strange.

Which "volunteers" are you referring to? Bun? yt-dlp?

Re: Bun support is now limited and deprecated

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

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.

Re: Bun support is now limited and deprecated

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

It was not ported by an engineer. It was transpiled by an LLM and no engineer has ever seen those 1mloc.

Re: Bun support is now limited and deprecated

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

Wait, expecting all code to be verified and tested by a human is not engineering-driven but instead emotion-driven mindset???

[flagged]

Re: Bun support is now limited and deprecated

#226
post #162
post #145

Earlier quoted context omitted.

> 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. I think your final comment gets at it. If they said "OK, I am skeptical, so we're going to pause on updating to see how this Rust thing plays out" -- that sounds like a reasonable…

Adding support again later is cheap. Stopping maintaining and testing support for upcoming versions is cheaper than doing that work. Sure it’s political but it is also just a sane approach, to stay away from such disruptive change and treat it as wait-and-see instead of tagging along for the ride. There is not really any technical upside to tagging along and promising support.

> Stopping maintaining and testing support for upcoming versions is cheaper than doing that work.

If it’s based on predictions of how some alpha software might turn out in the future then I don’t see how you can claim it’s cheaper.

If a bunch of new bug reports came in then you said no, then everyone would understand.

This is pretty obviously ideological otherwise. Which is fine, but we shouldn’t pretend otherwise because we might agree with it

Re: Bun support is now limited and deprecated

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

Isn't that what Bun/Anthropic did? A rewrite based on vibes? Except "because we can" and the expectation that some kind of bug will be reduced and other metrics will not get worse All Bun devs are happy to change programming language? When their competition is already in rust and more mature While using the LLM that is now paying their salaries. Kind of a conflict of interest Even a major version upgrade is enough fo…

> Has Bun posted any analysis and shown the data?

Jarred promised a blog post just like he promised to not merge the slop branch.

Re: Bun support is now limited and deprecated

#228
post #53

Earlier quoted context omitted.

Very much agree. Until the vibe-coded version has been fully audited and profiled to perform, within reasonable tolerances, as well as the original code base, it feels like a bad idea to support it downstream or use it in production.

Even if it performs reasonably, it may still be unmaintainable, meaning that any future changes are likely to introduce bugs and instabilities. At the present state of AI coding it’s completely understandable not wanting to depend on code that the maintainers have no good understanding of. The code auditors would have to become the maintainers.

Any rational person investing in AI rewrites at this scale must fundamentally believe that all the downsides of the slop will eventually be cleaned up by the next version of the slop machine. So it's slop all the way down until, wave wands, the slop is indistinguishable from magic.

That is to say, techno jesus cometh.

Re: Bun support is now limited and deprecated

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

[dead]

Re: Bun support is now limited and deprecated

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

The changes submitted to zig were rejected because they were off an old fork and had already been implemented.

They may have been rejected for being vibe coded if they were original, but they were rejected for being pointless. The rust rewrite was because Bun was butt hurt that they didn't actually help.

Post reply on HN