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

91–100 of 646 posts

Re: Bun support is now limited and deprecated

#91

Post by 827a »

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…

You may not want to take part in politics, but politics wants to take a part in you.

Re: Bun support is now limited and deprecated

#92

Post by 827a »

nkmnz wrote: post #84
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

So it was possible to write ~2 million lines of (mostly) zig, but it's not possible to review ~1 million lines of rust, even though the same test suite included in those 2 million lines of zig can still be used? I'm not convinced the rewrite is a good idea and will work out, but I'm equally unconvinced by your argument.

Its possible to do that over a period of a few years. Sadly, the Rust rewrite happened in (checks notes) 8 days.

Re: Bun support is now limited and deprecated

#93

Post by raincole »

hnav wrote: post #90
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…

a vibecoded rewrite right after being acquired is not political?

No one says that? Of course Bun rewrite is political. And if you deprecate Bun support due to they did something political, obviously this decision itself is political too.

Re: Bun support is now limited and deprecated

#94

Post by rcxdude »

layer8 wrote: post #77
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?

The ground truth is that the new maintainers can’t possibly have a good understanding of the many millions of lines of vibe-translated code. Even assuming that the code happens to work okay in its current state, the lack of understanding means a high risk that its continuing maintenance won’t result in a satisfactory level of reliability.

Aren't the maintainers the same people? I haven't seen any talk of who's working on it changing drastically.

Re: Bun support is now limited and deprecated

#95

Post by sashank_1509 »

Has bun really shipped using a million line vibecoded PR. I know they merged it, but merging something in a new dir doesn’t mean anything compared to what code is actually running for customers. It’s crazy if the vibecoded rust version is what’s running for customers and not just some experimental hack.

Re: Bun support is now limited and deprecated

#96

Post by nish__ »

cizezsy wrote: post #83
leobuskin wrote: post #79

Earlier quoted context omitted.

absolutely, and `its development seems to have taken a turn towards being fully vibe-coded` ungrounded claim confirms the hysteria, I'm afraid

What are you afraid of?

A codebase that no human understands.

Re: Bun support is now limited and deprecated

#97

Post by LoganDark »

tedivm wrote: post #49
vosper wrote: post #38

Earlier quoted context omitted.

How has it been trashed? Does the Bun software not work anymore?

They literally threw out every line of code that existed before and rewrote it in a completely different language, seemingly on a whim. That's how it was trashed, in the very literal sense that all of the existing project was tossed in the trash in favor of a completely brand new code base. That's a big deal even if you ignore the coding agent aspects.

The worst part is that they basically didn't review the new code at all other than making sure it passes tests. We have no idea what could be lurking in the codebase now, and it's even all completely un-idiomatic, Zig-ish Rust.

Re: Bun support is now limited and deprecated

#98

Post by gpm »

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…

> 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 experiment on your users if you thought there was a reasonable probability of increased security vulnerabilities.

I think there's a good argument that the responsible thing to say would be "we aren't going to immediately support running our software on a new bun release cut from main right now".

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.

Re: Bun support is now limited and deprecated

#99

Post by szmarczak »

sheept wrote: post #30
blain wrote: post #16

Earlier quoted context omitted.

Well, apparently Deno is also a slop now: https://github.com/yt-dlp/yt-dlp/issues/16766#issuecomment-4...

Deno's LLM contributions have been smaller in scope, so they're more likely to be reviewed by a human, and the codebase remains understood by its contributors. Can the same be said of Bun, which switched to an entirely different language in a single, million-line PR?[0] [0]: https://github.com/oven-sh/bun/pull/30412

Since when small vibe coded slop became the norm? Because there exists bigger vibe coded slop, it's no justification to have a smaller vibe coded slop.

Re: Bun support is now limited and deprecated

#100

Post by leobuskin »

cizezsy wrote: post #83
leobuskin wrote: post #79

Earlier quoted context omitted.

absolutely, and `its development seems to have taken a turn towards being fully vibe-coded` ungrounded claim confirms the hysteria, I'm afraid

What are you afraid of?

I'm afraid "we" tackle (agressively) the wrong problem, also making it's tough for the maintainers, who did nothing wrong (I have a lot of sympathy towards Bun's developers, they got a lot of ugly feedback within the last month). I don't think AI-written code is the problem at all. Human signs off the changeset the same way as it happened before. I don't care if Rust rewrite did happen using pipeline/harness and LLMs, if the maintainer takes responsibility, and in projects like Bun it happens "by default", I think.
Post reply on HN