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

161–170 of 592 posts

Re: Zig → Rust porting guide

#161

Post by rtpg »

pstuart wrote: post #69
rtpg wrote: post #23

Earlier quoted context omitted.

I think the big difficulty here is that Rust's ownership model in particular tends to require certain kinds of control flow to avoid a bunch of weird churning/copying, which makes it not as straightforward of a port target from other imperative languages. Like maybe you get the LLM to try _really hard_ to churn through everything, but this feels like a big case of "perils of the lack of laziness". Of course if you ha…

This is all wild conjecture, but I'd assume that teaching the LLM to do that mapping is an achievable goal and then it get's close to automatic -- effectively slurp the source AST into a rust AST and render. My only experience with ports so far is Python to Go, and it's been near flawless (just enough stupid shit to make me feel justified to be in the loop).

It really isn't if you don't have the right abstractions.

Especially for memory management the right and wrong abstractions in Rust can lead to a factor of 5 or 10 extra amount of difficulty. The right memory management abstraction and your code can be a straight line port (or even cleaner!), the wrong one and you're going to just be spending a lot of tokens to have a machine spin around in circles trying to untie itself

GC'd languages don't have this problem, though obviously you can still generate stupid amount of pain for yourself by doing something wrong

Re: Zig → Rust porting guide

#162

Post by [deleted] »

ai_critic wrote: post #150
endospore wrote: post #137

Earlier quoted context omitted.

Makes me wonder why zig announced the strict LLM rule recently. I'm afraid one reason could be that zig doesn't want to accept code from the bun fork in the first place (because of LLM usage, deviation and other reasons)

It's a combination of pragmatism (not wanting to wade through slop, not wanting to shove out newbie developers) and politics (usual contemporary techie progressive stuff that's now oddly anti-technology).

[deleted]

Re: Zig → Rust porting guide

#163

Post by petre »

wg0 wrote: post #145
andkenneth wrote: post #100

Earlier quoted context omitted.

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.

So if tomorrow Rust denied the "improvement" to upstream Rust then what's the next language they plan to vibe code it in?

C obviously.

Re: Zig → Rust porting guide

#164

Post by lioeters »

Capricorn2481 wrote: post #143
lioeters wrote: post #120

Earlier quoted context omitted.

Exactly, this is a direct response to Zig refusing to accept pull requests from Bun (and Anthropic). That situation forced Bun to maintain a fork of Zig, and it makes sense in the long term that they'd rather port their entire project to Rust. I've really enjoyed Bun the past year or so, but the acquisition by Anthropic, Bun's codebase and documentation increasingly becoming AI slop, and this impulsive complete rewri…

Zig said they wouldn't have accepted the changes without AI either.

You're right, I was just now reading the full explanation. https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...

This makes me respect Zig team's stance more, that it's a technical decision more than an ideological one.

Re: Zig → Rust porting guide

#165

Post by josephg »

pizlonator wrote: post #127
kllrnohj wrote: post #77

Earlier quoted context omitted.

I would expect all LLMs are going to be better at Rust than Zig - a strong, thorough compiler will simply prevent more mistakes, and the benefits of a "simple" language decreases the larger the code base gets. The more abstractions exist, the less valuable "no hidden control flow" or "no hidden allocations" from the standard library get, and that's before you add the mother of all abstractions of vibe coding.

I have no doubt that LLMs are good at Rust. But I can’t reconcile the reasoning about “strong, thorough compiler” with the fact that LLMs are also fantastic at Ruby. They also write really great posix shell (including very sophisticated scripts) and python. Something more subtle is going on.

They do work well. But I still see the occasional type related issue or bug from refactoring that claude will introduce into javascript and python code. It seems to be happening less and less frequently as the models get better. But, the rust compiler catches real bugs in LLM code. I consider that a win.

Has anyone made any cross language benchmarks for LLMs? I wonder if rust's conceptual complexity makes it harder for LLMs to write? If all you care about is working software, which language is best for LLMs? Python, because there's more example code? Go or Java, because they're simpler languages? Ruby because its terse? Rust because of the compiler? I'd love to see a comparison!

Re: Zig → Rust porting guide

#167

Post by Petersipoi »

Capricorn2481 wrote: post #142
anymouse123456 wrote: post #90

This is a huge loss for the zig language and community. As a fan of the language, I hope it leads to some reflection on things that might need to change moving forward.

I think it reflects more on Bun. [1]. [1] https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...

Bun is the largest project written in zig. And it isn't close. Bun is bigger than zig itself. Seems like zig isn't mature enough to handle Bun's needs, so I don't blame them at all for looking for off ramps. Only time will tell if rigidity from the zig team is worth the cost of losing Bun. It might be.

Re: Zig → Rust porting guide

#168

Post by wg0 »

echelon wrote: post #155
wg0 wrote: post #145

Earlier quoted context omitted.

So if tomorrow Rust denied the "improvement" to upstream Rust then what's the next language they plan to vibe code it in?

Rust is legit one of the best languages to "vibe code" in. The emitted AST has a lower defect rate since it incorporates strong types and in-built error handling. Other pros include native code and portability, but downside is the compile time.

This could be a subjective feeling with no real data to back it up.

People say same about Go as well that it's type system and limited feature set makes it the best AI friendly language but there too, it just seems like a hunch rather than a proven fact.

Re: Zig → Rust porting guide

#169

Post by abtinf »

rdmsr0 wrote: post #156
andkenneth wrote: post #100

Earlier quoted context omitted.

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.

Even if AI had not been used, the changes would not have been upstreamed, see https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio... tl;dr the supposed improvements are not sound and the zig compiler has already gotten a whole lot faster

That is a devastating comment. I will now be extremely skeptical of bun.

Re: Zig → Rust porting guide

#170

Post by tux1968 »

TheRoque wrote: post #62
fcarraldo wrote: post #19

Earlier quoted context omitted.

Contributors and maintainers will also be easier to find in Rust than Zig. Zig is a great language and I want to see it succeed, but this is a prudent move for Bun.

Why didn't they use Rust in the first place then ? All this was true before AI

Anthropic only acquired Bun in December of last year. They weren't there in the first place, to make the decision.
Post reply on HN