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

411–420 of 646 posts

Re: Bun support is now limited and deprecated

#411

Post by elzbardico »

egorfine wrote: post #233
eddythompson80 wrote: post #144

Earlier quoted context omitted.

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.

Even a bad developer, that is, the average developer, develops a whole in which the parts have some degree of coherence. AIs simulate that, but they don’t have intent and thus this coherence is broken in large code bases.

Re: Bun support is now limited and deprecated

#412

Post by elzbardico »

solidasparagus wrote: post #396
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

They support Windows, which is many millions of lines of code not written by the current maintainers.

Windows have a incredible degree of architectural coherence and design intentionality.

It is far easier to understand some part of the various NT source code leaks than it is to understand Claude code leak

Re: Bun support is now limited and deprecated

#413

Post by antonvs »

smlavine wrote: post #6
antonvs wrote: post #3

Reason #2 is purely speculative. It’s disappointing to see technical decisions being made on such grounds.

All dependency management is speculative. You've got to hedge your bets that the dependency is reliable and fit for purpose. It is reasonable to view Bun's recent choices as increasing the risk associated with depending on it.

> All dependency management is speculative.

What a nonsense generalization.

In this case, the speculation ostensibly is that in future, there will be a release version of Bun that has is buggier or otherwise lower quality than the current stable version.

There's literally no basis for believing that. The actual basis is "I don't like how they're approaching the development of their next version."

If that's a valid basis for "dependency management", then using a Ouija board would be just as valid.

Re: Bun support is now limited and deprecated

#414

Post by 48terry »

pizlonator wrote: post #245

I can’t help but read the logic as not being too far off from: “libfoo switched to being developed using emacs instead of vim so we can’t trust it anymore” It’s not the same obviously, but here’s why I can’t help but view it analogously: The only truth in software is whether it works or not for whatever your use case is. Even before AI, we couldn’t have known if the author of a piece of software was proceeding with r…

I don't know how to tell you this, but people actually can and do, in fact, worry about the methods things come to be made with, and make decisions based on if they approve of that process or not. Otherwise the idea of free trade chocolate/coffee/other shit would not exist.

Re: Bun support is now limited and deprecated

#415

Post by LelouBil »

I don't know how to feel about the Bun rewrite.

On one hand, it seems very scary to me, having most of your codebase unreviewed.

On the other hand, it passes their tests with few regressions from what I heard.

Maybe it's just because I don't have enough experience there, but I wouldn't trust my tests to this degree and completely rely on them without reading the code.

Re: Bun support is now limited and deprecated

#416

Post by solidasparagus »

phire wrote: post #401
solidasparagus wrote: post #396

Earlier quoted context omitted.

They support Windows, which is many millions of lines of code not written by the current maintainers.

It's a bit harder to avoid windows than it is to avoid Bun. More importantly, it's not the same thing at all. All the code in windows (at least until recently) was written by humans, understood by humans and reviewed by humans. And that code has stood the test of time, proven its value and stability in the wild, on billions of systems. The fact that the current maintainers haven't needed to understand or replace the…

That's a valid way to approach this - bun isn't valuable enough to bother with or at least wait for a while, Windows is.

But I think the comparison is closer than you are making it sound. I sincerely doubt the Windows codebase was all written by humans, let alone reviewed. And my understanding is that the code is being regularly rewritten and replaced because of how flawed it is, it's just a massive undertaking.

Also if you look at their investment in AI-driven code rewriting into Rust, my bet would be that some modern Windows code itself is being vibe-coded.

Re: Bun support is now limited and deprecated

#417

Post by antonvs »

happytoexplain wrote: post #10
antonvs wrote: post #3

Reason #2 is purely speculative. It’s disappointing to see technical decisions being made on such grounds.

It's a common fallacy among tech folks to believe that every decision can be made from 100% deterministic grounds ("X decision will result in Y percent change"). In reality, successful decision-making often involves speculation. The speculation in question is within the bounds of reason. You may disagree , but the fact that it is speculative isn't the problem.

> The speculation in question is within the bounds of reason. Y

I disagree. It seems to be an emotional reaction borne of ignorance and uncharitable assumptions. There's no "reason" involved.

Re: Bun support is now limited and deprecated

#419

Post by [deleted] »

elzbardico wrote: post #412
solidasparagus wrote: post #396

Earlier quoted context omitted.

They support Windows, which is many millions of lines of code not written by the current maintainers.

Windows have a incredible degree of architectural coherence and design intentionality. It is far easier to understand some part of the various NT source code leaks than it is to understand Claude code leak

[deleted]

Re: Bun support is now limited and deprecated

#420

Post by skywhopper »

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…

“Vibe coded” means “human programmers did not review the code”. So I think that’s an entirely reasonable line to draw that’s no more political than dropping support for some other project that suddenly decided to drop all unit testing or to refuse to do any security vetting.
Post reply on HN