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

131–140 of 646 posts

Re: Bun support is now limited and deprecated

#131

Post by apalmer »

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…

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 production dependency on. If for sale of argument BUn was fully rewritten by hand would be the same situation. I personally think this kind of decision is pretty standard, I also personally think the Bun LLM rewrite will be of good quality overall, but I certainly would not bet my product/company on it. I want to be the one making the risky changes on my software not being forced into it by downstream deps.

Re: Bun support is now limited and deprecated

#133

Post by Shank »

raincole wrote: post #128
827a wrote: post #101

Earlier quoted context omitted.

FYI in case you aren't aware, the rewrite was shipped, and then had to be reverted due to issues being discovered. That's "Jarred's high quality bar" you're so confident in.

The whole point of having canary builds is that they're unstable. That's why they're called canary. Rockets failing in test flights isn't a bad thing.

> Rockets failing in test flights isn't a bad thing.

I hate to be pedantic but for a whole host of environmental reasons, they are suboptimal, and it still incinerates money to lose a rocket during a flight test.

Re: Bun support is now limited and deprecated

#134

Post by andai »

adamtaylor_13 wrote: post #80

We desperately need some new terminology to describe using LLMs to support development work. "Vibe code" has a strict definition but no one really cares. I have a really hard time believing that the Rust port was 100% "vibed" the way the original definition was laid out. It's a big slushy of emotions that I understand (both positive and negative) but it makes it so hard to actually tells what problem someone actually…

Vibe coding indeed originally meant "give in to the vibes [...] and forget that the code even exists."

https://x.com/karpathy/status/1886192184808149383

In the case of this specific port, the port was done so fast that it is clear humans did not verify the soundness of the translation. It is not clear whether this manual verification will ever occur.

That being said, most software projects were already doing "vibe coding" by Dijkstra's standards long before AI showed up. Going on vibes and forgetting that correctness even exists ;)

Guaranteeing the correctness of complex code is difficult, but it will increasingly become non-optional as we now have a billion hackers in a data center.

---

Edit: "Bun's unreleased Rust port has 13,365 unsafe blocks"

https://news.ycombinator.com/item?id=48239790

Re: Bun support is now limited and deprecated

#135

Post by cizezsy »

leobuskin wrote: post #100
cizezsy wrote: post #83

Earlier quoted context omitted.

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…

I agree with you that AI-written code should not be a problem and tons of open-source projects have AI-written code right now. But do you really believe the way Bun rewrites and merges its code to master is the same as before? The change in rhetoric (from "don't overreact, it's just an experiment" to "merge it anyway"), the never-arrived blog post promised to explain the decision are concerning to me.

I really appreciate the maintainers' effort towards this awesome project. However, I think it is fair to be a little bit less confident with the current state of Bun.

Re: Bun support is now limited and deprecated

#136

Post by nesarkvechnep »

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.

Re: Bun support is now limited and deprecated

#137

Post by raincole »

Shank wrote: post #133
raincole wrote: post #128

Earlier quoted context omitted.

The whole point of having canary builds is that they're unstable. That's why they're called canary. Rockets failing in test flights isn't a bad thing.

> Rockets failing in test flights isn't a bad thing. I hate to be pedantic but for a whole host of environmental reasons, they are suboptimal, and it still incinerates money to lose a rocket during a flight test.

Yes, building rockets costs money and is bad for environments.

Re: Bun support is now limited and deprecated

#138

Post by vor_ »

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.

In 7 days?

Re: Bun support is now limited and deprecated

#139

Post by johnfn »

apalmer wrote: post #131
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…

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.
Post reply on HN