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

71–80 of 592 posts

Re: Zig → Rust porting guide

#71

Post by kgeist »

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 model.

The slides: https://go.dev/talks/2015/gogo.slide#3

An interesting similarity:

>We had our own C compiler just to compile the runtime.

The Bun team maintain their own fork of Zig too

Re: Zig → Rust porting guide

#72

Post by jabedude »

versecafe wrote: post #21
fcarraldo wrote: post #19

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.

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

Where is a source for either of these extraordinary claims?

Re: Zig → Rust porting guide

#74

Post by ratstew »

This feels more like a reaction to Zig's anti-LLM policy than anything. Anthropic would probably like to contribute something back to Zig at some point, but I doubt anyone would ever believe their PRs were not written by Claude.

Re: Zig → Rust porting guide

#75

Post by vips7L »

philwelch wrote: post #50
sourcegrift wrote: post #28

Earlier quoted context omitted.

[flagged]

Normal, emotionally stable people don’t care if the creators of a programming language disagree with them about tariffs.

Normal, emotionally stable people don’t drive business towards people they disagree with politically. You see that all around the country.

Re: Zig → Rust porting guide

#77

Post by kllrnohj »

Avicebron wrote: post #8
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…

I imagine claude is better at Rust than Zig?

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.

Re: Zig → Rust porting guide

#79

Post by mmastrac »

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 doing it as fast as possible. I spent ages writing a future arena to optimize this stuff..

Post reply on HN