Bun support is now limited and deprecated

Post by boomlinde » Sat, May 23, 2026, 5:49 AM UTC

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…

Post by otabdeveloper4 » Sat, May 23, 2026, 6:00 AM UTC

trollbridge wrote: post #14

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

Right. I now have responsibility for rather large codebases where the person who generated it with agentic tools (I'd say it's better than pure 'vibe coding') barely understands how it works. This is okay for unimportant parts of the codebase, but completely unacceptable for a critical piece of infrastructure where it really needs to be well thought out.

Post by bentcorner » Sat, May 23, 2026, 6:07 AM UTC

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.

Post by gregoryl » Sat, May 23, 2026, 6:09 AM UTC

tonyedgecombe wrote: post #458

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

Earlier quoted context omitted.

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.

Post by baq » Sat, May 23, 2026, 6:21 AM UTC

dlopes7 wrote: post #244

colordrops wrote: post #47

Earlier quoted context omitted.

Unless specific issues have been identified that were introduced by it being "vibe coded", isn't a reaction to reject it outright without actually checking the ground truth just exhibiting the behavior you are criticizing?

No, would you use a proudly vibe-coded banking app?