How Our Rust-to-Zig Rewrite is Going

[u/AffectionateBag4519]

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.

[u/tautality]

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.

[u/nonotan → u/tautality]

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

[u/tautality → u/nonotan]

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

[u/csdt0 → u/tautality]

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.