Zig → Rust porting guide • Hacker News Board

Re: Zig → Rust porting guide

#551

Post by vdfs » Wed, May 06, 2026, 12:35 AM UTC

halJordan wrote: post #541

kelnos wrote: post #236

Earlier quoted context omitted.

The big difference here is that the C-to-Go tool was presumably deterministic: running it over and over again should produce the exact same result. You can trust that result because the human wrote the conversion tool, understood it, tested it, and worked the bugs out. The LLM is non-deterministic. You could have it independently do the conversion 10 times, and you'd get 10 different results, and some of them might e…

I'm not convinced by this argument. If you put 10 senior devs on a problem, you'd get ten solutions. Maybe even 12. If one engineer solves the same problem 10 times, you also will get 10 solutions. The problem is not that we get 10 solutions, and I think you should draw out your implications and state them directly. Bc they're already either solved or being actively iterated on by industry. And we (well not me) can a…

It's more about knowing that the tool will always produce the same result, like a compiler. There is also a difference, the llm may use diffrent solutions within the file and across files

Re: Zig → Rust porting guide

#552

Post by fireant » Wed, May 06, 2026, 1:15 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.

As a human occasionally writing Rust I've also frequently got stuck in type hell.

Re: Zig → Rust porting guide

#553

Post by pie_flavor » Wed, May 06, 2026, 4:13 AM UTC

gobdovan wrote: post #442

pie_flavor wrote: post #379

Earlier quoted context omitted.

Please observe a policy of extreme wisdom: https://github.com/Fody/Home/blob/master/pages/licensing-pat...

Are you being ironic or serious? I can see both pros (encourage people to see themselves as customers) and cons (less initial adoption) to the licensing, although I'd maybe leave bug issues open for everybody. What aspect do you think dominates?

Serious. And although 'seeing yourself as a customer' certainly makes things slightly better, I'm also referring just to the amount of cash that enters the coffers once it's no longer a tip jar per se. It is open source on the subject of copyright, but as was described in an article on here the other day, open-source doesn't mean community. By positioning the community aspect as something you have to buy into to enter, you end up (a) selling a product for cash without compromising open source and (b) ensuring everyone you deal with is serious. It's like the Red Hat model but workable at the lower end of software at the expense of lower upside.

Re: Zig → Rust porting guide

#554

Post by psychoslave » Wed, May 06, 2026, 5:01 AM UTC

kingstnap wrote: post #481

psychoslave wrote: post #472

Earlier quoted context omitted.

Will you have a way to measure the ecological impact it has to make such a throw away attempt? Not actually pointing on you or anyone in particular here to be clear. And if the answer would be "not much more than forgetting the light when leaving the toilets", certainly that would be a "go have fun" cheerleading on my part. But otherwise we collectively have to keep in mind that the prompt that we can throw mindlessl…

Right now it seems to say: > Showing 1,808 changed files with 790,916 additions and 151 deletions. Just looking at the git diff [0]. I looked at one of these rust port files [1]. Its 827 loc and apparently 7,576 tokens. So that gives you a first order guess that the full 700k additions is around 8 million output tokens. Obviously there are some tool calls, reasoning, reads of the zig version, and fixing compile error…

Thanks, that's a really great answer.

It feels odd that the same message can be thus down voted and give the impulse to provide courteous response with reasoning, metrics and values.

Glory to your kindness and informarive way to react.

Re: Zig → Rust porting guide

#555

Post by psychoslave » Wed, May 06, 2026, 5:19 AM UTC

tracker1 wrote: post #529

psychoslave wrote: post #472

Earlier quoted context omitted.

Will you have a way to measure the ecological impact it has to make such a throw away attempt? Not actually pointing on you or anyone in particular here to be clear. And if the answer would be "not much more than forgetting the light when leaving the toilets", certainly that would be a "go have fun" cheerleading on my part. But otherwise we collectively have to keep in mind that the prompt that we can throw mindlessl…

