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

311–320 of 560 posts

Re: Rewriting Bun in Rust

#311

Post by thayne »

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…

> Beside that, for many problems, a garbage collector eliminates a large amount of defects (including the ones stated in the article)

Languages with garbage collection are generally considered "memory safe". GP was talking about choosing a language that requires manual memory management, but doesn't have something like rust's lifetimes to catch things like use-after-free.

Re: Rewriting Bun in Rust

#313

Post by raincole »

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.

Opportunity cost isn't just a real cost. It's THE real cost.

Re: Rewriting Bun in Rust

#314

Post by Havoc »

jordand wrote: post #254

The thing you have to remember with that $165k spend on tokens is that token prices are going to keep rising, and models may not get much better. I wouldn't be surprised if doing this same migration in 6 months time would end up costing $250k+

For sota perhaps but not convinced token price will shoot up if capability is held steady

Re: Rewriting Bun in Rust

#315

Post by [deleted] »

reinitctxoffset wrote: post #230
metaltyphoon wrote: post #206

Earlier quoted context omitted.

> Rust is (mostly) safer and more succinct than Zig while being dramatically less ergonomic This is just your opinion.

Well, it's my opinion. But it's also the opinion of the broader functional programming community from 1993 to the present day. This notably includes the quite serious Haskellers who designed Rust for the highly specific and demanding requirements of the Servo rendering engine in ~2010. Being as my two parents in web browser layout optimizations were both filed in 2009 I took considerable interest. It wasn't until 201…

[deleted]

Re: Rewriting Bun in Rust

#316

Post by usef- »

crote wrote: post #263
teach wrote: post #90

Earlier quoted context omitted.

You're entitled to call things as you wish, of course, but your definition of "vibe-coding" differs quite a bit from mine.

500k lines in 11 days? With 8-hour working days that's 100 lines per minute. There's no way you're comprehensively reviewing code that quickly. The code was generated by a LLM, and the output wasn't even read by its user. That's definitely vibe coding.

It's a direct translation without changing the overall code structure or data structures. I do think this process deserves a distinct name from blind whole-of-project vibe coding.

Translation does seem to be a strength of LLMs, and as they said in the post, the code at the function-level all still feels familiar to the team. They've also already moved users to the codebase without anyone noticing; that's a better result than typical vibe coding.

Re: Rewriting Bun in Rust

#317

Post by rane »

atonse wrote: post #160
losvedir wrote: post #156

In what ways does Anthropic use Bun? I know it's used as the "runtime" for Claude Code, but rather than porting a million lines of Zig to Rust, why not just port Claude Code to rust and not need to bundle a JS runtime at all? Does Anthropic use Bun otherwise? Maybe for JS execution tool calls in Claude responses?

I’ve wondered the same. Especially because codex is written in rust. Why not just port Claude code over. But my guess is that maybe it doesn’t have as robust a test suite? This might embolden them to do it…

It's extremely difficult to have a robust test suite for a TUI app like Claude Code. Hence regressions keep showing up in every update.

Re: Rewriting Bun in Rust

#318

Post by khurs »

> Bun was acquired by Anthropic in December 2025

Great for the Bun creators, but now we will have major runtimes that are optimised to work with one companies models...

Re: Rewriting Bun in Rust

#319

Post by canbus »

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…

People get attached to things they've been using for decades. Also most of the world is still written in c/c++ so any critical mass has quite a lot to go up against.

Rust isn't perfect but it solves a lot of the pitfalls of C++ (not just UB, package management, horrible cmake files, linker errors etc.)

Post reply on HN