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

621–630 of 646 posts

Re: Bun support is now limited and deprecated

#621

Post by stuaxo »

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…

Heh, that would include the tests where the content is just replaced with a single sleep.

Re: Bun support is now limited and deprecated

#622

Post by stuaxo »

josephg wrote: post #403
ChoGGi wrote: post #328

Earlier quoted context omitted.

I assume most of the complaints about the massive rewrite are in regards to AI, not Rust. As lots of large and small companies have shown, test suites can only find what you test for. Vibe coded test suites can find?

On the whole, I think vibe coded test suites can be pretty good. But it really depends on how you prompt. I often get the AI to brainstorm needed tests into a text file while it works. Then later I get another agent to write tests based on the list. It does a reasonable job. Its also pretty good at writing regression tests when it fixes a bug. Where LLMs struggle - or at least where claude struggles - is fixing the a…

Disagree: I've played with vibe coding, and the tests are worse quality than the code, which makes sense and that's how real world tests tend to trend.

Re: Bun support is now limited and deprecated

#623

Post by adampunk »

kibwen wrote: post #560
cybercatgurrl wrote: post #530

Earlier quoted context omitted.

insult people you disagree with. smart approach

To merely disagree with someone first requires one to acknowledge the legitimacy of their capacity for logical reasoning. Rather, what I'm doing here is outright dismissing someone who isn't worth disagreeing with. There is no law of the universe that says that I am morally obliged to waste my energy taking seriously the arguments of fools.

Oh in that case insulting people is a smart response…

C’mon, pal.

Re: Bun support is now limited and deprecated

#624

Post by szmarczak »

elzbardico wrote: post #418

Most developers can’t see AI slop because their level of competence is actually below what an AI can produce. Technical debt was a reality before vibe coding. Someone was writing all that trash by hand.

I got banned from yt-dlp for stating that Deno is vibe coded and that AIs are responsible for 54% commits since Feb 01. Also see https://news.ycombinator.com/item?id=48241873

> Someone was writing all that trash by hand.

And reading code written by AI isn't the same as reading code written by a real expert person.

There still exists the difference of quality of the written code and people who use AIs are lazy enough to accept code with vulnerabilities - see https://news.ycombinator.com/item?id=45034496

Re: Bun support is now limited and deprecated

#625

Post by atonse »

allthetime wrote: post #390
atonse wrote: post #269

Earlier quoted context omitted.

You can go read all the details on Jarred's X account - including the progress, how it was thought out, strategy, that they're aware that it looks like zig still, etc etc etc. Speaking of environment though, everyone neglects to mention that the Bun core team now has access to Claude Mythos. You think they haven't already run Mythos against this? So they have private access to the best cybersecurity scanner known to…

jarred two weeks ago: "we're probably not going to merge any of this" jarred a few days ago: "bun has been rewritten in rust" thought out?

You've never changed your mind once you got new information?

Re: Bun support is now limited and deprecated

#626

Post by atonse »

kelnos wrote: post #385
atonse wrote: post #234

Earlier quoted context omitted.

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

> YOLO? Bun has an extensive test suite and this implementation passed the test suite. I'm sure macOS has an extensive test suite that Apple runs as well, and yet still people suggest waiting a bit before adopting a new macOS release. An extensive test suite can prove that you have regressions when you change the code, by showing you one or more newly-failing tests. However, it cannot prove that you don't have any re…

My argument wasn't that the test suite was perfect, my argument was that this is far from "YOLO" - this is a textbook example of being able to do bigger refactors, etc when you have an extensive test suite.

Re: Bun support is now limited and deprecated

#627

Post by jeltz »

827a wrote: post #593
justinhj wrote: post #582

Earlier quoted context omitted.

I was thinking along similar lines today. An AI assisted audit of the issues that caused segfaults could find and implement safe memory management patterns in Zig. It sounds like the Rust port process essentially has had to do this anyway when it analyzed all of the places unsafe is needed and started mitigating some of them. The project also sounds like it has unique memory management problems in its nature: native…

Zig has a "Zero AI" policy. Bun has had to maintain an internal fork of Zig with various AI-assisted fixes that have resulted in real performance and stability gains for the runtime. Its, arguably, a decent reason to decouple from Zig. The challenge is: They already were decoupled. They've forked Zig. If your desire is to make a bet on generated code and reasoning as the entire future of software development, as Jarr…

I looked at one thing the bun developers wanted to fix in Zig and the issue with it was a bad idea which would not have been merged even if it had been written by a human.

Re: Bun support is now limited and deprecated

#628

Post by truncate »

atonse wrote: post #625
allthetime wrote: post #390

Earlier quoted context omitted.

jarred two weeks ago: "we're probably not going to merge any of this" jarred a few days ago: "bun has been rewritten in rust" thought out?

You've never changed your mind once you got new information?

By that logic, most politicians making election promises didn’t lie or under delivered. They just changed their minds.

Re: Bun support is now limited and deprecated

#629

Post by simongr3dal »

Rexxar wrote: post #545
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 ?

THey need to provide all the API's that nodeJS provides. I'm sure nodejs has a lot of lines too even though they also have the js engine as a library.

Re: Bun support is now limited and deprecated

#630

Post by autumnstwilight »

josephcsible wrote: post #430
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…

> It’s all the same just different syntax. That reminds me of Chris Reigrut's story from https://thedailywtf.com/articles/Holiday_Smorgasbord

>>> //How did this happen??

>>> log.fatal("Aaaaarrrgghhhh");

Reminds me of working at a small Japanese company and someone had written a try-catch for retrieving a crucial bit of config that just logged "X missing. This is disuster." and terminated.

Post reply on HN