Live data from Hacker News

Bun support is now limited and deprecated

github.com

581–590 of 646 posts

Re: Bun support is now limited and deprecated

#581

Earlier quoted context omitted.

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.

Nobody can say that about Microsoft's rewrite of Typescript into Go (which was not done in a week with AI). That's an unrealistically high bar.

Presumably, in any sane process, changes would be split into small, reviewable PRs with people reasoning about the code. That wouldn't eliminate the possibility of bugs, but when done correctly it would give us substantially higher confidence that semantic equivalence is preserved.

With zero reviews and no one even reading the code, there's zero confidence. For all we know, the new Bun could contain a change that causes JS file reads to return a novel for a very specific filename, and the tests people keep pointing to, intended to downplay the malpractice, would never catch it. Tests cannot cover every contrived scenario that normal human beings would never think of writing.

Re: Bun support is now limited and deprecated

#582
post #92

Earlier quoted context omitted.

Its possible to do that over a period of a few years. Sadly, the Rust rewrite happened in (checks notes) 8 days.

So this question was never answered: If Zig had so may problems that they felt compelled to rewrite it all in Rust, does that suggest the great Mythos was unable to fix the Zig version? Isn't this suppose to be the most advanced model ever and you're telling me they can't just schedule a cron job that detects and repairs the zig version? Really? Did they just completely admit that the great AI future can't secure a s…

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 code calling js code which calls native code and trying to manage lifetimes amongst that.

Re: Bun support is now limited and deprecated

#583
This makes a lot of sense.

I don't use Bun, but we (and many others) depend heavily on numpy. It's been around for decades and heavily battle tested. If someone came out with a new version of numpy vibe-code rewritten in a week, with assurances that "all tests pass", do you think we would adopt it? Absolutely not. We would have no confidence that there aren't some latent bugs or that we can fully trust the results.

It has nothing to do with AI having rewritten it, it has to do with being battle tested over time. If a team of humans had rewritten it in a week, I wouldn't trust or use it either. Maybe after a year of it being widely adopted. Not before.

Re: Bun support is now limited and deprecated

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

I have the opposite experience. The library I develop depends significantly on external behavior, so point an AI at it and it will come up with tests like "test if a string is NULL" (even though I annotated it to be nonnull/a null-terminated string argument, but LLMs love ignoring my compiler annotations unless I tell them otherwise). So the "tests" end up being nonsensical ones like "test this range linear piecewise transformation; if you pass in x and round-trip it does it come back out as x?".

Re: Bun support is now limited and deprecated

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

That was a snarky question, but I appreciate knowing where AI is when it comes to test suites. Let it write them, babysit the crap outta them when it comes to passing.

Re: Bun support is now limited and deprecated

#587
post #547

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

The other is pure complexity. We can reasonably trust the Zig implementation because it had a lot of talented people working on it. But then they threw it out and rewrote it in Rust, and it's like okay a huge number of tests pass but:

1. Are we positive the AI didn't cheat when getting some or most of them to pass? Are we sure it didn't just cheat on even 1 percent of them?

2. Are we positive that the AI didn't introduce bugs that the tests didn't think about because there was no need to think about that before (because actual people understood the code)? And therefore, those things go untested, and nobody can write good competent tests for them because nobody understands the code in the first place.

Re: Bun support is now limited and deprecated

#588
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

How much of the windows code has been written by its current maintainers? Little. I feel this argument is not valid, especially for large code bases. Documentation and code quality is what is important, not who wrote the code.

A project that's 2/5/10/30/100m LoC is obviously not going to be understandable entirely in someone's head. Documentation is critical. But if I'm reading your code, and I come across something confusing or you wrote something in a weird way and I want to understand, then I just... Come and ask you. "Hey, why did you do this this way? Did you consider x?" With an AI you can't do that. IMO this point is especially important if your code base is widely deployed to the point that people use it as a learning resource or a good source to learn good practices.

Re: Bun support is now limited and deprecated

#589

Earlier quoted context omitted.

>that's just an experiment that has no chance of being merged Yeah he never said that.

Here is him saying that in words that could be interpreted as ‘this is just an experiment’: https://news.ycombinator.com/item?id=48019226

Right he said it was an experiment. Nowhere did he say there was no chance of it being merged. Do people not understand what an experiment is?

Re: Bun support is now limited and deprecated

#590

Earlier quoted context omitted.

>that's just an experiment that has no chance of being merged Yeah he never said that.

> This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely. https://news.ycombinator.com/item?id=48019226

Is your reading comprehension poor? Where in that does it say it had no chance of being merged? Do you understand what an experiment and what the purpose of an experiment is ?
Post reply on HN