Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Our Rust-to-Zig Rewrite Is Going

rtfeldman.com

Post reply on HN
Print view View original

211–220 of 336 posts

Re: How Our Rust-to-Zig Rewrite Is Going

#211

Post by feelamee »

> As discussed earlier, having full control over allocations and deallocations is what I want in our compiler's implementation. And in tests, I also appreciate the testing allocators detecting leaks—it can even detect leaks in compiled Roc code! Unfortunately, to get that benefit requires a lot of "init this, defer deinit" code in tests that has to be correct or else the test fails on a memory leak. None of that is necessary in Rust. I care more about the compiler's implementation being the way I want it than the tests looking nicer, but in a perfect world I could somehow have both.

haha, just for fun... do you want a C++ in your perfect world :D?

Re: How Our Rust-to-Zig Rewrite Is Going

#212

Post by skhameneh »

echelon wrote: post #134
up2isomorphism wrote: post #18

I think there will be soon a wave of rewriting rust to language X coming up.

The other way around. Rust is also one of the best languages to use with AI.

I like Rust and I'm an advocate of Rust, but this really isn't true (at least it hasn't been and I doubt much has significantly changed).

The syntax complexity and the ecosystem haven't been ideal for LLM development. And there have been publications on findings of LLM efficacy with different languages. Rust is most often towards the lower end of efficiency/correctness when benchmarked.

https://arxiv.org/html/2508.09101v1

Re: How Our Rust-to-Zig Rewrite Is Going

#214

Post by steveklabnik »

skhameneh wrote: post #212
echelon wrote: post #134

Earlier quoted context omitted.

The other way around. Rust is also one of the best languages to use with AI.

I like Rust and I'm an advocate of Rust, but this really isn't true (at least it hasn't been and I doubt much has significantly changed). The syntax complexity and the ecosystem haven't been ideal for LLM development. And there have been publications on findings of LLM efficacy with different languages. Rust is most often towards the lower end of efficiency/correctness when benchmarked. https://arxiv.org/html/2508.09…

This paper uses models that are over a year old at this point. Many people didn't believe that LLMs were worth using for programming until 6 months after that, and now again this week we've had another huge leap in abilities.

This is beyond the other issues with the methodology of this study. For example, their Rust code was created by asking Deepseek to port their C++ code, not having it try and write Rust itself.

Re: How Our Rust-to-Zig Rewrite Is Going

#215

Post by yencabulator »

surajrmal wrote: post #102
steveklabnik wrote: post #52

Earlier quoted context omitted.

> probably be a linker I don't think that's any different either. The core job of linking isn't particularly unsafe. (Unless, similarly, you're doing the hot reloading stuff)

Perhaps the parent meant dynamic linker.

It wouldn't be the linker that has to be unsafe, it'd be the "and now execute!" jump. And that could be abstracted as memfd+execveat, which are fairly normal operations.

OP's argument is roughly "doings things with computers has to be unsafe to be useful", which is.. uninteresting.

Re: How Our Rust-to-Zig Rewrite Is Going

#216

Post by senderista »

jandrewrogers wrote: post #203
sph wrote: post #167

Earlier quoted context omitted.

I don’t think there’s too many of us on the ‘GC did nothing wrong’ hill. Reading the average HN opinion, it seems everybody is writing high-performance latency-sensitive systems that would implode if a response would take 1 ms longer than normal.

Sampling bias. Most of the people responding are probably those with a strong opinion because of what they work on. Everyone else is likely relatively indifferent to it. It is a misconception that GCs only affect latency-sensitive systems. High-performance throughput-optimized systems are also sensitive at ~1µs granularity for different reasons, so GCs are not used there either. That a GC is adverse to the performanc…

Not to mention that in general GC simply requires more memory.

Re: How Our Rust-to-Zig Rewrite Is Going

#217

Post by landr0id »

azakai wrote: post #204
veber-alex wrote: post #41

Earlier quoted context omitted.

I believe you are correct. I think ReleaseSafe just adds bound checking and panics on unreachable code. I don't think Zig offers any temporal memory safety.

Zig does offer some amount of temporal memory safety. Link: https://zig.guide/standard-library/allocators/ Text: > The Zig standard library also has a general-purpose debug allocator. This is a safe allocator that can prevent double-free, use-after-free and can detect leaks. For more detail, see: https://github.com/ziglang/zig/issues/3180#issuecomment-5284...

I still don't think that does anything regarding use-after-frees, only double-frees.

Here's the code: https://codeberg.org/ziglang/zig/src/commit/e44e927d33d37c44...

The closest callout in the doc comment is:

>Never reuses memory addresses, making it easier for Zig to detect branch on undefined values in case of dangling pointers. This relies on the backing allocator to also not reuse addresses.

But it's not really clear what this means. "branch on undefined values" would I think indicate that maybe they're doing a fill pattern that the compiler can detect at runtime when dereferenced? But I don't see it in the `free` path. It's not clear if this is deterministic or not either.

Re: How Our Rust-to-Zig Rewrite Is Going

#218

Post by senderista »

jandrewrogers wrote: post #203
sph wrote: post #167

Earlier quoted context omitted.

I don’t think there’s too many of us on the ‘GC did nothing wrong’ hill. Reading the average HN opinion, it seems everybody is writing high-performance latency-sensitive systems that would implode if a response would take 1 ms longer than normal.

Sampling bias. Most of the people responding are probably those with a strong opinion because of what they work on. Everyone else is likely relatively indifferent to it. It is a misconception that GCs only affect latency-sensitive systems. High-performance throughput-optimized systems are also sensitive at ~1µs granularity for different reasons, so GCs are not used there either. That a GC is adverse to the performanc…

Could you elaborate on "GCs are not used there [high-performance throughput-optimized systems]"? Are you referring to the cascading effects of tail latency on systems with high fanout?

Re: How Our Rust-to-Zig Rewrite Is Going

#219

Post by drdexebtjl »

uaksom wrote: post #175
drdexebtjl wrote: post #97

Earlier quoted context omitted.

I invite you to read the release notes and see for yourself the types of breaking changes we’re talking about. To me it is not much different from Lua, which despite being on 5.x for decades, makes breaking changes on minor releases (because it predates SemVer). I also don’t see it being much different from any other language or language runtime that has a major release every year. It’s fine to update at your own pac…

> I invite you to read the release notes and see for yourself the types of breaking changes we’re talking about. I did, and I immediately found this in the latest release: https://ziglang.org/download/0.16.0/release-notes.html#IO-as... That seems like it would require changing a lot of code. Calling it "production ready" is dishonest at best

Not really. It’s find and replace work.

If by production-ready you mean you can forever avoid changing code you wrote 8 months ago, sure, pick something else.

To me production-ready means it can be trusted to power production workloads, has all tooling I need, and has a consistent long-term vision. Zig ticks all the boxes.

Re: How Our Rust-to-Zig Rewrite Is Going

#220

Post by samatman »

minraws wrote: post #93
rtfeldman wrote: post #74

Earlier quoted context omitted.

Also a good point! TIL that Rust and C++ use interpreters for const, although of course that wouldn't work for running tests. Then again, in the specific case of Rust I believe rustc only compiles the tests and then something else like Cargo executes them. Of course, as I noted elsewhere, if rustc emits machine code and then cargo immediately executes it, there's the same opportunity for end user memory being corrupt…

I would like to understand this more, > rustc emits machine code and then cargo immediately executes it, there's the same opportunity for end user memory being corrupted (due to miscompilation) as if rustc and cargo shared a code base. Cause this hasn't been true for me or for anyone maybe your definition of memory being corrupted is the not same as mine. I am not even sure what you are trying to prove with this. I a…

Scenario A: A program has a memory vulnerability. That's bad, and the reason it's bad: attacker-controlled data can potentially trigger this vulnerability, which could even lead to privilege escalation.

Scenario B: A program writes machine code in an executable region of memory, and the code has a memory vulnerability. That's bad, and the reason it's bad: attacker-controlled data can potentially trigger this vulnerability, which could even lead to privilege escalation.

Scenario C: A program write machine code to disk, which is then read into memory and executed. That's bad, and the reason it's bad: attacker-controlled data can potentially trigger this vulnerability, which could even lead to privilege escalation.

Post reply on HN