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

321–330 of 592 posts

Re: Zig → Rust porting guide

#321

Post by rob74 »

andkenneth wrote: post #100
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.

Yeah, now that I think about it, having a major project written in a language that doesn't accept AI contributions now owned by a major AI company was a recipe for dis... er, conflict.

I'm not a huge fan of Rust, but I guess having a project like Bun in an actually memory safe language is probably a win? Guess it depends on how good Claude is at writing Rust code...

Re: Zig → Rust porting guide

#324

Post by wolfi1 »

Dylan16807 wrote: post #256
bboozzoo wrote: post #250

Earlier quoted context omitted.

> patch series from a competent team that changes 3000 lines should probably be split into a bunch of much smaller changes?

I don't understand your suggestion. If you take an ugly patch series that changes 3000 lines and organize it into small quality changes, it's still a patch series that changes 3000 lines. There's no reason to assume my generic statement was talking about the ugly version rather than the nicely organized version.

perhaps not all of these 3000 line changes make sense?

Re: Zig → Rust porting guide

#325

Post by [deleted] »

alethic wrote: post #320
norman784 wrote: post #272

Earlier quoted context omitted.

Not only because the AI part, here's a discussion [0] about it [0] https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...

In the context of this post, that's absolutely hilarious they're vibe-porting their Zig codebase to Rust . I love Rust, but you couldn't pick a language with slower compile times... XD

[deleted]

Re: Zig → Rust porting guide

#326

Post by codethief »

andkenneth wrote: post #100
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.

> but were prevented from doing so because zig has a hard and fast "no AI code" rule

No, they were prevented from doing so because the Zig devs didn't like the proposed changes and are preparing a more comprehensive improvement.

Re: Zig → Rust porting guide

#328

Post by IshKebab »

swyx wrote: post #211
mr_00ff00 wrote: post #119

Earlier quoted context omitted.

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

care to attempt a top 3 differences that someone doing this kind of rewrite should know? (would teach me a little about Zig, about which i know 0)

Zig doesn't have a borrow checker. It's basically C, if C had been much better designed.

Line-by-line ports to idiomatic Rust are usually not possible because of the borrow checker and Rust's ownership rules. That's the reason the Typescript compiler was ported to Go instead of Rust.

Re: Zig → Rust porting guide

#329

Post by sufficientsoup »

swyx wrote: post #211
mr_00ff00 wrote: post #119

Earlier quoted context omitted.

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

care to attempt a top 3 differences that someone doing this kind of rewrite should know? (would teach me a little about Zig, about which i know 0)

Wouldn’t call myself an expert in either, but I think 2 things stand out far more than anything else: 1. Rust is effectively as strict as can be in terms of ownership. In Zig you can just allocate some memory and then start slinging pointers (or slices) all over. If you’re doing this then you’re presumably doing it for mutability and you don’t strictly know where that pointer ends up once you’ve passed it on. 2. Rust’s metaprogramming is split among a couple different things (e.g. traits, macros), whereas Zig’s is unified (comptime). comptime is (at least advertised as) “just normal Zig code” and Rust macros are a great example of “this doesn’t work at all like the base language”.

#1 boils down to “can the LLM solve the pointer aliasing here?” and #2 is translating between metaprogramming paradigms. Could work but a line-by-line translation is a pipe dream.

Re: Zig → Rust porting guide

#330

Post by mb2100 »

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…

What's the main motivation for considering Rust?

For what it's worth, in my last experience with Bun[0] I ran into a couple of bugs where it seemed Rust could have helped, e.g. using Bun.write

[0]: https://mastrojs.github.io/blog/2025-10-29-what-struggled-wi...)

Post reply on HN