Live data from Hacker News

Zig → Rust porting guide

github.com

61–70 of 592 posts

Re: Zig → Rust porting guide

#61
post #13

Earlier quoted context omitted.

> what looks like a massive undertaking for vibe coding It doesn’t look like that at all. Do you think that all use of AI is vibe coding?

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

The blind leading the blind.

Re: Zig → Rust porting guide

#62

Earlier quoted context omitted.

I imagine claude is better at Rust than Zig?

Contributors and maintainers will also be easier to find in Rust than Zig. Zig is a great language and I want to see it succeed, but this is a prudent move for Bun.

Why didn't they use Rust in the first place then ? All this was true before AI

Re: Zig → Rust porting guide

#64

>*No `tokio`, `rayon`, `hyper`, `async-trait`, `futures`.* No `std::fs`, I'm not a rust dev but even I kind of notice that tokio is kind of shunned in most projects. Why is that? Is it just bad or what?

Async is an anti-pattern but sometimes inexperienced developers don't realize that and will infect your codebase with it.

Re: Zig → Rust porting guide

#65

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…

Honestly, this kind of thing seems to work quite well with vibe coding. If I remember correctly, the Ladybird JS engine was "vibe-ported" to Rust as well, and it passed 100% of the original test suite, in addition to new Rust tests.

Re: Zig → Rust porting guide

#66

Earlier quoted context omitted.

I don't think Zig is different enough from rust or any other systems language for it to matter. If you can write rust you can write Zig.

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.

Re: Zig → Rust porting guide

#67

Earlier quoted context omitted.

I imagine claude is better at Rust than Zig?

Zig is a moving target. 0.15 -> 0.16 includes some massive structural changes concerning IO and async/threading. Claude has absolutely no idea what it's doing with bleeding edge zig unless you feed it source and guide it closely (in which case it's useful for focused work) - I'm building a game engine & tcp/udp servers with it and it requires a hands-on approach and actually understanding what's being built. I imagin…

> it requires a hands-on approach and actually understanding what's being built.

I think this is true regardless of what language you’re using.

I’ve built a lot in Zig and there’s no difference between vibing stuff in it versus TypeScript/React. Claude can “one-shot” them both, and will mimic existing code or grep the standard library to figure everything out.

Re: Zig → Rust porting guide

#68

Earlier quoted context omitted.

Contributors and maintainers will also be easier to find in Rust than Zig. Zig is a great language and I want to see it succeed, but this is a prudent move for Bun.

I don't think Zig is different enough from rust or any other systems language for it to matter. If you can write rust you can write Zig.

I'm reminded of the old joke "how to shoot yourself in the foot in 25 different languages". The first one was "C - you shoot yourself in the foot." Zig remains very close to that philosophy.

So the difference is not in writing new stuff but in maintaining the existing codebase. Rust's rigidity makes it potentially harder to break stuff compared to Zig's general flexibility. As a project grows and matures, different types of contributors naturally come in and it's unreasonable to expect everyone to learn about historical footguns that may have accumulated.

Re: Zig → Rust porting guide

#69
post #23
post #7

Earlier quoted context omitted.

Porting from one typed language to another seems like a perfect use for LLMs. I can see the appeal of both languages and why to consider such an action (e.g., rust is a mainstream PL vs zig's cult status (no slight intended)).

I think the big difficulty here is that Rust's ownership model in particular tends to require certain kinds of control flow to avoid a bunch of weird churning/copying, which makes it not as straightforward of a port target from other imperative languages. Like maybe you get the LLM to try _really hard_ to churn through everything, but this feels like a big case of "perils of the lack of laziness". Of course if you ha…

This is all wild conjecture, but I'd assume that teaching the LLM to do that mapping is an achievable goal and then it get's close to automatic -- effectively slurp the source AST into a rust AST and render.

My only experience with ports so far is Python to Go, and it's been near flawless (just enough stupid shit to make me feel justified to be in the loop).

Re: Zig → Rust porting guide

#70
post #13

Earlier quoted context omitted.

> what looks like a massive undertaking for vibe coding It doesn’t look like that at all. Do you think that all use of AI is vibe coding?

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

I'm sure it will be called Systems Programing . Because Rust.
Post reply on HN