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

451–460 of 646 posts

Re: Bun support is now limited and deprecated

#451

Post by aragilar »

usef- wrote: post #395
kelnos wrote: post #382

Earlier quoted context omitted.

I think it's perfectly rational to take a wait-and-see approach when a dependency has been completely rewritten from scratch. That would still be rational if it had been rewritten by hand, and not by an LLM.

This isn't a wait and see approach, this is proactively removing it

It's "we support 4 JS backends, we don't have the capacity to support 5 currently". They're not dropping bun entirely, instead bumping the minimum bun version and not supporting "bunv2" because they don't want to be beta testers.

Re: Bun support is now limited and deprecated

#453

Post by bitexploder »

827a wrote: post #242
cyanydeez wrote: post #213

Earlier quoted context omitted.

So this question was never answered: If Zig had so may problems that they felt compelled to rewrite it all in Rust, does that suggest the great Mythos was unable to fix the Zig version? Isn't this suppose to be the most advanced model ever and you're telling me they can't just schedule a cron job that detects and repairs the zig version? Really? Did they just completely admit that the great AI future can't secure a s…

AI is extremely good at rewriting existing code, and rewriting code is a classic engineering productivity trap. That's a tale as old as time; "we need to rewrite the api in Go" said every new midlevel engineering hire ever. Of course, 9 times out of 10 we don't do it, because the unpredictable costs always outweigh the benefit, and in Jarred's case we're starting to see these costs surface. They aren't technical, the…

Write in C, snapshot to memory safe production Rust that had been verified and differential tested to within an inch of its life. This is a hard reality. Ports will become cheap. Disposable. The vuln finding capabilities are changing everything and not a lot of solutions are out there yet. We can automate the ports and get them efficient.

Re: Bun support is now limited and deprecated

#454

Post by usef- »

aragilar wrote: post #451
usef- wrote: post #395

Earlier quoted context omitted.

This isn't a wait and see approach, this is proactively removing it

It's "we support 4 JS backends, we don't have the capacity to support 5 currently". They're not dropping bun entirely, instead bumping the minimum bun version and not supporting "bunv2" because they don't want to be beta testers.

Has the team announced that they're breaking backwards compatibility, or that testing will be reduced?

Re: Bun support is now limited and deprecated

#455

Post by zzrrt »

giancarlostoro wrote: post #348
827a wrote: post #86

Earlier quoted context omitted.

IMO the source of the new code is less important than the sheer volume of it. Bun does not need to be entirely rewritten; certainly not over a period of a week, possibly not even over a period of a year. Stability is hard-fought and battle-tested. Everyone has a plan until they get punched in the face; and every repository has passing tests until it runs production code.

How many lines of translated code would have been acceptable? What about before AI all the machine translated projects that people used for years without a single complaint? The person who did this was the lead for Bun from the get go no? So it stands to reason that they are one of the highest authorities in Bun itself.

> What about before AI all the machine translated projects that people used for years without a single complaint?

If by machine translation you mean something like transpiling, that's a technology that has been proven over decades, and the translators were written by hand with some attempt at formal correctness and guarantees. Translating with LLM is much newer and subject to the errors LLMs can create, such as hallucination. And I think a lot of people would still be nervous about translating an entire project of that many lines, even with the best pre-AI translators.

Re: Bun support is now limited and deprecated

#456

Post by happymellon »

tomjakubowski wrote: post #209
soledades wrote: post #201

Earlier quoted context omitted.

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/…

They did try upstreaming to Zig, but it was rejected for already being implemented not because it was vide coded.

https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...

Bun were so excited about their 4x speed improvement that they missed that Zig had already implemented it, plus other optimisations that were far larger.

Re: Bun support is now limited and deprecated

#458

Post by tonyedgecombe »

b40d-48b2-979e wrote: post #117
adamtaylor_13 wrote: post #80

We desperately need some new terminology to describe using LLMs to support development work. "Vibe code" has a strict definition but no one really cares. I have a really hard time believing that the Rust port was 100% "vibed" the way the original definition was laid out. It's a big slushy of emotions that I understand (both positive and negative) but it makes it so hard to actually tells what problem someone actually…

I'm using LLMs to assist my development and I'm measurably (in all the ways we engineers could possibly care about) doing better work faster. Studies suggest you aren't any faster and may in fact be slower. It's difficult to study such a new tech, but even optimistically, empirical evidence is only showing a ~3% gain in some domains. Writing code is rarely the limiting factor in our work.

Surely that argument is dead once someone has migrated a million lines of code in eight days.

Re: Bun support is now limited and deprecated

#459

Post by yallpendantools »

pylotlight wrote: post #434
tomjakubowski wrote: post #215

Earlier quoted context omitted.

Notably, they aren't (yet) dropping support for older, pre-rewrite versions of Bun. They also could be leaving the door open to support Bun in the future, if the rewrite proves successful. I think waiting and seeing is the right, conservative move.

If that was how it was phrased I think there would have been less push back, but that's not at all how it's been communicated. There is no assumption to rereview at a later date at all given the focus on the AI usage etc. If they said we will rereview in 1-6 months or whatever the whole discussion would be mute.

Why should yt-dlp commit to review their decision in the future about a project that makes no commitment (that I've seen) on reviewing their source code?

I get the idea to "battle-test" the rewrite first but (a) how does one even determine a reasonable timeframe for battle-testing that much LOC and (b) each vibe-coded update pushed to the Bun upstream basically resets the battle-testing timer. I guess you could lag behind $LATEST by a given window but that just brings us back to (a).

Given that part of their announcement is to keep supporting pre-rewrite versions of Bun, it implies to me that they are open to reconsider if the Bun team cleans up their act. I don't think it could get any more reasonable than that.

Re: Bun support is now limited and deprecated

#460

Post by boomlinde »

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 - I select them because they do the thing I want them to.

With that in mind, is there anything that yt-dlp uses the Bun runtime for which it can not use the other supported runtimes for? Similarly, perhaps the yt-dlp maintainers shouldn't keep supporting Bun just because it gives them a good feeling when every runtime incurs a maintenance cost.

That said, as a developer I skim over so much bullshit simply based on "bad feelings". I don't have time to evaluate every potentially useful technology in terms of whether it does what I want it to do, and no one else does either. It's clear to me that Bun is in an experimental phase of development and I think that's a good enough reason to move on if your use case is not.

Post reply on HN