Zig → Rust porting guide • Hacker News Board

Re: Zig → Rust porting guide

#481

Post by kingstnap » Tue, May 05, 2026, 2:42 PM UTC

psychoslave wrote: post #472

Jarred wrote: post #319

I work on Bun and this is my branch 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. I’m curious to see what a working version of this looks, what it feels like, how it performs and if/how hard it’d be to get it to pass Bun’s test suite and be maintainable. I’d like to be able to co…

Will you have a way to measure the ecological impact it has to make such a throw away attempt? Not actually pointing on you or anyone in particular here to be clear. And if the answer would be "not much more than forgetting the light when leaving the toilets", certainly that would be a "go have fun" cheerleading on my part. But otherwise we collectively have to keep in mind that the prompt that we can throw mindlessl…

Right now it seems to say:

> Showing 1,808 changed files with 790,916 additions and 151 deletions.

Just looking at the git diff [0].

I looked at one of these rust port files [1]. Its 827 loc and apparently 7,576 tokens. So that gives you a first order guess that the full 700k additions is around 8 million output tokens. Obviously there are some tool calls, reasoning, reads of the zig version, and fixing compile errors as overhead. So I would guess maybe this is like 40 million tokens by multiplying by 5?

If we guess that is around $200 to $500 in token spend. We can probably guess that it emits around the same as buying $100 in gas? Or like 50 or so kgs of CO2?

[0] https://github.com/oven-sh/bun/compare/main...claude/phase-a...

[1] https://github.com/oven-sh/bun/blob/dacc59c62a8f93eabe6d9998...

Re: Zig → Rust porting guide

#482

Post by dspillett » Tue, May 05, 2026, 2:42 PM UTC

zozbot234 wrote: post #467

magicmicah85 wrote: post #462

Earlier quoted context omitted.

The branch name is "claude/phase-a-port", there was zero indication this was an experiment until Jarred commented. The more accurate title might have simply been "there is a branch in the official repo of bun describing a port to rust from zig". No amount of soft titles would have prevented the discussion. People have their opinions about Bun, about Zig, about Rust and it's all going to come out in a discussion board…

> there was zero indication this was an experiment The goal of Phase A is a **draft** `.rs` next to the `.zig` that captures the logic faithfully — it does **not** need to compile. Phase B makes it compile crate-by-crate. I mean, it would be hard to spell it out any clearer than that! Code that fails to compile is just not very useful for real work.

Yes, but that would require people to read past the title. You can't get a proper knee-jerk first post in if you do that! Completely unfair to expect people to make that sacrifice/effort.

