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

141–150 of 592 posts

Re: Zig → Rust porting guide

#141

Post by efficax »

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.

this is an interesting idea and i might try it with something smaller. there are more than 15,000 commits to bun, so you’d have to have some sort of way to operate on groups of commits in one prompt to get that done without thousands and thousands of api requests

Re: Zig → Rust porting guide

#142

Post by Capricorn2481 »

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

Re: Zig → Rust porting guide

#143

Post by Capricorn2481 »

lioeters wrote: post #120
ratstew wrote: post #74

This feels more like a reaction to Zig's anti-LLM policy than anything. Anthropic would probably like to contribute something back to Zig at some point, but I doubt anyone would ever believe their PRs were not written by Claude.

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.

Re: Zig → Rust porting guide

#144

Post by gschizas »

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

All language is "coined terms". The point is that if you dilute the definition of a term, you make the term useless. Evolution of a term isn't done automatically. Correcting terms such as these pushed the evolution in a more useful way. Also, evolution of language is not a magic spell that automatically forgives people on making language mistakes.

Re: Zig → Rust porting guide

#145

Post by wg0 »

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.

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

Re: Zig → Rust porting guide

#146

Post by abacadaba »

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.

seems easier to fork zig

Re: Zig → Rust porting guide

#148

Post by cybercatgurrl »

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.

good, more reason to stay away from zig

Re: Zig → Rust porting guide

#149

Post by simonw »

classicposter wrote: post #133

https://github.com/oven-sh/bun/issues/30197 It seems there was an issue where the image API ignored the ICC Profile.(now fixed) Any developer with experience implementing image formats would almost certainly avoid this mistake. This is a problem that cannot be solved with vibe coding. In this situation, the user is merely a guinea pig for bug fixes.

... and that bug was spotted in the canary release, reported and fixed.

Sounds like responsible open source software development to me. That's what pre-releases are for.

Re: Zig → Rust porting guide

#150

Post by ai_critic »

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)

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).
Post reply on HN