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

231–240 of 592 posts

Re: Zig → Rust porting guide

#231

Post by kelnos »

brailsafe wrote: post #116
nailer wrote: post #103

Earlier quoted context omitted.

The definition is at https://x.com/karpathy/status/1886192184808149383 and no that does not match what is in the branch. Systemically migrating a code base using an LLM does not match the defintion of vibe coding. There's a decent article by Simon Willison that talks about this: https://simonwillison.net/2025/Mar/19/vibe-coding/ > I’m seeing people apply the term “vibe coding” to all forms of code written with the as…

This is just a coined term; definitions evolve over time based on usage

Then "vibe coding" is a useless term, if it just means "LLM-assisted coding". We might as well just say "LLM-assisted coding" or "AI coding" or whatever.

As much as I find the word "vibe" generally annoying (in all contexts), I actually really like "vibe coding" as "LLM did everything and I didn't even look at it". It's a succinct, useful way to describe that mode of doing things. Diluting it down to "LLM-assisted coding" makes it useless.

Re: Zig → Rust porting guide

#233

Post by toshinoriyagi »

Petersipoi wrote: post #167
Capricorn2481 wrote: post #142

Earlier quoted context omitted.

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.

Zig won't be affected by Bun potentially moving to Rust, the language has been growing rapidly and one of the main proposals of Zig is "maintain it with Zig". It's ability to integrate with existing C code bases, as well as be a drop-in build replacement, has widespread use.

In addition, the link in the comment you replied to explains why the PRs Bun opened to Zig would have lowered the quality of the compiler and how Zig has achieved even greater speedups, with more widely applicable features like incremental compilation and the self-hosted backend.

Re: Zig → Rust porting guide

#234

Post by [deleted] »

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.

[deleted]

Re: Zig → Rust porting guide

#235

Post by kelnos »

LamaOfRuin wrote: post #131
allthetime wrote: post #27

Earlier quoted context omitted.

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

The commit would look exactly like that if it was a 100% deterministic transpilation (like Golang did with their original C implementation?). This is obviously very different from that, but the way the commit looks doesn't make it so.

The question isn't whether or not you'd get the same line count with a non-LLM tool. The question of whether or not it's vibe-coded depends on whether or not the committer actually reviewed and understood the new code. And with a 75k line difference, that seems unlikely.

Re: Zig → Rust porting guide

#236

Post by kelnos »

kgeist wrote: post #71

Interesting how times have changed. Back in 2015, the entire Go runtime (already a mature codebase) was rewritten from C to Go semi-automatically: one of the maintainers wrote a C-to-Go conversion tool (for a subset of C they used) so that it compiled and produced identical output, and then the resulting code was manually refactored to make the Go code more idiomatic and optimized. And now you can just ask a language…

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 even be wildly different. There's no way to validate that without reviewing it fully, in its entirety, each time.

That's not to say the human-written deterministic conversion tool is going to be perfect or infallible. But you can certainly build much more confidence with it than you can with the LLM.

Re: Zig → Rust porting guide

#237

Post by uncircle »

lowbloodsugar wrote: post #191
neomantra wrote: post #154

Earlier quoted context omitted.

One non-obvious reason is that an important aspect of their community is to shepherd new contributors [1]. LLMs crushing everything would reduce that. More obvious is all the toil for maintainers dealing with LLM PRs (broadly it’s an issue). The Zig maintainers prefer to put their energy into improving people and fostering those relationship. [1] https://kristoff.it/blog/contributor-poker-and-ai/

Yeah, I remember when the lazy bastards started writing programs using compilers instead of learning assembly language. Now I don’t have a single colleague who can write assembly. There’s whole generations now who can’t code assembly. Most don’t even know what a register is. Hope Zig holds against this latest attempt to make everyone stupid.

To add to the other commenters, loads of people don’t know assembly, which speaks to the quality of the average developer. The ones that still understand assembly to this day tend to be better developers, writing faster and more efficient code.

Re: Zig → Rust porting guide

#238

Post by nicce »

tacitusarc wrote: post #99

I wonder if a successful, albeit slower, approach would be to walk the git commit history in lockstep, applying the behavioral intent behind each commit. If they did this, I would be interested in knowing if they were able to skip certain bug fix commits because the Rust implementation sidestepped the problem.

Many segfaults in Bun issue tracker. I bet it would sidestep many.

Re: Zig → Rust porting guide

#239

Post by padjo »

Picking a pre 1.0 language to build your product always seemed like a bad choice to me. Purely on that basis and ignoring the recent drama this seems like a reasonable idea for tech debt pay down to me. Assuming automated conversion can work without making things worse, which is not exactly a given.

Re: Zig → Rust porting guide

#240

Post by kelnos »

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

Earlier quoted context omitted.

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.

Even if there was anything in private channels, the reasons stated in that forum post are alone more than enough to reject Bun's Zig changes.
Post reply on HN