Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rewriting Bun in Rust

bun.com

Post reply on HN
Print view View original

451–460 of 560 posts

Re: Rewriting Bun in Rust

#451

Post by jgalt212 »

pier25 wrote: post #140

Personally I don't care that they used AI to rewrite Bun to Rust. Even if 1.4 is not good enough it will probably get better over time. What has pushed me back to Node is seeing how amateurish the transition has been handled. - No LTS support for the Zig version regarding CVEs etc. - Huge bugs like the 3MB memory leak mentioned in the blog post abandoned in the Zig version to basically force people into the Rust vers…

> One day it was "stop the drama I'm just playing with this" and a couple of days later "yolo merged to main".

Yeah, that was beyond ridiculous.

Re: Rewriting Bun in Rust

#452

Post by OGWhales »

karatchov wrote: post #413
solid_fuel wrote: post #205

Earlier quoted context omitted.

Ehh, I think this take needs a grain of salt. There's a few significant facts here: - They had an existing functional Zig implementation - They had an existing test suite for the Zip implementation - They had a separate JavaScript compliance test suite with ~ 1 million tests - The person overseeing the rewrite was responsible for a huge portion of the existing codebase and was very familiar with the existing architec…

You are missing the big picture here The AI literally was able to do a year's work of a top notch developer team in just 11 days (mainly because of a lot of human intervention, otherwise it would have been faster) Why do you think its cant or wont be able to replace the lead developer and/or designer's 11 day job ! and btw, if it can write code, it can write tests and test suite Ai has come a long way, 2 years ago, t…

> You are missing the big picture here The AI literally was able to do a year's work of a top notch developer team in just 11 days (mainly because of a lot of human intervention, otherwise it would have been faster) Why do you think its cant or wont be able to replace the lead developer and/or designer's 11 day job !

It would help if you actually engaged at all with any of the points they just made. They were good points!

Re: Rewriting Bun in Rust

#453

Post by Ygg2 »

darkwater wrote: post #441
Ygg2 wrote: post #438

Earlier quoted context omitted.

> AI is an inherently anti-social, anti-human technology, and this rewrite is the perfect example of that. Not really. LLMs are a tool, and they do possess some interesting properties, but they are, in essence, a very surprising auto-complete. No, what sucks is the AI companies marketing them as if they are The Holy Grail. And people are assuming that somehow LLM -> AGI -> ASI, even though there isn't really a causal…

If you think like this - and you are most probably right IMO as well - then you should somehow share GP feelings, because LLMs are made by companies like OpenAI and Anthropic and Bun was bought by Anthropic and ported to Rust by Anthropic. TBH in hindsight it seems that the Bun acquisition was also for the PR stunt they just did with the Rust porting.

I don't because I think the GP is blaming the tech, not the actual culprit - a bit like blaming the invention of fridges for people hiding the body. LLMs can be made and hosted independently of OpenAI and Anthropic.

> TBH in hindsight it seems that the Bun acquisition was also for the PR stunt they just did with the Rust porting.

The events went roughly like this:

- Anthropic used Bun. So they acquired it.

- Bun made some LLM derived patches for Zig. They were rejected due to Zig no-LLM stance.

- Bun couldn't get patches in, so they switched to Rust.

Was it a PR stunt, an attempt to pressure Zig maintainers into changing AI stance, or just doing the fastest thing possible? It's difficult to tell. I'm inclined to believe the last option.

As easy as it is to blame Bun for a PR stunt, it's also possible that you can't really associate with someone who rallies against your employer/owner.

Re: Rewriting Bun in Rust

#454

Post by srdjanr »

nicce wrote: post #310
pier25 wrote: post #140

Personally I don't care that they used AI to rewrite Bun to Rust. Even if 1.4 is not good enough it will probably get better over time. What has pushed me back to Node is seeing how amateurish the transition has been handled. - No LTS support for the Zig version regarding CVEs etc. - Huge bugs like the 3MB memory leak mentioned in the blog post abandoned in the Zig version to basically force people into the Rust vers…

> - No LTS support for the Zig version regarding CVEs etc. Every release would have tons of CVEs and would take so much effort. E.g. the example from blog with memory issues. Better just think that Zig version was not there what comes to security. Use at your own risk. > Jarred basically keeps operating as if he was a lone hacker working on his personal project. They have right to do it, however. It is expected, espe…

Of course he has the right to do it, no one disputes that. The users and community also have the right to complain, or stop using and supporting Bun because they don't like his actions

Re: Rewriting Bun in Rust

#455

Post by bluGill »

padjo wrote: post #421

It's very odd how quickly people fall back on emotional claims to attack this. Like we're engineers, if you can point at concrete problems with this rewrite I'd love to hear them. Obviously Jared is going to give the positive case, saying that he's doing that doesn't prove the rewrite is a bad idea. You need to point at objective problems, not your vague sense of unease. As it stands, by all available measures, this…