Less than the impact of people who can't be bothered to remember basic historical facts or directions in terms of hitting Google services dozens of times a day across the population. Probably less than the impact of having dozens/hundreds of actual developers, each with a dedicated computer running for months/years in what it would take for a similar effort. If you want to go live in the woods and farm/hunt for yours…

Isn't b it same to emit doubts that the resources required to find and access webpages or use a GPS is causing at scale the same ecological impact as everyone selling the world by the token. Though that might be wrong, of course, then doubts should be addressed with proper reasoning, not aggressive rejection which would be a call to run with a blind fold.

Having people working together at some goal is not not going to create the same social structures as running LLMs at the same goal. That's missing the ecosocietal forest for the digital output.

Actually, at societal level, no, people are not free to go into gather and hunt mode, that is not at scale. Sure some individual can do it on the margin, but by definition that won't make the mainstream societal impact disappear.

Re: Zig → Rust porting guide

#556

Post by psychoslave » Wed, May 06, 2026, 5:20 AM UTC

wiseowise wrote: post #343

psychoslave wrote: post #309

Earlier quoted context omitted.

You missed the part were everyone is going to run its own vibe coded assembly tools[1]. So the next step will be that bun will be directly re-written from scratch at every iteration, the repository will only contains the specs for the LLMs. Caching locally the generated code will be authorized for some transition period, but as it’s obviously very dangerous to let people tweak what exactly computers are doing, forbid…

Democratizing knowledge btw

Not sure I understand what you mean here.

Re: Zig → Rust porting guide

#557

Post by satvikpendem » Wed, May 06, 2026, 6:17 AM UTC

LinusU wrote: post #480

satvikpendem wrote: post #470

Earlier quoted context omitted.

Well yeah, it's in Zig, not a memory-safe language, so of course I'd expect memory leaks. That's why I haven't seriously used bun and instead use a runtime that actually is in a memory-safe language, Deno in Rust. It's like wearing roller skates without brakes and wondering why you keep running into things.

Memory safety has nothing to do with memory leaks, and it's perfectly valid to leak memory in Rust? e.g. `Box::leak(Box::new( ... ))`

Generally it's automatically dropped unless you go out of your way to use the leak function, which most software doesn't do.

Re: Zig → Rust porting guide

#558

Post by someone654 » Wed, May 06, 2026, 7:09 AM UTC

jillesvangurp wrote: post #306

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…

I've been targeting Go instead of Rust for a few things. But same deal, I'm not really a Go programmer and it seems to work well enough. I do have a few decades of engineering all sorts of code bases; so I'm not coming at this completely naively. My way of compensating for my own inability to do detailed code reviews is making sure the tests, integration tests, end to end tests, cover everything I care about. Without…

I have the same experience. Maybe I’ve used the same amount of time getting the rewrite out, but the amount of quality checking have increased for me. Before, I would probably not bother to create end to end tests and benchmarks, but now the mental cost for being extra vigilant is so cheap.

My rewrite is running stable in production for two weeks with 50x speedup, which have made the doomed old solution viable again.

Wonder what this will mean for future legacy projects and how how we should structure the programs to be inside “rewrite with llm”-size? Maybe a renessanse for microservices?

Re: Zig → Rust porting guide

#559

Post by vga1 » Wed, May 06, 2026, 8:25 AM UTC

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…

Might be a good idea to let AI handle social media. I'm not saying you're doing it badly, just that it doesn't seem like worth the drained energy to do manually.

Re: Zig → Rust porting guide

#560

Post by wtetzner » Wed, May 06, 2026, 9:49 AM UTC

merlindru wrote: post #540

wtetzner wrote: post #392

Earlier quoted context omitted.

The JavaScript developers are checking in JavaScript code that they ostensibly understand. That is not the same as prompting an LLM to generate Zig that they don't understand, and expecting someone to merge it.

ah, i see what you're saying. fair point! though the argument was that LLMs essentially are a yet higher level programming language (or, rather, let you write in a higher level language).

They do let you write in a higher-level language, but it's not really analogous to a higher-level programming language. The ambiguity and lack of determinism makes prompting fundamentally different from using a high level programming language.