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

261–270 of 592 posts

Re: Zig → Rust porting guide

#261

Post by dathinab »

kajaktum wrote: post #243
nicce wrote: post #238

Earlier quoted context omitted.

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

Well…there would still be panics.

most unsafe language to rust transpilations produce not just pretty terrible rust code but also use unsafe everywhere

which is needed, as making things safe often requires refactoring not localized to a single function/code block and doing that while transpiling isn't the best idea. In general I would recommencement a non LLM based transpilation (if possible) and then use an LLM to do bit by bit as localized as possible bottom up refactoring to get ride of unsafe code potentially at some runtime performance cost, followed by another top down refactoring to make thing nice and fast. And human supervision to spot parts where paradigms clash so hard that you have to do some larger changes already during the bottom up step.

anyways that means segfaults likely would stay segfaults in the initial transpilled version

Re: Zig → Rust porting guide

#262

Post by faangguyindia »

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…

anthropic just wanted to "codex" like bragging rights of codex being developed in rust. so they are now going to write bun in rust, and then claudecode can use claim to be built on rust.

Re: Zig → Rust porting guide

#263

Post by SkiFire13 »

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.

> but were prevented from doing so because zig has a hard and fast "no AI code" rule

The patch would have been rejected either way because it was out of date and conflicted with other work going on.

Re: Zig → Rust porting guide

#264

Post by moomoo11 »

Dylan16807 wrote: post #216
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/

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

I mean in an authoritarian system you wouldn’t make a one off exception like that.

Re: Zig → Rust porting guide

#265

Post by moomoo11 »

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…

> It could be just that I am less familiar with Rust so it feels like it's doing a better job.

Dunning Kruger effect. At least you admit it.

Re: Zig → Rust porting guide

#266

Post by J_Shelby_J »

echelon wrote: post #155
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?

Rust is legit one of the best languages to "vibe code" in. The emitted AST has a lower defect rate since it incorporates strong types and in-built error handling. Other pros include native code and portability, but downside is the compile time.

Downside: CC and Codex will write, compile, and fix in a loop until it has a monstrosity rather than designing something smarter.

Re: Zig → Rust porting guide

#267

Post by dolebirchwood »

rzmmm wrote: post #255
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…

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

Thanks. That helps us know not to take Wiktionary seriously.

Re: Zig → Rust porting guide

#268

Post by dolebirchwood »

kelnos wrote: post #231
brailsafe wrote: post #116

Earlier quoted context omitted.

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 co…

> Then "vibe coding" is a useless term

You're absolutely right.

Re: Zig → Rust porting guide

#269

Post by DeathArrow »

uncircle wrote: post #237
lowbloodsugar wrote: post #191

Earlier quoted context omitted.

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.

>The ones that still understand assembly to this day tend to be better developers, writing faster and more efficient code.

That is if you use something like C, C+=, Java, .NET, Go. With Javascript and Python I don't think knowing assembly would make any difference because it's hard to optimize the code in these languages for how the CPU and memory works.

Re: Zig → Rust porting guide

#270

Post by andriamanitra »

toshinoriyagi wrote: post #225
reissbaker wrote: post #6

Earlier quoted context omitted.

Probably an experiment due to Bun's PRs to Zig being rejected (Zig does not allow AI use). If Rust works well enough, and the alternative is maintaining a fork of Zig, I'd guess they'd go with Rust.

The anti-AI policy had nothing to do with Bun's PRs being rejected. This post[0] by a core zig maintainer explains why the PRs were low quality and subsequently rejected. [0] https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...

Was there even a PR? The post from Bun [1] says they have no plan to upstream it, and that ziggit post says the changes are undesirable. It sounds like there never was anything to reject.

[1] https://x.com/bunjavascript/status/2048428104893542781

Post reply on HN