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

Zig → Rust porting guide

github.com

Post reply on HN
Print view View original

51–60 of 592 posts

Re: Zig → Rust porting guide

#51

Post by heddhunter »

allthetime wrote: post #27
nailer wrote: post #13

Earlier quoted context omitted.

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

what would you call a fully uncommented commit with "+27,939Lines changed: 27939 additions & 0 deletions" of new rust code

Just another Monday in 2026.

Re: Zig → Rust porting guide

#52

Post by lstodd »

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?

You try to use it you'll get it. Otherwise it's just words. Like these: rust failed at async.

Re: Zig → Rust porting guide

#54

Post by stingraycharles »

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?

I think the definition of vibe coding is a bit fluid, in this case I just meant it to be “code fully generated by AI, possibly not fully reviewed by human eyes”. I agree that this definitely not “coding based purely off vibes”, and the approach looks legit.

Re: Zig → Rust porting guide

#55

Post by Philpax »

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 not really shunned - it's the standard solution for async in Rust - but it's not the right solution for every project, especially if you have specific requirements for how your project's computation should be scheduled. I would guess that Bun is one of those projects, especially as it needs to be able to schedule JS async work itself.

Re: Zig → Rust porting guide

#58

Post by thayne »

When I first heard that bun was written in zig, I thought that was an odd choice for such a large project, mostly because the language is "unstable" and is still making significant breaking changes.

I would guess dealing with breaking changes is a big motivation for this.

Re: Zig → Rust porting guide

#60

Post by _--__--__ »

kristoff_it wrote: post #44
_--__--__ wrote: post #11

Earlier quoted context omitted.

Possibly related to https://simonwillison.net/2026/Apr/30/zig-anti-ai/ where the Bun team wanted to upstream work to Zig that was rejected by a blanket anti-LLM contribution policy.

Code origin was not even a factor https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...

That seems totally reasonable but I wonder if there was some head butting in non-public channels given Bun is one of the biggest players in Zig and planned to push through a change like that on their own.
Post reply on HN