[there was some sarcasm there, BTW, if anyone has a faulty detector that didn't pick up on it]

Re: Zig → Rust porting guide

#483

Post by MisterTea » Tue, May 05, 2026, 2:44 PM UTC

Jarred wrote: post #319

I work on Bun and this is my branch 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. I’m curious to see what a working version of this looks, what it feels like, how it performs and if/how hard it’d be to get it to pass Bun’s test suite and be maintainable. I’d like to be able to co…

Advice for the future: experiments should be explicitly tagged as such. The commit message "docs: add Phase-A porting guide" says nothing about the experimental and looks like a planned move to rust. That message certainly looks very official to me.

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

Trying to pass off a blunder like this like its no big deal is an insult to your users. You made a dumb mistake. Own it, be transparent and correct the problem that started this; namely, put some form of experimental tag in the commit message. Then say you made a simple mistake, sorry, and move on. Being dismissive is a defense mechanism that can arouse suspicion, as in are you now lying about the experimental state to quench the flame war? Not that I believe that but it can certainly now become conspiracy. Again, you can avoid all that with transparency.

Re: Zig → Rust porting guide

#484

Post by nicoburns » Tue, May 05, 2026, 2:44 PM UTC

LinusU wrote: post #480

satvikpendem wrote: post #470

Earlier quoted context omitted.

Well yeah, it's in Zig, not a memory-safe language, so of course I'd expect memory leaks. That's why I haven't seriously used bun and instead use a runtime that actually is in a memory-safe language, Deno in Rust. It's like wearing roller skates without brakes and wondering why you keep running into things.

Memory safety has nothing to do with memory leaks, and it's perfectly valid to leak memory in Rust? e.g. `Box::leak(Box::new( ... ))`

Memory safety doesn't help too much here, but "RAII" (automatically dropping values when they go out of scope) does.

Re: Zig → Rust porting guide

#485

Post by selfmodruntime » Tue, May 05, 2026, 2:44 PM UTC

mr_00ff00 wrote: post #119

noveltyaccount wrote: post #104

Earlier quoted context omitted.

This prompt defines the translation as a file for file, line for line port. Seems like historical knowledge will be fine.

Having dabbled with both Zig and Rust, they do things so fundamentally differently, it isn’t possible to do exact lines like that.

You can do this with a bunch of clones. But this will make your software slower and kind of defeats the entire purpose.

Re: Zig → Rust porting guide

#486

Post by magicmicah85 » Tue, May 05, 2026, 2:47 PM UTC

eigilsagafos wrote: post #475

magicmicah85 wrote: post #462

Earlier quoted context omitted.

The branch name is "claude/phase-a-port", there was zero indication this was an experiment until Jarred commented. The more accurate title might have simply been "there is a branch in the official repo of bun describing a port to rust from zig". No amount of soft titles would have prevented the discussion. People have their opinions about Bun, about Zig, about Rust and it's all going to come out in a discussion board…

Can’t every branch be considered an experiment? I have a ton of experimental branches that I don’t label «experimental». One of the reasons you use git…

Sure, but then how does it change anything around the discussion? You are still running an experiment to port to Rust, it still gets posted, the Rust-heads and Zig-heads still make their comments.

Re: Zig → Rust porting guide

#487

Post by dspillett » Tue, May 05, 2026, 2:49 PM UTC

naasking wrote: post #430

jeltz wrote: post #293

Earlier quoted context omitted.

I don't see why they think it would work when the reason their patch set was rejected was because it was not correct, did not go in a direction the Zig authors were interested in and is also in an area where they are already working hard on improvements. It would have been much better if the bun team joined forces and helped out instead of vibe coding a broken PoC patch that never can get merged. Compilation speed is…

> It would have been much better if the bun team joined forces and helped out Submitting patches is joining forces and helping out.

Submitting patches that are correct and match the project's desired standards¹ is joining forces and helping out.

--------

[1] And align with the project's direction. This part is of course much more subjective so could very easily be an honest misunderstanding of the situation.

Re: Zig → Rust porting guide

#488

Post by Tadpole9181 » Tue, May 05, 2026, 2:50 PM UTC

MisterTea wrote: post #483

Jarred wrote: post #319

I work on Bun and this is my branch 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. I’m curious to see what a working version of this looks, what it feels like, how it performs and if/how hard it’d be to get it to pass Bun’s test suite and be maintainable. I’d like to be able to co…

Advice for the future: experiments should be explicitly tagged as such. The commit message "docs: add Phase-A porting guide" says nothing about the experimental and looks like a planned move to rust. That message certainly looks very official to me. > 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 throw…

Or we can stop being toxic to open source maintainers and acting like we own them or they owe us anything.

A commit message on a random branch is not an obligation. Not telling random internet users what side projects they're working on is not a blunder. It quite frankly doesn't matter what you think looks official, it doesn't give you the right to treat people like this.

It's so embarrassing to be a programmer some times, so many of my peers behaving like spoiled rotten brats.

Re: Zig → Rust porting guide

#489

Post by magicmicah85 » Tue, May 05, 2026, 2:52 PM UTC

zozbot234 wrote: post #467

magicmicah85 wrote: post #462

Earlier quoted context omitted.

The branch name is "claude/phase-a-port", there was zero indication this was an experiment until Jarred commented. The more accurate title might have simply been "there is a branch in the official repo of bun describing a port to rust from zig". No amount of soft titles would have prevented the discussion. People have their opinions about Bun, about Zig, about Rust and it's all going to come out in a discussion board…

> there was zero indication this was an experiment The goal of Phase A is a **draft** `.rs` next to the `.zig` that captures the logic faithfully — it does **not** need to compile. Phase B makes it compile crate-by-crate. I mean, it would be hard to spell it out any clearer than that! Code that fails to compile is just not very useful for real work.

Phase B clearly says compilation is the next goal. The first goal is to get a like for like logic, the second goal is to get it to compile. Can you guess what the third goal will be? Throw out the code?

Re: Zig → Rust porting guide

#490

Post by zozbot234 » Tue, May 05, 2026, 2:56 PM UTC

magicmicah85 wrote: post #489

zozbot234 wrote: post #467

Earlier quoted context omitted.

> there was zero indication this was an experiment The goal of Phase A is a **draft** `.rs` next to the `.zig` that captures the logic faithfully — it does **not** need to compile. Phase B makes it compile crate-by-crate. I mean, it would be hard to spell it out any clearer than that! Code that fails to compile is just not very useful for real work.

Phase B clearly says compilation is the next goal. The first goal is to get a like for like logic, the second goal is to get it to compile. Can you guess what the third goal will be? Throw out the code?

The branch is named phase-a-port and the document explains what "phase-a" means. It's quite clear.