Zig → Rust porting guide • Hacker News Board

Re: Zig → Rust porting guide

#91

Post by thombles » Tue, May 05, 2026, 2:33 AM UTC

sergiotapia wrote: post #36

>*No `tokio`, `rayon`, `hyper`, `async-trait`, `futures`.* No `std::fs`, I'm not a rust dev but even I kind of notice that tokio is kind of shunned in most projects. Why is that? Is it just bad or what?

The answer is in the next sentence: "Bun owns its event loop and syscalls." They clearly want to manage their use of threads explicitly, which is not _unusual_ for systems programming but probably less common. Note that `rayon` is different from most of these in that it has nothing to do with async Rust - it's a tool for spreading computation over a thread pool, very popular in non-async projects, but it would also go against their goals here.

Re: Zig → Rust porting guide

#92

Post by cropcirclbureau » Tue, May 05, 2026, 2:33 AM UTC

The only Bun shipped product I've used in anger is OpenCode and I regularly run into segfaults on it. I doubt this is the reason for migration but every time it happens, it reminds me the real cost of unsafe code. That being said, Zig is an absolute pleasure to write and I can't wait until it has a real library ecosystem, Rust's greatest boon.

Re: Zig → Rust porting guide

#93

Post by arjie » Tue, May 05, 2026, 2:35 AM UTC

sergiotapia wrote: post #36

>*No `tokio`, `rayon`, `hyper`, `async-trait`, `futures`.* No `std::fs`, I'm not a rust dev but even I kind of notice that tokio is kind of shunned in most projects. Why is that? Is it just bad or what?

It's an async runtime. The whole async-await flow removes a little bit of scheduling control and adds some forced memory management in order to give you some nicer code in an application case, but if you're trying to build a runtime yourself I think you'd much rather retain control in this case. It's just hard to reason about.

You much rather have this runtime you're building manage task scheduling and allocation and all that. It's the most natural design choice to make.

Re: Zig → Rust porting guide

#94

Post by malisper » Tue, May 05, 2026, 2:38 AM UTC

stingraycharles wrote: post #5

Interesting to see this when the current top post on HN is someone worrying about Bun as it was acquired by Anthropic. The top comment there describes “Anthropic does experiments on their own codebase, the Bun team is not gonna do the same vibe coding experiments”. Yet here we are, what looks like a massive undertaking for vibe coding. Time will tell how this will turn out. Would be nice if the Bun maintainers could…

> what looks like a massive undertaking for vibe coding

fwiw, I suspect it's less of an undertaking than you may think. I've been playing with AI to rewrite Postgres in Rust[0] over the past couple of weeks and I found the AI to be exceptional at doing rewrites. Having an existing codebase you can reference prevents a lot of the problems you have with vibecoding. You have an existing architecture that works well and have a test suite that you can test against

Over the course of a month I've gone from nothing to passing over 95% of the Postgres test suite. Given Jarred built Bun, I bet he'll be able to go much faster

[0] https://github.com/malisper/pgrust

Re: Zig → Rust porting guide

#95

Post by toledocavani » Tue, May 05, 2026, 2:38 AM UTC

For better or for worse, at least Bun is open source, and the world is not lacking a NodeJS alternative.

What is the most interesting here for me is:

- a big, clear outcome and acceptance criteria, vibe coding project on

- a public, working, high performance, full featured, production codebase by

- the leading LLM model maker known for the strongest coding ability

A good example no matter if it successes or not.

Re: Zig → Rust porting guide

#96

Post by vlovich123 » Tue, May 05, 2026, 2:38 AM UTC

aabhay wrote: post #66

jaggederest wrote: post #30

Earlier quoted context omitted.

Anthropic makes claude, claude can write Rust like a champ and struggles at Zig. It's a straightforward "training data" argument. I think there are even longer term plays that Anthropic should be looking at, in this space, but it seems like they've decided rust is the right thing, so fair play. I would be (am!) thinking about making an LLM optimized high level language that you can generate / train on intensively bec…

Claude doesn’t write Rust like a champ. It’s still miles ahead at js and python than it is at rust. It can do macros and single file optimizations but its gotten really stuck in type hell and tried to dyn everything on multiple occasions for me.

Claude struggling at Rust: not getting types correct, using the wrong abstractions, not implementing things correctly

Claude struggling at Zig: the above + memory safety issues if you run “fast” mode.

It is generally true that Rust code tends to be written in a way that the compiler catches the issue at compile time. The same is not as true for Zig, Python or JS

Re: Zig → Rust porting guide

#97

Post by confessinator » Tue, May 05, 2026, 2:40 AM UTC

Aside from Zig's anti-AI stance and maintaining their own Zig fork, I think this port will showcase that Anthropic can re-engineer a massive codebase.

As an aside, I've been bitten by Zig's breaking changes on my own projects as well. It's taken the shine off of Zig and I'm looking at alternatives.

Re: Zig → Rust porting guide

#98

Post by WD-42 » Tue, May 05, 2026, 2:41 AM UTC

nailer wrote: post #13

stingraycharles wrote: post #5

Interesting to see this when the current top post on HN is someone worrying about Bun as it was acquired by Anthropic. The top comment there describes “Anthropic does experiments on their own codebase, the Bun team is not gonna do the same vibe coding experiments”. Yet here we are, what looks like a massive undertaking for vibe coding. Time will tell how this will turn out. Would be nice if the Bun maintainers could…

> what looks like a massive undertaking for vibe coding It doesn’t look like that at all. Do you think that all use of AI is vibe coding?

Did you look at the branch? This is vibed, even with the most liberal definition

https://github.com/oven-sh/bun/compare/claude/phase-a-port

This single commit is 65k lines of additions

https://github.com/oven-sh/bun/commit/ffa6ce211a0267161ae48b...

Re: Zig → Rust porting guide

#99

Post by tacitusarc » Tue, May 05, 2026, 2:41 AM UTC

I wonder if a successful, albeit slower, approach would be to walk the git commit history in lockstep, applying the behavioral intent behind each commit. If they did this, I would be interested in knowing if they were able to skip certain bug fix commits because the Rust implementation sidestepped the problem.

Re: Zig → Rust porting guide

#100

Post by andkenneth » Tue, May 05, 2026, 2:42 AM UTC

stingraycharles wrote: post #5

Interesting to see this when the current top post on HN is someone worrying about Bun as it was acquired by Anthropic. The top comment there describes “Anthropic does experiments on their own codebase, the Bun team is not gonna do the same vibe coding experiments”. Yet here we are, what looks like a massive undertaking for vibe coding. Time will tell how this will turn out. Would be nice if the Bun maintainers could…

They recently tried to upstream an improvement to zig, but were prevented from doing so because zig has a hard and fast "no AI code" rule. Whether you think this response is trying to put pressure on zig or whether they're just moving for practical reasons is up to you.

It's probably a bit of both.