How Our Rust-to-Zig Rewrite Is Going • Hacker News Board

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

#41

Post by veber-alex » Thu, Jul 16, 2026, 4:12 PM UTC

landr0id wrote: post #12

>ReleaseSafe catches use-after-free errors through runtime checks which panic if the program tries to use freed memory. I don't know Zig so maybe they know something I don't, but I have seen no evidence that it catches any type of use-after-free including double-free? While writing a blog post (below) I went through the documentation to figure out the possible runtime memory safety checks Zig can insert. The term "us…

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.

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

#42

Post by [deleted] » Thu, Jul 16, 2026, 4:13 PM UTC

EPWN3D wrote: post #28

steveklabnik wrote: post #11

I think this is a fine post. But one comment: > remember that for compilers which emit machine code, like roc and rustc, doing memory-unsafe things is a big part of the job I don't really think that this is true, in the way that it's written. I think that for the hot binary patching / code reloading features, yes, that is going to need unsafe. But for regular old "producing an executable" compilation? Emitting machin…

Yeah that is definitely 1000% wrong. A compiler can do its job with totally abstract data structures. If anything would need to do unsafe stuff in memory, it would probably be a linker.

[deleted]

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

#43

Post by jdw64 » Thu, Jul 16, 2026, 4:14 PM UTC

[dead]

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

#44

Post by drdexebtjl » Thu, Jul 16, 2026, 4:14 PM UTC

dev_l1x_be wrote: post #19

Zig is a pre-1.0 language while Rust is post-1.0. This alone is settles which one to pick for may developers. The library support is probably favours Rust too. Rust build times are much slower than Zig, I get that, but I rarely optimize software for build times.

Zig is not pre-1.0 because it’s not ready for production (bugs or missing features), it’s pre-1.0 because they want to be able to make breaking language changes.

Nowadays when you can just point an agent at release notes and have it update everything, I actually prefer not having to wait through rare major releases to get new language features.

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

#45

Post by djha-skin » Thu, Jul 16, 2026, 4:17 PM UTC

satvikpendem wrote: post #26

grayrest wrote: post #23

Earlier quoted context omitted.

One of the primary goals for the Roc project is compiler speed. I presume OCaml is out of the running because it's not a systems language.

OCaml compiler is incredibly fast. I wonder how it'd fare with Jane Street's extensions for the borrow checker etc in OxCaml, if it's good enough for their HFT I'm sure it's good enough for a new language.

I suspect this "not a systems language" alludes only to OCaml's rather steeper learning curve and until-recently difficulty with multiple threads. I am sure it could roll just fine as a single-threaded compiler language written by a small team, which indeed, it was.

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

#46

Post by flohofwoe » Thu, Jul 16, 2026, 4:17 PM UTC

veber-alex wrote: post #41

landr0id wrote: post #12

>ReleaseSafe catches use-after-free errors through runtime checks which panic if the program tries to use freed memory. I don't know Zig so maybe they know something I don't, but I have seen no evidence that it catches any type of use-after-free including double-free? While writing a blog post (below) I went through the documentation to figure out the possible runtime memory safety checks Zig can insert. The term "us…

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.

The DebugAllocator catches use-after-free (at least on page-level), but at the cost of never recycling memory addresses (e.g. it eats through the virtual address space).

https://ziglang.org/documentation/master/std/#src/std/heap/d...

For higher level code, "generation-counted index handles" might be the better solution to provide temporal runtime memory safety, not part of Zig the stdlib though.

Or even better: never use dynamic memory allocation and make all lifetimes 'static' :)

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

#47

Post by pjmlp » Thu, Jul 16, 2026, 4:18 PM UTC

Quite interesting the hand waving of security issues with Zig, oh well.

If I want to use allocator debuggers I already have the production ready tools that exist for C and C++ for at least 30 years.

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

#48

Post by steveklabnik » Thu, Jul 16, 2026, 4:19 PM UTC

orlp wrote: post #35

steveklabnik wrote: post #11

I think this is a fine post. But one comment: > remember that for compilers which emit machine code, like roc and rustc, doing memory-unsafe things is a big part of the job I don't really think that this is true, in the way that it's written. I think that for the hot binary patching / code reloading features, yes, that is going to need unsafe. But for regular old "producing an executable" compilation? Emitting machin…

I think if you interpret it charitably it means that any bug in the emitted machine code is already a likely memory-unsafe miscompilation if it is ran. The compiler itself might be perfectly "memory safe" but the generated binary fundamentally is always at risk (besides WebAssembly I suppose). I'm fully aware of the separation of compiler and binary, and being able to compile untrusted code safely is nice, but a perf…

I do think that is a good point, it's just not what the line actually says. But that's why I wasn't saying "zomg this is WRONG!!!!" but instead, trying to point out that there are subtleties here. For people who aren't as deep in the weeds in this subject, I think the details matter. But again, as I said, I like the post, this is just one thing.

I am also probably in a more pedantic mindset because, well, I'm writing a compiler in Rust, and the words as written do not resonate with me at all.

> a perfectly safe compiler that generates vulnerable binaries isn't that much better.

I do think it's much better. Eliminating classes of bugs in one component is a good thing, even if it's not every component. This is a core lesson of Rust! unsafe still exists, but going from "I don't know what is unsafe" to "only this part is unsafe" is a major improvement.

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

#49

Post by solatic » Thu, Jul 16, 2026, 4:19 PM UTC

veber-alex wrote: post #37

lioeters wrote: post #7

Earlier quoted context omitted.

Instead of waiting for faster compiler in Rust, how about from the other direction, adding some kind of borrow checker to Zig? That sounds more within reach and practically achievable, possibly even in userland.

It's impossible to add a borrow checker to any existing language. The reason Rust has a working borrow checker is because every part of the language from structs, enum, traits, generics and all the way to the syntax itself has been designed to support lifetimes and borrow checking. It's is not something you can just tack on to an existing language without fundamentally changing it.

I wouldn't say it's impossible, rather un-ergonomic. TypeScript can add type information to ordinary JavaScript code via JSDoc comments; the result can both be executed as ordinary JavaScript as-is and type-checked with TypeScript. But it's a huge pain to try to write (and maintain) everything that way, it was supported as a hack to help migrate legacy codebases. You could probably take a similar "the lifetimes are embedded in comments" approach with other languages, and the result would be similarly un-ergonomic.

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

#50

Post by skybrian » Thu, Jul 16, 2026, 4:19 PM UTC

Aurornis wrote: post #27

steveklabnik wrote: post #11

I think this is a fine post. But one comment: > remember that for compilers which emit machine code, like roc and rustc, doing memory-unsafe things is a big part of the job I don't really think that this is true, in the way that it's written. I think that for the hot binary patching / code reloading features, yes, that is going to need unsafe. But for regular old "producing an executable" compilation? Emitting machin…

That line confused me, too. What parts of their compiler require memory-unsafe operations to produce machine code?

They are saying that running the compiled code is memory-unsafe when there is a compiler bug, and that’s what developers do next. The memory corruption happens in a different process.

In this respect, effectively all the compiler should be treated sort of like an unsafe region because it requires extra care to avoid memory corruption bugs.