Live data from Hacker News

Bun support is now limited and deprecated

github.com

231–240 of 646 posts

Re: Bun support is now limited and deprecated

#231
post #154

Earlier quoted context omitted.

> This decision seems to based more in politics than engineering. You are 100% right. This is a decision made on VIBES and not evidence. The proof is here: > Bun was recently rewritten in Rust using Claude, and its development seems to have taken a turn towards being fully vibe-coded. This is alarming and disappointing for a number of reasons, and frankly it seems like a future headache that we'd prefer to avoid. The…

So a vibed decision to reject vibed code. Minus minus equals plus?

I think you should read what the bun devs published about their process. It's not just vibed.

Re: Bun support is now limited and deprecated

#232
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 don’t think changing from zig to rust suddenly means that don’t know what a certain file contains or how it works or how it relates to other files. It’s all the same just different syntax. Which, by the way, is why it looks ugly to rust developers. The devs wanted the code to look familiar to them. I do think they should have called this 2.0 though. Would not feel such a rush (1.3.14 has a few regressions, and no o…

> Image routines my heart sank. Another shiny object

With quite a peculiar set of supported formats different between operating systems.

Re: Bun support is now limited and deprecated

#233
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

Pretty normal in many corporate cultures especially ones with high turnover. You get assigned to a team that's "maintaining" a 10 year old code base with few million LoC. The most senior person on the team has been there for a year or 2 and it's just business as usual. You don't know what those 1M+ lines are doing. No one does. It's not a passion of anyone to work on it. You just get a bunch of requirements handed to…

Human-written code is theoretically surmountable.

Large LLM-written code is called slop for a reason. It's hard to understand because oftentimes it does not follow human logic.

Re: Bun support is now limited and deprecated

#234
post #223
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…

Every single macOS update the top comments are about giving it six months to stabilize, but when a program’s biggest ever rewrite involves a lot of AI, the top comment is calling you irrational if you don’t YOLO it, and probably a jerk, too.

YOLO? Bun has an extensive test suite and this implementation passed the test suite.

Can we at least try to be a bit more accurate and less hyperbolic?

I will continue to use Bun because the same people that made bun have made this decision. I trusted them one week ago. I have used bun for the past 2 years, and so have many others.

I'm not about to just assume they've become immature idiots yolo'ing stuff overnight. They're still the same people they were a week ago. Or two weeks ago.

Re: Bun support is now limited and deprecated

#235

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…

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.

Those studies have well known flaws. I'm measuring my output so I happen to know I'm not only going faster, but the quality is better.

I'm not vibe-measuring my output ;)

Re: Bun support is now limited and deprecated

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

1 million lines of code written and approved, in 9 days proves without reasonable doubt it was vibe coded.

Re: Bun support is now limited and deprecated

#237
post #92

Earlier quoted context omitted.

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

So this question was never answered: If Zig had so may problems that they felt compelled to rewrite it all in Rust, does that suggest the great Mythos was unable to fix the Zig version? Isn't this suppose to be the most advanced model ever and you're telling me they can't just schedule a cron job that detects and repairs the zig version? Really? Did they just completely admit that the great AI future can't secure a s…

https://duckduckgo.com/?ia=web&q=bun+fork+of+zig+compiler

Re: Bun support is now limited and deprecated

#238
post #75

This is about the rust conversion but that has not been released. > Due to foreseeable compatibility and security issues Hmm, Zig bun crashes plenty. I wish yt-dlp linked to detail on why there are foreseeable compatibility issues. Both projects have test suites, in an ideal world they would allow fast rewrites. Maybe they want to limit inflaming the situation, but if they have spotted some specific issues it would b…

Yep, it's one thing if there was some project that saw severe regressions in Bun.rs and actually showed data about regressions.

But it's been available for a week. And so far, seems like crickets on actual data on any regressions. It's more "I just don't like this!" style grumbling.

Re: Bun support is now limited and deprecated

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

Even re-written by hand isn't the same because a hand re-write proceeds slower over a longer period of time with more smaller updates that get tested somewhat along the way.

Also I don't think it's wrong to use an action as an input to judging engineering character. That could be read as judging yt-dlp or judging bun but in this case I mean it's reasonable to judge bun's developers.

IDK if i'd personally judge this action quite so badly though. It depends how they went about it and what they proffessed to get out of it.

I am very much against letting llms think and decide for you, but I don't think it's so wrong for an actual coder to employ automation.

But if they are acting like it's magic and everything will be so much better after the magic llm uses the magic safe language... yeah that definitely gets the side eye. Or no eye. Just no longer interested in or concerned with their output.

Since this is being offered as the next release version while still being new and stuffed with unsafe, looks like it's the latter. So I'm with yt-dlp in this case.

It doesn't matter if the new code happens to be ok or not, it's still a problem that they got there by hoping a black box does the right thing. A black box that that no one wrote and no one understands, not just themselves.

gcc is a black box to me, but I know that someone wrote it and understands it (or some people collectively understand all it's parts), and I know that any time I want, I can choose to understand any part of it, and satisfy myself that it is doing something both sane and deterministic.

So a developer choosing to use gcc when it's a black box to them does not reflect badly on them to me.

But no one can say that about any llm or ai. So yeah, a developer choosing to use them, depending on exactly how, may reflect badly on them.

The same was true for cheap off-shore gig coding by humans too. I have tried to use them myself in the past, hire out for small generic programming jobs using those web sites where you put up some escrow money and post a job and people bid for it, you choose one, they do it and get paid from the escrow. I only tried about 3 times for the same small job and every time I git ridiculously shit (but technically functional) results.

These were humans 15-20 years ago, no possibility of hidden ai usage like today, and it's essentially the same dynamic of just hoping some magic will get you something good for cheap, and accepting any result that appears good as good.

If someone said that that's how they made their product, I would decide that product is probably pretty crap inside and no way should I buy it or invest in it as a dependency if I have any choice.

And that's humans not ai. The problem isn't really the ai, it's the judgement to use an ai that way.

Re: Bun support is now limited and deprecated

#240

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…

[dead]
Post reply on HN