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

171–180 of 592 posts

Re: Zig → Rust porting guide

#171

Post by fgfarben »

rustybaritone wrote: post #129
Humphrey wrote: post #16

I'll be very interested in how this AI port turns out. I am involved in a number of active projects that are being held back by the language / framework is holding back the project, but where a rewrite would be too big of a project to undertake by using only human power. I've had more success vibe coding Rust than I have in more dynamic languages. I suspect the strictness of the Rust compiler forces the AI agent to p…

Yes it generates trash Rust code. > Not sure. It could be just that I am less familiar with Rust so it feels like it's doing a better job. Ya think?

Doy!

Re: Zig → Rust porting guide

#172

Post by NewJazz »

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

What a sober, detailed forum post.

Re: Zig → Rust porting guide

#175

Post by kimos »

abacadaba wrote: post #146
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.

seems easier to fork zig

Then that becomes an ongoing effort. The rewrite is once. (Good idea or not)

Re: Zig → Rust porting guide

#176

Post by kelnos »

ratioprosperous wrote: post #132
xeonmc wrote: post #128

Earlier quoted context omitted.

Take off every Zig

It's time! https://xkcd.com/286/

Wow. That xkcd was written in 2007, and part of the dialog is "didn't that [meme] die like five years ago?" Which means All Your Base, as a meme, was already getting somewhat stale by around 2002. It's hard to believe it's been that long.

Re: Zig → Rust porting guide

#177

Post by KingMob »

endospore wrote: post #137
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.

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)

Possibly, but the Zig creator is active on Lobste.rs, where he's been vocally anti-LLM for a year now, so the timing could just be a coincidence.

Re: Zig → Rust porting guide

#178

Post by dimator »

allthetime wrote: post #124
10000truths wrote: post #106

Earlier quoted context omitted.

> unless you feed it source Which isn't particularly difficult - the language docs and std source come with the installation, so all you need to do is tell Claude where those directories are in your skill/plugin/CLAUDE.md. > and guide it closely (in which case it's useful for focused work) It does struggle sometimes with writing code that compiles and uses the APIs correctly. My approach to that so far has been to wr…

You're already at a disadvantage having to stuff the context and spend extra tokens coercing the model in the correct direction compared to it already knowing what to do (rust, ts, go, etc.) Here, I just did a quick test with claude. 1. "make a simple tcp echo server that uses rust" compiles and runs - took a few seconds to generate. 2. "make a simple tcp echo server that uses zig" result: compile error, took literal…

i mean, if zig is doing its best (inadvertently) at shooing off slop jockeys, then i already have more confidence that:

1. the language and stdlib are written by people who know what they're doing 2. packages in the ecosystem, at the barest level, are written by those who didn't leave after a few compile errors they couldn't reason about

Re: Zig → Rust porting guide

#179

Post by wg0 »

petre wrote: post #163
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?

C obviously.

I was hoping bash because why not. It's AI that has to work and maintain anyway and Anthropic employees aren't limited by 5 hour 7 days limits anyway I suppose.

Re: Zig → Rust porting guide

#180

Post by mswphd »

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.

the rust they've written (so far) is highly unidiomatic (and with a ton of unsafe). I can't speak to the zig part, but it seems plausible to me it is line-by-line, horrendous rust.

Whether or not they can clean it up is an interesting question.

Post reply on HN