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

611–620 of 646 posts

Re: Bun support is now limited and deprecated

#611

Post by soraminazuki »

usef- wrote: post #605
soraminazuki wrote: post #564

Earlier quoted context omitted.

"Who did they mislead? They just changed their minds a few days later and words aren't what you think they mean. Here's the team's PR statement containing assertions about the 1M lines of code they never reviewed." It's unfortunate that this is what some call "engineering" while labeling actual science and engineering as "politics." yt-dlp is under no obligation to keep using a dependency from vendors that instantly…

I suspect this thread won't go anywhere. Something that's experimental can receive further changes and then no longer be considered experimental.

There could be some genuine discussion if you stop bending over backwards justifying YOLO prompting with strained logic.

Re: Bun support is now limited and deprecated

#612

Post by throwaway27448 »

hurfdurf wrote: post #553
throwaway27448 wrote: post #482

Can anyone explain why bun was used to begin with?

Processing the YouTube-scripts to get to the video addresses. It was never the default option for that purpose, which is deno.

but isn't this just javascript?? Where is the standard interpreter?

Re: Bun support is now limited and deprecated

#613

Post by usef- »

soraminazuki wrote: post #611
usef- wrote: post #605

Earlier quoted context omitted.

I suspect this thread won't go anywhere. Something that's experimental can receive further changes and then no longer be considered experimental.

There could be some genuine discussion if you stop bending over backwards justifying YOLO prompting with strained logic.

Feel free to point out where my logic is wrong. It sounds like you think they've made a stable release already? None of the new code is sent to users yet. It's a direct translation without relying on major AI decisions. I'm happy to call them cowboys if they make a release with lousy testing.

Re: Bun support is now limited and deprecated

#614

Post by soraminazuki »

usef- wrote: post #613
soraminazuki wrote: post #611

Earlier quoted context omitted.

There could be some genuine discussion if you stop bending over backwards justifying YOLO prompting with strained logic.

Feel free to point out where my logic is wrong. It sounds like you think they've made a stable release already? None of the new code is sent to users yet. It's a direct translation without relying on major AI decisions. I'm happy to call them cowboys if they make a release with lousy testing.

> Feel free to point out where my logic is wrong.

I already have, as have others, but

> It sounds like you think they've made a stable release already?

What's the point if you keep refusing to acknowledge the issue and tossing out theories about how I and others might be wrong, just to see what sticks?

> None of the new code is sent to users yet.

So? The decision to adopt was already made and the code was merged without planning, without considering downstream impacts, and without proper inspection. People who won't read their own code before merging won't read it after. But many of you don't even see this as an issue. So again, what's the point in trying to point all of this out?

Also you yourself said the experiment is over. You can't have it both ways.

> It's a direct translation without relying on major AI decisions.

Because the genie said so? That sounds lacking in scientific rigor, but

> I'm happy to call them cowboys if they make a release with lousy testing.

Oh right, that the test passes is proof that the new code is debuggable, maintainable, architecturally sound, semantically equivalent to the old code, and non-disruptive for downstream users. Apparently testing has leapt centuries ahead in the past two weeks or so.

Re: Bun support is now limited and deprecated

#616

Post by forresthopkinsa »

fortyseven wrote: post #572
jabavagauha wrote: post #558

Earlier quoted context omitted.

What about people who view AI as a useful tool, and use it daily while still recognizing it’s limitations? I’m no AI hater, but there’s a limit to how much trust I give it and the Bun rewrite is well beyond that limit.

It's a bit of a contradiction. We understand that AI can be used usefully, and to great effect. But if someone else uses it, it's a potential liability. I think the issue is, we understand our own usage of it, and respect the boundaries of what's possible and what needs to be done to use these tools properly. But we don't know how the other guy is using it. We don't know if they're being responsible, and using it in…

AI or not, I trust a development team with a rigorous code review process, and I distrust a team that merges one-shot seven-figure PRs.

Bun has very loudly defected from the former category to the latter.

Re: Bun support is now limited and deprecated

#617

Post by fmbb »

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

Proactively removing work, yes.

Re: Bun support is now limited and deprecated

#618

Post by fmbb »

dmix wrote: post #226
fmbb wrote: post #162

Earlier quoted context omitted.

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

I don’t thing maintaining and testing support for an extra runtime is free.

It is by definition cheaper to not support extra runtimes like Kaluma, Elsa, WinterJS. Adding support is not just the initial work of adapting CI and writing policies, maintenance and support is ongoing work.

Re: Bun support is now limited and deprecated

#619

Post by usef- »

soraminazuki wrote: post #614
usef- wrote: post #613

Earlier quoted context omitted.

Feel free to point out where my logic is wrong. It sounds like you think they've made a stable release already? None of the new code is sent to users yet. It's a direct translation without relying on major AI decisions. I'm happy to call them cowboys if they make a release with lousy testing.

> Feel free to point out where my logic is wrong. I already have, as have others, but > It sounds like you think they've made a stable release already? What's the point if you keep refusing to acknowledge the issue and tossing out theories about how I and others might be wrong, just to see what sticks? > None of the new code is sent to users yet. So? The decision to adopt was already made and the code was merged with…

Testing is a broader term covering multiple things, up to and including the decision of when you have enough confidence in the system to declare it stable. The test pass rate was an early bar for merging into dev, not release.

The translation did not change the architecture: it was a 1:1 translation with even the same internal data structures. Rust written in a zig-like way, with the original Zig still available as reference. AI can make an absolute mess when making architectural decisions, but translation like this plays to the strength of current AI, especially when moving to a stricter language.

The code being in the dev branch means that they now are open to community feedback and testing, and no date is set on it being declared stable. We'll see how the team handles it.

Post reply on HN