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

191–200 of 646 posts

Re: Bun support is now limited and deprecated

#191

Post by johnfn »

gpm wrote: post #178
johnfn wrote: 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…

> Saying "because they vibe coded we are dropping support for Bun" sounds political. I don't think "political" is necessarily a bad thing. Engaging in politics is how you shape the world. The mere act of writing and maintaining yt-dlp is quite political considering the context of IP law and enforcement that we live in. It happens that in this case that I'd disagree with their politics if that's why they are dropping…

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 call me out here.

Re: Bun support is now limited and deprecated

#192

Post by gpm »

nesarkvechnep wrote: post #136
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…

Then Bun's rewrite is also political. They couldn't upstream their vibe coded "improvements" so in spite they decided to vibe a rewrite in Rust. The arguments for the rewrite were not backed by any data.

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

Re: Bun support is now limited and deprecated

#193

Post by johnfn »

dogleash wrote: post #188
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.

So, you're fanboying? If we're gonna fight, lets go xbox vs playstation. Javscript runtimes are a snoozefest.

Stating e.g. "Bun is more performant than Node [along a particular benchmark]" is not a fanboy statement. It's a statement of measurable fact.

Re: Bun support is now limited and deprecated

#195

Post by prmoustache »

thatxliner wrote: post #56
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 funny how the readme still says "written in Zig"

If Claude isn't even able to correct the readme, I don't know how one can have hope it produces decent results.

Re: Bun support is now limited and deprecated

#196

Post by rho_soul_kg_m3 »

oytis wrote: post #167
johnfn wrote: 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…

Vibe-coded code is a code no human has written, so no human truly understands how it works. It's a perfectly reasonable technical decision not to support such software, especially if actual human effoft is required for that

I wouldn't have problems with AI-generated code, but LLMs are not AIs, they are random sentence generators. They don't have logic, yet programs are logical constructs. So let's call this what it is: randomly-generated code, kinda sorta filtered by humans and tests. It's not because the output distribution has a good match with the expected distribution that it's not random. An LLM that is "hallucinating" is still working perfectly well and isn't doing anything different, in the same way that a straight-line fit through data points isn't "hallucinating" where it isn't overlapping the data points exactly.

Re: Bun support is now limited and deprecated

#197

Post by phoronixrly »

johnfn wrote: post #191
gpm wrote: post #178

Earlier quoted context omitted.

> Saying "because they vibe coded we are dropping support for Bun" sounds political. I don't think "political" is necessarily a bad thing. Engaging in politics is how you shape the world. The mere act of writing and maintaining yt-dlp is quite political considering the context of IP law and enforcement that we live in. It happens that in this case that I'd disagree with their politics if that's why they are dropping…

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

Re: Bun support is now limited and deprecated

#198

Post by oytis »

doug_durham wrote: post #115
bhaak wrote: 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.

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

Re: Bun support is now limited and deprecated

#199

Post by somebehemoth »

doug_durham wrote: post #122
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

I'm certain that the maintainers of Bun have excellent understanding of their codebase. What makes you think that they don't? They wrote the code in the first place. They know the architecture. They know what pieces do what functions.

They did not write the rust code. AI wrote that code. Your response is side stepping the primary issue people have with the rewrite: no human has read and understood all the code AI wrote.

Re: Bun support is now limited and deprecated

#200

Post by [deleted] »

gpm wrote: post #192
nesarkvechnep wrote: post #136

Earlier quoted context omitted.

Then Bun's rewrite is also political. They couldn't upstream their vibe coded "improvements" so in spite they decided to vibe a rewrite in Rust. The arguments for the rewrite were not backed by any data.

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

[deleted]
Post reply on HN