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

371–380 of 646 posts

Re: Bun support is now limited and deprecated

#371

Post by inatreecrown2 »

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…

The first sentence on the linked page is literally: "Due to foreseeable compatibility and security issues"

Re: Bun support is now limited and deprecated

#372

Post by backwardsponcho »

TheCoreh wrote: post #329
maxloh wrote: 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.

And five engineers reviewing 20 thousand LoCs would get the job done in ten days, but both numbers are just as BS when it comes to actually understanding the codebase. No one is comprehensively reading 5k lines per day for a month straight.

Re: Bun support is now limited and deprecated

#373

Post by johnfn »

n_e wrote: post #216
johnfn wrote: post #120

Earlier quoted context omitted.

Jared has shipped a lot of things that have impressed me. His software is measurably faster than the alternatives, and I have measured it. It runs code that Node et al can't run, and I have tried. These are normal, everyday experiences with software - based in fact, not vibes. I'm not going to argue every decision he's ever made is amazing, but his decisions have historically tracked above average.

> It runs code that Node et al can't run What kind of code can't node run?

Bun supports import and require together in the same file https://bun.com/docs/runtime/module-resolution#using-import-...

Re: Bun support is now limited and deprecated

#374

Post by terminalbraid »

ungovernableCat wrote: post #295

Why are some people so pressed about this decision? From my point of view, if you're truly a vibe code enthusiast wouldn't you be able to just vibe code your own better yt-dlp (or fork the existing one and do whatever you need to do with it)?

What's more is yt-dlp already has plugin support for 3rd party interpreters. They're just saying they don't want to deal with supporting bun themselves and the infrastructure for anyone else do use whatever they want is already there.

This is just the standard misguided entitlement people feel towards other people's projects supported by other people's time and effort. It's continually outrageous to me how people feel they can just volunteer other people's time and effort to support their own wants. The people who do the work are entitled to make their decisions and if you don't like it fork it yourself. This has been the way of this ecosystem since it started.

yt-dlp is surprisingly hackable as is.

Re: Bun support is now limited and deprecated

#375

Post by shimman »

oytis wrote: post #198
doug_durham wrote: post #115

Earlier quoted context omitted.

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.

How can you claim following SWE best practices if couldn't realistically even have read the code?

"Please follow best practices."

You're telling me that isn't good enough? You might need to head off to the VC reeducation camps.

Re: Bun support is now limited and deprecated

#376

Post by feelamee »

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…

> This decision seems to based more in politics than engineering.

Will you use untrustworthy dependencies in your project, which has users? I think, no.

I don't know, but I feel that this is the case with yt-dlp.

And this is absolutely engineering - care about quality and security of your software, which is used by thousands of people

Re: Bun support is now limited and deprecated

#377

Post by kelnos »

johnfn wrote: post #145
gpm wrote: post #98

Earlier quoted context omitted.

> 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.) On the flip side it's not on the yt-dlp authors to test Bun's new development process and see if it results in more segfaults, OOMs, security vulnerabilities, etc. In fact it would arguably be negligent to…

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

Why is it "political" to say "I don't trust software fully written by an LLM that has not been vetted by a human"?

That feels like an entirely reasonable stance to take.

And I see the argument/correction downthread that it's an "emotional" or "ideological" stance. Why does it have to be that? It seems completely rational and logical not to trust software written by a technology that is known to hallucinate and "cheat" to make tests pass.

Of course, I can't say that the yt-dlp maintainer is or isn't being political/emotional/ideological when making this decision; none of us can know their true motivations without asking them, and I choose the charitable explanation unless shown evidence otherwise.

Re: Bun support is now limited and deprecated

#378

Post by Capricorn2481 »

johnfn wrote: post #139
apalmer wrote: post #131

Earlier quoted context omitted.

It's not really political. Or let me rephrase possibly yt-dl is being political. VUT the concept of 'not adopting a core dependency until it has been widely used in production for 6 months - a year.', is not a political on general. A full rewrite of 1 million loc is essentially a new runtime that has the same ABI as the previous and for many downstream consumers it's not something they are comfortable taking a produc…

I think your stance is more reasonable than the one in the article, TBH. If yt-dlp said something like "We're going to wait 6 months on the Rust rewrite", that would be reasonable. But instead it says something more like we think that Bun is vibe-coded, so we don't want to use it any more. That seems less reasonable.

I think it's fine to not depend on code that nobody, even the maintainers, has read. Is that really controversial?

I do find it ironic you think this project is making rash decisions on no technical merit, and not Bun

Re: Bun support is now limited and deprecated

#379

Post by davidee »

vcryan wrote: post #370

I don't think it matters how code is produced -- it matters what it achieves. Is there evidence that there is something wrong with recent Bun releases?

I think one of the big disconnects here are the competing views about "what it achieves" means on a fundamental level.

There's the "what it achieves" today; software x works as intended as of right now.

And then there's "what it achieves" long term.

Those with significant experience with sprawling, LLM-generated, codebases, often built by those who don't understand the code produced, can attest to things being good today, unworkable tomorrow.

While this isn't true across the board, and my own experience should be considered anecdotal at best, those who consider "what it achieves" to also include long term viability as a success metric, are skeptical of these types of changes.

Personally, success for dependencies isn't just "does it work today" but "can I trust it to work long term."

I don't use Bun. I don't care about Bun. But my opinion is that how code is produced will have some effect on what it achieves, if the goalpost includes more than "it works today."

Re: Bun support is now limited and deprecated

#380

Post by isityettime »

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…

What world do you live in where selecting your dependencies doesn't involve personal judgment calls?
Post reply on HN