I think this HN submission provides little value and a lot more headache to the maintainers of FOSS project (you can already see a lot of brigading in the GitHub comments). IMHO HN shouldn’t allow submissions like this.
Bun support is now limited and deprecated
441–450 of 646 posts
Re: Bun support is now limited and deprecated
#442Oh well, I really like using Bun and I get kinda sad about the turn they are taking after the Anthropic acquisition. I really want a good Node with batteries included, but I don't want it vibe coded.
Why dont you want it vibe coded? Does that make it worse?
Not necessarily, but I don't trust Anthropic in making sure it doesn't become worse. They are already doing a terrible job with their own Claude Code CLI.
Re: Bun support is now limited and deprecated
#443Earlier quoted context omitted.
I had an actual look at the code, and because it's a translation it's not just straight up de novo slop. The bits I saw were fairly straightforward 1:1 translations, so the Bun developers should still be familiar with the overall structure and logic. I still think it's mad, but not quite as mad as you might first think from the headlines.
It's the little bits that aren't 1:1 Who wants to review a brand new codebase for free?
Why is it for free? Isn’t Anthropic paying their salaries?
Re: Bun support is now limited and deprecated
#444Re: Bun support is now limited and deprecated
#445Earlier quoted context omitted.
It's not impossible, or even that hard to review the entire rewritten codebase. 10 engineers each reviewing 5,000 LoC a day for 20 days can do it. And that is being highly conservative with the estimate. A good chunk of the the code is probably highly trivial boilerplate one can easily skim over in minutes.
And five engineers reviewing 20 thousand LoCs would get the job done in ten days, but both numbers are just as BS when it comes to actually understanding the codebase. No one is comprehensively reading 5k lines per day for a month straight.
Seriously, “just review 5k lines a day for a month” is the most out of touch manager suggestion I’ve seen in a hot minute. As though you only need to read each line one single time in a review before magically committing its exact purpose, content, and overall implications to memory. The absurdity of which is multiplied for AI generated code which, based on what I see from my coworkers, is clunkier and weirder and less focused even than regular human code, on average.
Re: Bun support is now limited and deprecated
#446I 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
So it was possible to write ~2 million lines of (mostly) zig, but it's not possible to review ~1 million lines of rust, even though the same test suite included in those 2 million lines of zig can still be used? I'm not convinced the rewrite is a good idea and will work out, but I'm equally unconvinced by your argument.
[deleted]
Re: Bun support is now limited and deprecated
#447Earlier 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
> Support : I'm telling you, nothing changed!!! The only difference between the old version and the new version is that the old version was in COBOL, and the new one is in C!!!
Thanks for the chuckles!
Re: Bun support is now limited and deprecated
#448Earlier quoted context omitted.
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…
I mean should we even compare Bun to Windows in the first place? Like Mircosoft with its resources would find a way to support Bun and Windows is one of their most popular and most used products. The situation with Bun is very different in terms of business/product.
Re: Bun support is now limited and deprecated
#449Earlier quoted context omitted.
They did not write the rust code. AI wrote that code. Your response is side stepping the primary issue people have with the rewrite: no human has read and understood all the code AI wrote.
I agree but would propose the weaker argument: no set of human contributors have, put together, read and understood all the code. Even in artisanal-coded projects of sufficient size, it's rare that any one human has read and understood all of it.
"No human understands any of the code" is not the same as "no human understands the entirety of codebase fully". Very different situations.
Re: Bun support is now limited and deprecated
#450Earlier quoted context omitted.
I can't see how this counts as "political" or "ideological" by your definition unless you believe that emotion can't exist as part of any decision, in which case you should give up interacting with human beings entirely. Regardless, the decision was 99% logical. In fact, even the emotional parts are laudable. For example, I love software. That's an emotion. If you disagree with that foundation, we will fundamentally…
The opposite of political would be someone saying "I have observed that Bun has X, Y and Z bugs -- therefore we are no longer support it". An example of this is the recent announcement that Ghostty is leaving GitHub[1]. Compare and contrast the rationale: > I've felt this way for a long time, but for the past month I've kept a journal where I put an "X" next to every date where a GitHub outage has negatively impacted…
But unless you're doing that for every service you use (and not just the ones that annoy you), that's still the same logic. Deciding to count something is just as "political" (as you put it) as choosing to not count something.