How well does that long translation prompt work?
Zig → Rust porting guide
151–160 of 592 posts
Re: Zig → Rust porting guide
#152People are asking why they would switch from zig to rust. I wonder the opposite: why would anyone would use zig over rust?
Re: Zig → Rust porting guide
#153>*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 a general purpose async runtime. Much the same could probably be said for async-std (except IIRC they do have a barebones reactor for you to build your own on). In general, a general-purpose async runtime will do worse for highly specific tasks than a purpose-built one (especially e.g. NUMA). I think avoiding async entirely might be a mistake, and I'm not entirely convinced anything better than a general-pur…
my guess is they want to do AI/O as part of their event loop explicitly, and blocking a thread in a syscall waiting for an IOP (ala std::fs) isn't the vibe.
Re: Zig → Rust porting guide
#154Earlier 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.
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)
One non-obvious reason is that an important aspect of their community is to shepherd new contributors [1]. LLMs crushing everything would reduce that. More obvious is all the toil for maintainers dealing with LLM PRs (broadly it’s an issue). The Zig maintainers prefer to put their energy into improving people and fostering those relationship.
Re: Zig → Rust porting guide
#155Earlier 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.
So if tomorrow Rust denied the "improvement" to upstream Rust then what's the next language they plan to vibe code it in?
Rust is legit one of the best languages to "vibe code" in.
The emitted AST has a lower defect rate since it incorporates strong types and in-built error handling. Other pros include native code and portability, but downside is the compile time.
Re: Zig → Rust porting guide
#156Interesting 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.
Even if AI had not been used, the changes would not have been upstreamed, see https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
tl;dr the supposed improvements are not sound and the zig compiler has already gotten a whole lot faster
Re: Zig → Rust porting guide
#157If nothing, it'll be good marketing material targeted at non-technical enterprise executives so that they pressurize their engineering teams in meetings that look people are porting such complicated things from one different language to totally different language then why are we not using AI effectively?!
Re: Zig → Rust porting guide
#158https://x.com/bunjavascript/status/1966806250827714736 Haha, is it really okay not to retract that that the official account previously posted a caricature criticizing Rust?
Yes, it's quite ok to not "retract" a goofy image from months ago. It's harmless fun.
Re: Zig → Rust porting guide
#159Earlier quoted context omitted.
So if tomorrow Rust denied the "improvement" to upstream Rust then what's the next language they plan to vibe code it in?
Rust is legit one of the best languages to "vibe code" in. The emitted AST has a lower defect rate since it incorporates strong types and in-built error handling. Other pros include native code and portability, but downside is the compile time.
Excellent comment.
As a downside, the compile time is somewhat offset once you're using agents (and especially parallel agents) anyway. Since all of your edits cost a round-trip API call to a third party server, you can accept a slightly slower compile step.
Re: Zig → Rust porting guide
#160it will make it more portable.