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

131–140 of 592 posts

Re: Zig → Rust porting guide

#131

Post by LamaOfRuin »

allthetime wrote: post #27
nailer wrote: 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 commit would look exactly like that if it was a 100% deterministic transpilation (like Golang did with their original C implementation?).

This is obviously very different from that, but the way the commit looks doesn't make it so.

Re: Zig → Rust porting guide

#133

Post by classicposter »

https://github.com/oven-sh/bun/issues/30197

It seems there was an issue where the image API ignored the ICC Profile.(now fixed) Any developer with experience implementing image formats would almost certainly avoid this mistake. This is a problem that cannot be solved with vibe coding. In this situation, the user is merely a guinea pig for bug fixes.

Re: Zig → Rust porting guide

#134

Post by Capricorn2481 »

April 26th - Bun announces they used AI to fork Zig so they could make an optimization for a 4x improvement

April 27th - Zig contributor mlugg clarifies why the specific optimizations Bun did were ill advised and wouldn't have been accepted in Zig, regardless of AI use [1]

May 4 - Bun is looking into Rust as an alternative.

This, to me, seems like total whiplash. Has anyone at Bun made a statement on why they're making such dramatic changes? It seems like the lesson to internalize from mlugg is not "switch to Rust"

[1] https://lobste.rs/s/ifcyr1/contributor_poker_zig_s_ai_ban#c_...

Re: Zig → Rust porting guide

#135

Post by wrs »

andai wrote: post #114
nailer wrote: post #101

Earlier quoted context omitted.

> I suspect it's less of an undertaking than you may think... having an existing codebase you can reference prevents a lot of the problems you have with vibecoding. That's because it's not vibe coding - stingraycharles doesn't seem to understand what vibe coding is. Vibe coding was defined here https://x.com/karpathy/status/1886192184808149383 > There's a new kind of coding I call “vibe coding”, where you fully give…

Yeah, it's a distinction worth making, and the language for making it kind of sucks. Vibe coding means "AI does the whole thing", or "I use tab autocomplete" depending on who you ask. It's not a very useful term anymore, we need better ones. My benchmark is basically, "are you letting the AI drive." In this case, an AI appears to have written the migration guide...

It was and is a perfectly good term, but people started using it without regard for its definition. I don't know why people wouldn't misuse a "better" term the same way.

Re: Zig → Rust porting guide

#136

Post by zamalek »

mmastrac wrote: post #79
sergiotapia wrote: post #36

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

tokio is great and it's pretty performant, but you pay an allocation for every future unless you do some complex organization of your futures. Source: I worked on Deno, competed directly with Bun on HTTP performance (and won on some metrics). Edit: and of course I typed future instead of task (aka "spawned future"). Thanks, child commenters below. Much of Deno was built on spawning futures that mapped to promises and…

You only allocate on box futures, which are much more rare than naked futures - generally only used where object safety (essentially dyn support) is required. Even then some workarounds exist.

Edit: and tasks.

Re: Zig → Rust porting guide

#137

Post by endospore »

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.

Makes me wonder why zig announced the strict LLM rule recently. I'm afraid one reason could be that zig doesn't want to accept code from the bun fork in the first place (because of LLM usage, deviation and other reasons)

Re: Zig → Rust porting guide

#138

Post by c0rruptbytes »

andai wrote: post #114
nailer wrote: post #101

Earlier quoted context omitted.

> I suspect it's less of an undertaking than you may think... having an existing codebase you can reference prevents a lot of the problems you have with vibecoding. That's because it's not vibe coding - stingraycharles doesn't seem to understand what vibe coding is. Vibe coding was defined here https://x.com/karpathy/status/1886192184808149383 > There's a new kind of coding I call “vibe coding”, where you fully give…

Yeah, it's a distinction worth making, and the language for making it kind of sucks. Vibe coding means "AI does the whole thing", or "I use tab autocomplete" depending on who you ask. It's not a very useful term anymore, we need better ones. My benchmark is basically, "are you letting the AI drive." In this case, an AI appears to have written the migration guide...

i mean AI docs are usually the result of collabs between users and AI using /plan

with superpowers, i see a lot of specs -> impl plan -> execute plan

Re: Zig → Rust porting guide

#139

Post by [deleted] »

pizlonator wrote: post #127
kllrnohj wrote: post #77

Earlier quoted context omitted.

I would expect all LLMs are going to be better at Rust than Zig - a strong, thorough compiler will simply prevent more mistakes, and the benefits of a "simple" language decreases the larger the code base gets. The more abstractions exist, the less valuable "no hidden control flow" or "no hidden allocations" from the standard library get, and that's before you add the mother of all abstractions of vibe coding.

I have no doubt that LLMs are good at Rust. But I can’t reconcile the reasoning about “strong, thorough compiler” with the fact that LLMs are also fantastic at Ruby. They also write really great posix shell (including very sophisticated scripts) and python. Something more subtle is going on.

[deleted]
Post reply on HN