We also need to ask if the better is because of Rust, or just because the old was a mess and the language was good otherwise.

Re: Rewriting Bun in Rust

#456

Post by endospore »

sashank_1509 wrote: post #125

I think the important thing is this is much cheaper than hiring a software engineering team. They could have hired me for 200k and I could not do this in a year. I do not have the context, and I do not know Zig or Rust, perhaps I could pick it up in a month, but I would be extremely slow. Forgetting all the predictions about singularity etc, at the very least AI as it is now, is going to make it very hard to justify…

Ha. You'll be surprised when you find out how much new problems were created in the code base precisely because the author's (not sure if it's still the right word here, they barely involved) lack of knowledge of Rust.

And no, since they don't know they don't know about it, there are no signs of fixes around these real issues. They had posted something about the unsafe usage, but lol most of the UBs are casually swept away (not even treated as unsoundness), if you actually look at the code and the summary.

Re: Rewriting Bun in Rust

#457

Post by pjmlp »

IshKebab wrote: post #407
pjmlp wrote: post #343

Earlier quoted context omitted.

Because contrary to Rust, C and C++ have a culture of binary libraries. You are seldom compiling the world from scratch. Especially in the platforms dear to game devs.

> You are seldom compiling the world from scratch. True in Rust too though - you're normally doing incremental compiles. And even though you're compiling the world, it's still on par with C++. For example I just tried compiling a hello world Bevy project, which has 462 crate dependencies - pretty big. It took 2m20. Totally reasonable to build an entire game engine and all it's dependencies. I wish they had reported t…

Yeah but compiling full Unreal from scratch already requires going down the path of forking it for own purposes.

Same applies to most commercial libraries, where code is usually provided for debugging purposes, not for building everything from scratch.

Also incremental linking on Rust, or hot code reloading is still not something that works out of the box.

How beefy is that machine to achieve 2m20? I started using C++ on MS-DOS, on a 20 MHz 386SX PC with 2MB RAM and 20 MB HDD.

Especially relevant in current times.

Re: Rewriting Bun in Rust

#458

Post by endospore »

padjo wrote: post #421

It's very odd how quickly people fall back on emotional claims to attack this. Like we're engineers, if you can point at concrete problems with this rewrite I'd love to hear them. Obviously Jared is going to give the positive case, saying that he's doing that doesn't prove the rewrite is a bad idea. You need to point at objective problems, not your vague sense of unease. As it stands, by all available measures, this…

Well the rewrite has newly introduced many immediate and critical safety (as in Rust sense) problems. It's clear and obvious if you read the code knowing the basic rules of unsafe Rust. And don't be surprised if it doesn't appear as obvious to you or Jarred or Claude, because not knowing they don't know is the exact reason why they failed at it.

And for the emotional aspect. I'm working as an R&D engineer and one of my recently assigned experiments is to evaluate replacing workers with LLMs, quality software with slops. Every bit of exaggeration they make is making my coworkers lose jobs and I'll be no exception. The entirety of me consists of reasons going against this kind of marketing compaign.

Re: Rewriting Bun in Rust

#459

Post by geraneum »

StriverGuy wrote: post #416
QuadmasterXLII wrote: post #412

Putting on my machine learning PhD student hat, the way to do this was to leave 10% of the tests out as a ‘test’ set and then once the port was done, bring them back in and find out how good the port is. The port may genuinely be good but because they spent 100k of compute hill climbing the whole test suite, “the test suite passes” now provides far less evidence that the port is good. Its weird that at Anthropic, a v…

Huh? This approach makes sense for non-deterministic problems. Not engineering problems that have deterministic end results.

> non-deterministic problems

I'm guessing you mean probabilistic? Nevertheless, you have an indeterministic variable here which is what the LLM generates.

Re: Rewriting Bun in Rust

#460

Post by insanitybit »

lunar_mycroft wrote: post #444
padjo wrote: post #421

It's very odd how quickly people fall back on emotional claims to attack this. Like we're engineers, if you can point at concrete problems with this rewrite I'd love to hear them. Obviously Jared is going to give the positive case, saying that he's doing that doesn't prove the rewrite is a bad idea. You need to point at objective problems, not your vague sense of unease. As it stands, by all available measures, this…

There were/are absolutely plenty of real problems with the resulting code pointed out. Running Miri trivially found soundness issues, `SAFETY` comments that demonstrate that the model in question fundamentally doesn't understand/simulate understanding how unsafe rust works [0], etc. [0] https://github.com/oven-sh/bun/blob/fc865b398e51de8a95ddde4b...

These seem really easy to address. Any SAFETY comment that relies on the caller is something you can trivially find and fix.
Post reply on HN