Live data from Hacker News

Zig → Rust porting guide

github.com

21–30 of 592 posts

Re: Zig → Rust porting guide

#21

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.

This is likely irrelevant given bun has stopped taking community PR's entirely and Jarred is pitching that human contributors should be banned.

Re: Zig → Rust porting guide

#22

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.

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.

Re: Zig → Rust porting guide

#23
post #7

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…

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 have a good idea for how to deal with allocations etc "idiomatically" already maybe that works out well. And to the credit of the port guide writer bun seems to have its explicit allocations that are already mapping pretty well to Rust.

Re: Zig → Rust porting guide

#24
post #13

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…

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

It depends on what you mean by "vibe coding". Is AI coding based on an existing implementation vibe coding? What about only from a natural-language spec? How does manual reviewing affect whether or not it's vibe coding?

Re: Zig → Rust porting guide

#25

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…

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 imagine these are not really concerns with rust at this point.

In my ideal world the team behind bun would be putting in the work to keep up with modern zig, but it's starting to look like they are running mostly on vibes in which case rust might be a better choice.

Re: Zig → Rust porting guide

#26
post #13

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…

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

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.

Re: Zig → Rust porting guide

#27
post #13

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…

> 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

Re: Zig → Rust porting guide

#29
post #12
post #3

Why? Are there particular reasons that the maintainers of Bun feel the need to attempt to migrate from Zig to Rust?

Zig is a moving target that has breaking changes in every release (which is fine as they are sub-1.0). But that means that AI tools have been trained on outdated syntax/etc. Zig isn't that common, so there is even less training data to begin with. Rust on the other hand is pretty established by now and has less breaking changes. It also has more compile-time safety-guarantees that makes vibe-coding a bit more confide…

Most of my vibe coding is in zig, and it has been my experience that Claude and Codex both keep up with zig changes just fine. Every now and then I catch them writing outdated code that they burn some tokens on, but my experience says your local codebases’s idioms will influence what gets generated enough to stop this from being a problem.

Re: Zig → Rust porting guide

#30

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.

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 because you control the language spec.

Post reply on HN