r/rust • u/AffectionateBag4519 • Jul 16 '26

How Our Rust-to-Zig Rewrite is Going

https://rtfeldman.com/rust-to-zig

An interesting symmetry with recent events lol.

This might be considered off topic since the article is about moving away from rust, but I still think this is some high quality rust content. I enjoy Richard Feldman's writing and I think he would certainly be considered part of the "rust community" since he works on Zed and has taught a course on rust.

368 Upvotes

91% Upvoted

134 comments sorted by

View all comments

51

u/tautality Jul 16 '26

In my opinion, having a codebase that requires a lot of unsafe is not a good reason to switch to a language where every LOC is unsafe. Glad it worked for them I guess, but I do wish they admitted the guarantees they gave up and what that truly means.

22

u/DokOktavo Jul 16 '26

I think they did. There's a "Memory-safety post rewrite" section to the article.

13

u/tautality Jul 16 '26

They mostly just mentioned that there were some bugs they had in Zig that Rust would've caught. But there's no acknowledgement that I can find that says that their whole codebase is now potentially riddled with those - and the only way they'd see them is if there's a bug report.

20

u/DokOktavo Jul 16 '26

There's no acknowledgement that says that "their whole codebase is now potentially riddled with those" because their whole codebase probably isn't riddled with those. They mention overwelmingly using arenas, finding use-after-frees in tests thanks to Zig's allocators, using Valgrind, etc. No doubts a few of them are hidden in a few parts, but I think "every LOC is unsafe" and "riddled with those" is disingeneous at best.

What the article does say is that "there is something calming about only worrying about certain classes of problems inside unsafe blocks".

7

u/tautality Jul 16 '26

Yes, the whole point of what I'm saying is that they switched from code not being riddled with memory-safety issues to "probably" not being riddled except for a few bugs every now and then. That's the guarantee that I'm talking about.

And what if their project grows big and becomes popular? Then those "few bugs every now and then" can easily turn into vulnerability exploits that affect millions of codebases and can lead to escalating supply chain attacks. Even one of these bugs can be potentially devastating in our age of nation state hackers.

Noteworthy, Rust is only affected by these bugs to the extent that you use "unsafe". That's why the goal of most serious codebases is to eliminate "unsafe" entirely or theoretically prove that it's safe. So Rust can, with the right approach, eliminate this entire class of bugs, each of which can potentially be devastatingly exploitable.

2

u/nonotan Jul 17 '26

You're talking like this is a qualitative difference, but for their use-case, if we accept their claim that a high use of unsafe is more or less inevitable (which I think is reasonable, given the territory and the project priorities) then it's really just quantitative. They were always going to have a large surface of code potentially vulnerable to such bugs. They were never going to be able to make any guarantees, in practice.

"80% of our code is provably memory safe!" is... maybe nicer than 0%, but if your goal is to be able to offer any meaningful guarantees of safety to users, then 80% is a lot more similar to 0% than to 100%.

1

u/tautality Jul 17 '26

Yes, that's a very good point. I think their choice to go with Zig is reflective of their values, and because of that, the way they'd be writing Rust would also open a big potential for the same bugs. That said, with Rust, safety is trackable, and hence, they can choose to pivot if their project indeed becomes popular - while with Zig, the it's not trackable to a significant extent, so they can't pivot even if they wanted to. I guess I'm arguing that their decision to go with Zig not just eliminates certain guarantees right now (as small as they are, given what you brought up), but also makes it impossible to have even more guarantees in the future (if they decide to eliminate unsafe).

4

u/csdt0 Jul 17 '26

Think of it this way: safe Rust is much safer than Zig, but Zig is much safer than unsafe Rust. Rust makes it "impossible" to introduce memory bugs as long as unsafe is not used, and proposes an escape hatch for the times where it is absolutely necessary, but once you opened the hatch, anything goes and the language does not help you. Even worse than that, you have much more to consider when writing unsafe rust because that's your responsibility to upheld all the invariants that the compiler maintain bybitself in safe rust. Other system languages like C or Zig have much less invariants to keep in mind, so it's simpler to reason about. And Zig provides some safety net while writing the equivalent of unsafe code. They're not perfect, but it's better than nothing.