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

251–260 of 592 posts

Re: Zig → Rust porting guide

#251

Post by pineapple_opus »

markatto wrote: post #123
lmm wrote: post #26

Earlier quoted context omitted.

In practice all use of AI rapidly becomes vibe coding. Even if someone says they're going to carefully manually review everything that's generated, within a couple of days they get bored and just click approve.

This is just a matter of priorities - I use LLMs to write code every day and I have never put a single line of code up for review that I didn’t read and understand.

I use to do this and then do test manually to validate everything works as expected in my small open source project. But then over the time I saw that some bugs crept in which I was unable track since I was doing manual testing. So I wrote some e2e tests with playwright and I think that gives a bit relief (at least).

Re: Zig → Rust porting guide

#252

Post by [deleted] »

kelnos wrote: post #176
ratioprosperous wrote: post #132

Earlier quoted context omitted.

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.

[deleted]

Re: Zig → Rust porting guide

#253

Post by woodruffw »

DeathArrow wrote: post #249
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)

>Makes me wonder why zig announced the strict LLM rule recently. I guess there are 2 philosophies in software development: move fast and break things and move at a pace that guarantees everything is rock solid. Most commercial software, Anthropic included is taking the former path, while most infrastructure teams are taking the later. I guess Linux and FreeBSD kernels are also not accepting LLM based contributions ye…

> I guess Linux and FreeBSD kernels are also not accepting LLM based contributions yet.

Both appear to be[1][2]. FreeBSD doesn't have a formal policy yet, but they appear to be leaning towards admitting some degree of LLM contribution.

[1]: https://docs.kernel.org/process/coding-assistants.html

[2]: https://forums.freebsd.org/threads/will-freebsd-adopt-a-no-a...

Re: Zig → Rust porting guide

#254

Post by giancarlostoro »

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.

Probably moreso going with the native language that is reliable and battle tested. Rust runs on Firefox, and in production at several systems across major orgs, this is not surprising.

Re: Zig → Rust porting guide

#255

Post by rzmmm »

nailer wrote: post #103
WD-42 wrote: post #98

Earlier quoted context omitted.

Did you look at the branch? This is vibed, even with the most liberal definition https://github.com/oven-sh/bun/compare/claude/phase-a-port This single commit is 65k lines of additions https://github.com/oven-sh/bun/commit/ffa6ce211a0267161ae48b...

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…

Here is the Wiktionary definition for curiosity.

> (programming, neologism) A method of programming in which a developer generates code by repeatedly prompting a large language model.

https://en.wiktionary.org/wiki/vibe_coding

Re: Zig → Rust porting guide

#256

Post by Dylan16807 »

bboozzoo wrote: post #250
Dylan16807 wrote: post #216

Earlier quoted context omitted.

That's a solid reason to keep LLMs away from the kind of tasks that help with onboarding. But a patch series from a competent team that changes 3000 lines should probably be evaluated on its own merits. Or at least, the collaboration-based reasons to reject AI don't apply and the real reason would be something else. (Though I don't know if this particular patch series would get accepted on its own merits.)

> 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.

Re: Zig → Rust porting guide

#257

Post by sevenzero »

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.

I see that as a win for Zig.

Re: Zig → Rust porting guide

#258

Post by dathinab »

mswphd wrote: post #180
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.

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.

zig can do some things wrt. compiler time compute which sits somewhere in between rust const expr and proc macro usage. This isn't something rust (or most languages) have. So even if we are generous and interpret line by line as expression by expression this isn't fully doable

but also telling a LLM to do a line-by-line translation and giving it a file _is guaranteed to never truly be a line-by-line translation_ due to how LLMs work. But thats fine you don't tell it to do line-by-line to actually make it work line by line but to try to "convince" it to not do any of the things which are the opposite (like moving things largely around, completely rewriting components based on it "guessing" what it is supposed to do etc.). Or in other words it makes the result more likely to be behavior (incl. logic bug) compatible even through it doesn't do line-by-line. And that then allow you to fuzz the behavior for discrepancies in the initial step before doing any larger refactoring which may include bug fixes.

Through tbh. I would prefer if any zip -> terrible rust part where done with a deterministic, reproducible, debug-able program instead of a LLM. The LLM then can be used to support incremental refactoring. But the initial "bad" transpilation is so much code that using an LLM there seems like an horror story, wrt. subtle hallucinations and similarr.

Re: Zig → Rust porting guide

#259

Post by GCUMstlyHarmls »

esperent wrote: post #230
pton_xd wrote: post #117

Earlier quoted context omitted.

Anthropic just needs to buy Zig! Problem solved.

Perfect A/B experiment opportunity. Fork Zig, call the fork Zag. Lock the syntax/api together for a couple of years. Allow AI code in Zag. Review after a few years, see which is better.

Interesting experiment, would it actually function if Zag was syntax/api locked to Zig? I guess Zag could still have api extensions.
Post reply on HN