Live data from Hacker News

Zig → Rust porting guide

github.com

31–40 of 592 posts

Re: Zig → Rust porting guide

#31

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.

100%. For many people, Bun is the only reason they've even heard of Zig. I'm not in a position to comment intelligently on comparative language features per se, but when it comes to mindshare and community size, Rust is a clear winner.

Re: Zig → Rust porting guide

#32

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…

[deleted]

Re: Zig → Rust porting guide

#34
post #26
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?

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.

Not to mention that manually writing code is itself a process of understanding. It cannot be replicated by reading code, no matter how carefully.

Re: Zig → Rust porting guide

#37
post #26
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?

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.

While I'm sure you're speaking for many, this is definitely not true across the board.

Re: Zig → Rust porting guide

#38

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…

But why should they? This just seems like the groundwork for an initial refactor and moving from one language to another. They haven't actually committed to switching from Zig to Rust yet. I mean, I get if you are an investor and you want to see if they are using their time effectively, but why would it matter to anyone else?

They’re not required to do so, but like I said, it would be nice, because it removes a lot of speculation. And development is in the open, so people notice what they’re doing.

Re: Zig → Rust porting guide

#40

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 does not struggle with zig? not in my hands anyways.
Post reply on HN