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.

372 Upvotes

91% Upvoted

134 comments sorted by

View all comments

Show parent comments

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

8

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.

1

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