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

301–310 of 560 posts

Re: Rewriting Bun in Rust

#301

Post by baq »

comex wrote: post #222
kibwen wrote: post #137

Earlier quoted context omitted.

> The best way to speed it up appears to be organizing a codebase in many crates. A "crate" in Rust is the unit of compilation. In C, a file is the unit of compilation. Rust just lets you have a compilation unit that's composed of more than one file (without having to resort to C-style textual inclusion). But if you want, you can certainly have one-file-per-crate, just like you would in C. And what's nice about havin…

The forbidding of circular dependencies is exactly what makes it hard to achieve parallelism! It means you have to draw nice clean module boundaries and split your compilation units there. Clean boundaries sound nice, except… what if the module is getting large? Can you just take half the module, ctrl-x, ctrl-v into a new file, and get faster compilation times without having to do any massive refactors? In C, usually…

The industry accepted way of handling circular dependencies is to not have them and heavily lint against them in languages which permit them in compilation or runtime.

Re: Rewriting Bun in Rust

#302

Post by steve_adams_86 »

bigstrat2003 wrote: post #269
minimaxir wrote: post #235

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/Opportunity_cost

Opportunity cost is not a real cost. No money leaves your bank account. It is a decision making tool, and treating it as an actual financial cost is a misuse of the idea.

It’s literally the price of lost opportunities. It’s not understood to be a financial cost. It’s exactly what it says on the tin. Lost opportunities may not be a financial cost, but they’re certainly a cost.

Re: Rewriting Bun in Rust

#303

Post by b0rsuk »

solid_fuel wrote: post #205
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…

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…

[dead]

Re: Rewriting Bun in Rust

#304

Post by IshKebab »

leecommamichael wrote: post #113
didibus wrote: post #80

Article did a decent job of showing discipline and care and human involvement to assert the automated rewrite was done diligently, as best as it can be when using AI for it. I does make me feel a bit more comfortable about it. As an aside, I don't know why anyone would not want to use a memory-safe (and possibly race-safe) language in 2026. Rust gives you that in a performant package, so if you are turned off by GCs…

> As an aside, I don't know why anyone would not want to use a memory-safe (and possibly race-safe) language in 2026. The rust compiler is very slow. The best way to speed it up appears to be organizing a codebase in many crates. This is not preferable ergonomics to many. Beside that, for many problems, a garbage collector eliminates a large amount of defects (including the ones stated in the article) without any add…

> The rust compiler is very slow.

It was very slow. It's gotten a lot faster over time (over 2x faster). It's still not exactly fast, but it's definitely faster than C++. Although C++'s slow compile times are often complained about they were never really enough to stop most people using it, including for games.

> a garbage collector eliminates a large amount of defects (including the ones stated in the article) without any added friction

I'd be careful about that "without any added friction". Rust's lifetime/borrowing system tends to lead to less buggy code because it encourages structuring code in a less spaghetti way. GC does eliminate memory errors but you also lose that non-spaghetti code structure.

Re: Rewriting Bun in Rust

#305

Post by baq »

henry_bone wrote: post #148
didibus wrote: post #80

Article did a decent job of showing discipline and care and human involvement to assert the automated rewrite was done diligently, as best as it can be when using AI for it. I does make me feel a bit more comfortable about it. As an aside, I don't know why anyone would not want to use a memory-safe (and possibly race-safe) language in 2026. Rust gives you that in a performant package, so if you are turned off by GCs…

I'll bite. The first language I could "just write" in was C. I had internalised the language and its standard lib and didn't need the internet to work with it. Rust is pushed by many as the replacement to C, because of the memory safety guarantees. I'm sympathetic. I worked with Haskell for a time, so I get it. But Rust seems quite complex. There are so many language features that there's memes about it. There's also…

> The first language I could "just write" in was C. I had internalised the language and its standard lib and didn't need the internet to work with it.

I bet $4.20 you didn’t write C. You wrote something C-like which the compiler didn’t reject because the C standard has a gigantic surface of ‘undefined behavior’ which means once your program does one thing out of spec it isn’t C anymore silently.

Re: Rewriting Bun in Rust

#306

Post by steve_adams_86 »

cognitiveinline wrote: post #215
einsteinx2 wrote: post #154

Earlier quoted context omitted.

> and spent $165,000 of tokens on the most advanced coding LLM anyone has access to. After having used 2 full weeks of 20x Max plan tokens on Fable over the weekend (coding all day Saturday and Sunday on a non-trivial project, tasks across full stack, mix of adding features, reviewing code, and fixing bugs), I’m confident if he’d spent $165,000 in Opus tokens the port would have gone more or less just as well (and pr…

Fable is kind of fantastic on the difficult tasks. if it's something eithe rmodel can do then you can't see the difference. Fable also makes much less mistakes. It's a more relentless, proactive problem solver.

I’ve been noticing that it will test hypotheses for evidence frequently. I really like that. With Opus I have to instruct it with a skill to build prototypes, but Fable will do it and do it really well by default. Really nice detail. I’m guessing it’s part of the system prompt, but the higher capability paired with this experimentation lean makes it far better at planning and verifying.

Re: Rewriting Bun in Rust

#307

Post by fulafel »

didibus wrote: post #80

Article did a decent job of showing discipline and care and human involvement to assert the automated rewrite was done diligently, as best as it can be when using AI for it. I does make me feel a bit more comfortable about it. As an aside, I don't know why anyone would not want to use a memory-safe (and possibly race-safe) language in 2026. Rust gives you that in a performant package, so if you are turned off by GCs…

Fortunately there are also many other memory safe languages to choose from.

Re: Rewriting Bun in Rust

#308

Post by IshKebab »

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…

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

Sure, if you're wasting money in silicon valley. They could have hired in Europe and got three people for $300k, which is only double what they spent.

I think the time is the really significant factor, not the money. I bet if they had the option of paying $300k to have it done by humans rather than AI, but magically in a week instead of a year, they would have gone for that instead. $300k is nothing to Anthropic.

Re: Rewriting Bun in Rust

#309

Post by IshKebab »

tick_tock_tick wrote: post #283
slopinthebag wrote: post #127

Earlier quoted context omitted.

Why assume the upper level salary here? Using senior level developers making astronomical salaries for what is a mechanical line-by-line port would be a poor financial decision. What does the math look like with 25 devs making ~100k and doing it in 22 days? I’m sure you could find a reasonable combination which costs less. And if you’re already paying the devs the salary, it’s basically free (minus the opportunity co…

> Why assume the upper level salary here? Even a junior is going to cost you $200k by the time you're done paying payroll taxes, healthcare, etc.

Nonsense. Junior salaries are on the order of $50k in the UK. There's no healthcare to pay, but employer taxes and overheads might be around 30%, so you're talking way under $100k.

Re: Rewriting Bun in Rust

#310

Post by nicce »

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, especially if company owns it.

Post reply on HN