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

541–550 of 646 posts

Re: Bun support is now limited and deprecated

#541

Post by jbs789 »

merlindru wrote: post #518
zarzavat wrote: post #391

Earlier quoted context omitted.

What is the essence of a program? The name? No. The author? No. The test suite? No, testing is hard and most projects don't do enough of it. The code? Not really, code can be rewritten. The history of the program being executed by its users? Ding ding ding. Yes, it's this one. Bun no longer exists. What exists now is a program that has the potential to be Bun but at this time is not Bun because it has no history of b…

i highly disagree with that framing. the essence of a program is not the fact that people have been running it you could write a great program and never run it. does that mean the program does now not exist? or that it is not a new, unique thing? if anything, the essence of a program is made up by all of the things you mentioned!

The confidence and trust accumulated by the users is paramount. I think that’s what we are talking about here.

Re: Bun support is now limited and deprecated

#542

Post by soraminazuki »

usef- wrote: post #454
aragilar wrote: post #451

Earlier quoted context omitted.

It's "we support 4 JS backends, we don't have the capacity to support 5 currently". They're not dropping bun entirely, instead bumping the minimum bun version and not supporting "bunv2" because they don't want to be beta testers.

Has the team announced that they're breaking backwards compatibility, or that testing will be reduced?

No, the team mislead people by claiming the rewrite was experimental only to merge 1M lines of unreviewed code merely days later. Responsible software developers don't operate on blind trust, and both the Bun code and the maintainers are highly unpredictable at this point. That's more than sufficient technical grounds to drop an optional and replaceable dependency, especially since there are no user-facing consequences beyond the bruised egos of a cult following that demands blind loyalty to its tech‑bro leaders.

Re: Bun support is now limited and deprecated

#543

Post by crowcroft »

manquer wrote: post #368
crowcroft wrote: post #343

Earlier quoted context omitted.

This is why I require all my software to have bespoke compilers otherwise how can I trust the devs know what their code is actually running!?

Just because we don't understand or know about compilers or able to read their output does not make them fungible. In old days we chose between Turbo/Borland C, Quick C and GCC. We didn't think them same or trust blindly even if we didn't know how they worked. The best developers hand optimized assembly for sub routines which they knew compilers were not good at, the rest of us sure didn't understand how any of it wo…

Part of what I’m getting at is exactly your point that we used to think about what compiler to use and didn’t always blindly trust them.

If you have enough tests at what point does AI rewriting software in a different language become close enough to ‘deterministic’? Maybe never, maybe not.

Re: Bun support is now limited and deprecated

#544

Post by vitally3643 »

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

Completely regardless of how the code was written or even if anyone understands it thoroughly, they replaced the entire running codebase in a week. The entire project was one thing and is now something different.

There are countless reasons that this is a very bad thing for consumers of Bun. First and foremost you've instantly lost any and all assurance that it works the way it's supposed to. Every project has load-bearing bugs that may or may not still exist. Can you trust the core behavior is the same?

If the Bun maintainers are willing to completely replace their core product over the span of a week, how is anyone supposed to rely on it? What's preventing another rewrite in a few more weeks?

If you want to position your product as a dependency, it needs to be stable and reliable. Throwing away a million lines of code and replacing the entire product overnight is pretty much the polar opposite of stable and reliable.

It has nothing to do with AI rewriting the code, it's the reckless abandon and wild disregard for consumers that is the problem. It's literally a rug pull.

Re: Bun support is now limited and deprecated

#545

Post by Rexxar »

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 don't use Node.js or Bun, so I'm little out of touch. But what need 1 millions lines of code as the js engine itself is a library ?

Re: Bun support is now limited and deprecated

#546

Post by gibber878 »

KingMob wrote: post #540
wiseowise wrote: post #489

Earlier quoted context omitted.

Anyone who isn’t supporting using runtime rewritten by an LLM is obviously “doesn’t get it” and a luddite.

But in this case, the yt-dlp maintainers didn't actually evaluate the rewrite yet, they just declared they wouldn't support it, sight unseen. Not really an argument on its merits.

[flagged]

Re: Bun support is now limited and deprecated

#547

Post by kreco »

sroussey wrote: post #61
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 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…

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

What if there was some malicious code within the 1 million lines?

Re: Bun support is now limited and deprecated

#548

Post by OtomotO »

kreco wrote: post #547
sroussey wrote: post #61

Earlier quoted context omitted.

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…

> 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. What if there was some malicious code within the 1 million lines?

What if there was some malicious code within the 1 million previous lines?

The problem is trust... About nobody has the time and the resources to read 1 million lines of code, keep everything in their head and derive whether there are problems...

Re: Bun support is now limited and deprecated

#549

Post by skydhash »

lelanthran wrote: post #493
giancarlostoro wrote: post #327

Earlier quoted context omitted.

I'm very skeptic that they read the entire codebase of Bun prior.

> I'm very skeptic that they read the entire codebase of Bun prior. Well, they didn't really need to. A complete rewrite is effectively a different project. You may feel comfortable using a new project in prod, but most people are not. Project A: used in production for 3 years - high trust. Project B: Has yet to be used in production - low trust. IDGAF about automated tests, let other users shake out the inevitable b…

People that like AI are always happy to point out that their code was written fast and passes tests. For me thats just the bare requirement to have more than a “wip” commit on my local codebase.

To create a PR, I need to test it manually. But the only true test is to survive production usage for a while. That’s where edge cases become normal occurrences.

Re: Bun support is now limited and deprecated

#550

Post by wiseowise »

KingMob wrote: post #540
wiseowise wrote: post #489

Earlier quoted context omitted.

Anyone who isn’t supporting using runtime rewritten by an LLM is obviously “doesn’t get it” and a luddite.

But in this case, the yt-dlp maintainers didn't actually evaluate the rewrite yet, they just declared they wouldn't support it, sight unseen. Not really an argument on its merits.

OSS is not a testing ground for rewrites made by hyperscalers. Bun is free to fork yt-dlp and prove it is stable enough.
Post reply on HN