Live data from Hacker News

Bun support is now limited and deprecated

github.com

401–410 of 646 posts

Re: Bun support is now limited and deprecated

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

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 code is some indication of the code's quality.

Almost none of Bun's rust code has been even seen by a human, and it's only about two weeks old.

I'm somewhat willing to accept vibe-coded code if it's either absolutely non-critical, well reviewed, or maybe in the long term if it's proven itself. But not two week old code.

Re: Bun support is now limited and deprecated

#402
post #234
post #223

Earlier quoted context omitted.

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

Program testing can be used to show the presence of bugs, but never to show their absence! Dijkstra (1970) "Notes On Structured Programming"

LLM generated code is garbage, not because it writes obvious errors. But because it lacks any kind of reasoning - Claude will gladly write you a solution for a problem you never had. Good luck fixing these kind of issues that will never be catched by tests.

Re: Bun support is now limited and deprecated

#403
post #328

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 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 actual bugs. Its very good at getting the test suite to pass. But it cheats. It'll sometimes disable a test, or do some hacky workaround that makes the test pass that doesn't fix the underlying issue. It'll say "All done, the tests pass". But sometimes you really wish they didn't.

I'm wondering if it might be better to set up 2 agents adversarially for bug hunting. Give one agent the goal of finding as many bugs as possible (via tests and other techniques). And another agent has the goal of fixing the bugs.

Re: Bun support is now limited and deprecated

#404

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

That doesn't change anything. No one can say with confidence, backed by proof, that the 1M slop is semantically equivalent to the old code. The code is a black box without that guarantee.

Re: Bun support is now limited and deprecated

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

I would argue the opposite. The decision to rewrite was based on politics, and the decision to deprecate support was based on actual engineering.

Re: Bun support is now limited and deprecated

#406

It’s not like they are discriminating on someone’s race or religion. If they don’t want a major vibe coded surface, do they even have to defend that? It’s part their “artistic” license as developers. Or did we forget software inherently is opinionated

Yes, it’s actually similar to discriminating based on race or religion, in the sense that it’s an arbitrary, meaningless criterion to discriminate on. If the Rust Bun port is better in every measurable way — passes all tests, has the same performance or better, and fixes existing bugs — then who cares what language it’s written in or how it was implemented? The point is that it’s higher quality. If you don’t trust the Bun team when they release a Rust version and give it their stamp of approval, why did you trust them when they released the Zig version two weeks ago? It makes no logical sense, and it makes the yt-dlp devs look foolish.

Re: Bun support is now limited and deprecated

#407
post #369

Earlier quoted context omitted.

Bun in its current state absolutely has issues like segfaults. As nice as it is, I moved off of it back to node for production. Folks generally tolerate issues if they believe they’ll get better with time. I know I did for a while. If that confidence collapses, that’s not politics.

But there's no evidence of that in the post. If they had said something like "Bun had bugs X, Y and Z - this Rust thing is the last straw, it's over" -- that would be a reasonable decision, and no one could really complain. But they didn't say that. They just said it "seems like a future headache".

Are we reading the same post? They literally point to bugs X and Y.

I don't see politics, I see frustrated maintainers of a hobby project that aren't particularly professional.

Re: Bun support is now limited and deprecated

#408
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'm very skeptic that they read the entire codebase of Bun prior.

yeah this just feels like an attention stunt tbh

Re: Bun support is now limited and deprecated

#409

Earlier quoted context omitted.

[flagged]

> in many aspects of human history, we have traded understanding for convenience—that's the reason why we buy food at the supermarket instead of hunting for our meal. You could always take a job on a cattle ranch or an abattoir or meat-packing plant, or watch a How It's Made documentary, and get some understanding of how the sausage gets made and put on the supermarket shelf for your convenience. This was also true a…

The limitations are far overstated. Who cares if you don't understand every bit but the LLM does? Is the LLM good enough to ship to prod? Great.

Understanding every corner of your codebase is overrated. LLMs, properly harnessed, are good enough.

Re: Bun support is now limited and deprecated

#410
post #381

Earlier quoted context omitted.

You might not like it but you actually live in a world with other people and building technology often affects their lives and they have opinions on it. For AI a lot of that impact has been negative.

I don't have the emotional energy to care, actually. This is actually fascinating. How does my opinion matter? Should I join all the socials (this is my only form of social media) and stand on my soapbox and shout into the void? Do I need to express I care so others know I care and have picked a side and have opionions on evrything? I do not care. My opinion does not matter. I can scream into all the voids. I can vir…

Engineers not caring is what leads to people working for scumbags who build socially poisonous technology.
Post reply on HN