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

391–400 of 592 posts

Re: Zig → Rust porting guide

#391

Post by Hendrikto »

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.

The Zig maintainers did a pretty in-depth review of the PR, and laid out multiple technical reasons for why it would not get merged. They did not reject it simply for being vibe-coded (though that is likely the cause of it sucking).

Re: Zig → Rust porting guide

#392

Post by wtetzner »

merlindru wrote: post #357
gertop wrote: post #215

Earlier quoted context omitted.

Your analogy falls apart because the "lazy bastards" still knew how to program and understood the code they were working on. Vide-coders often don't read, let alone understand, the code they send for PRs.

I don't think most JavaScript devs know how to read C code, let alone assembly, so I think the comparison is apt. Is it not?

The JavaScript developers are checking in JavaScript code that they ostensibly understand. That is not the same as prompting an LLM to generate Zig that they don't understand, and expecting someone to merge it.

Re: Zig → Rust porting guide

#393

Post by xigoi »

brabel wrote: post #374
xigoi wrote: post #277

Earlier quoted context omitted.

The main difference is that the input to an LLM is in an ambiguous language.

A programming language is allowed to be ambiguous, I don’t know of a definition that excludes that!

All programming languages I know of provide at least some guarantees about the program’s behavior.

Re: Zig → Rust porting guide

#394

Post by Hendrikto »

DeathArrow wrote: post #246
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.

>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. And will Rust team accept their vibe coded patches?

Very likely not, if they are of similarly low quality.

Re: Zig → Rust porting guide

#396

Post by stingraycharles »

elktown wrote: post #370
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…

"Show me the incentive and I'll show you the outcome" is usually the overarching law of software dev/design/arch.

What do you mean with that in this context?

Re: Zig → Rust porting guide

#397

Post by asG1298 »

I mean this is self-evident. Bun got bought by Anthropic to shill in the open source space:

https://bun.com/blog/bun-joins-anthropic

"I got obsessed with Claude Code"

So the bad, bad Zig that opposes the clanker mania has to be punished, even if top comments deny it.

Anthropic is one of the most evil companies in existence today. Whenever someone produces something, they steal it.

Re: Zig → Rust porting guide

#398

Post by Tehnix »

jeroenhd wrote: post #361
alethic wrote: post #320

Earlier quoted context omitted.

In the context of this post, that's absolutely hilarious they're vibe-porting their Zig codebase to Rust . I love Rust, but you couldn't pick a language with slower compile times... XD

Compiling Rust is actually quite fast in my experience. The problem with many Rust projects is that they pull in dependencies left, right, and center. Pulling in Tokio makes your project compile an entire thread management system even if you're just compiling Hello World, and simple oneliners containing macros can easily spread out into dozens of lines of code each. Linking is also slow, and the extreme amounts of me…

>Compiling Rust is actually quite fast in my experience

I guess it's all relative.

I find Rust's compile times abhorrent and it's objectively slower than many many other languages that also pull in dependencies left, right, and center. I guess that just means Rust scales very badly with amount of code.

I'd put it at a bit better than Haskell, but honestly not by much.

I really wish Rust would focus much more on compile times, or on making smaller parallel compilation units. It's quite a chore to have to keep splitting your program into smaller and smaller crates just to not sit and wait for an eternity.

As a comparison my CI job for Rust takes 14m running on a 16vCPU machine while my much larger TypeScript project compiles in 1m on a 2vCPU machine. I know people that have to spend quite a lot of work on keeping compile times manageable for Rust (nix, smaller crates, aggressive caching, etc etc).

Rust still brings me enough value that I'll stick with it, but one can still dream of a better future :)

Re: Zig → Rust porting guide

#399

Post by sandrello »

brabel wrote: post #273
wtetzner wrote: post #200

Earlier quoted context omitted.

Using an LLM isn't analogous to using a higher level language.

That’s funny because it’s exactly, literally the same. The difference is it’s not deterministic. That may be a problem but it’s still a higher level language, just a much higher level language than anything before.

I assume you're some sort of programmer and I genuinely wonder how in the world can someone in good faith downplay non-determinism and ambiguity when talking about a programming language.

High-level languages can certainly yield inefficient code when compiled, or maybe different code among different compilers, but they're always meant to allow their users to know exactly what to expect from what they put together in their programs. I've always considered this a hard fact, I simply cannot wrap my head around working in a way that forces me to abandon this basic assumption.

Re: Zig → Rust porting guide

#400

Post by 0xpgm »

kelnos wrote: post #236
kgeist wrote: post #71

Interesting how times have changed. Back in 2015, the entire Go runtime (already a mature codebase) was rewritten from C to Go semi-automatically: one of the maintainers wrote a C-to-Go conversion tool (for a subset of C they used) so that it compiled and produced identical output, and then the resulting code was manually refactored to make the Go code more idiomatic and optimized. And now you can just ask a language…

The big difference here is that the C-to-Go tool was presumably deterministic: running it over and over again should produce the exact same result. You can trust that result because the human wrote the conversion tool, understood it, tested it, and worked the bugs out. The LLM is non-deterministic. You could have it independently do the conversion 10 times, and you'd get 10 different results, and some of them might e…

Perhaps a viable approach might be to vibe code the translation tool itself and observe that for every input it gives the expected output. Then once the translation is done, the translation tool can be discarded.

This would require a robust test suite though.

One of the cases where vibe coding might actually be useful, writing a throwaway tool.

Post reply on HN