Rust is winning. For nine years running, it has been the most-admired language in the world's largest developer survey. It's winning, because it's clearly needed. The systems programming landscape is clearly tired of memory safety problems.
And for good reason. Rust ecosystem has a lot of technical merit. Just cargo alone is a reason to use Rust. It's what npm wishes every day it could be. The integrated documentation, development, packaging and testing are everything the modern software ecosystem dreamt of. It's a breath of fresh air for the systems programming sphere.
Not having to use Catch2 or Doxygen or CMake... Finally leaving OOP behind... Being able to write concurrent, low-level, high-performance programs fearlessly... It's all so appealing.
Except for two problems.
cve-rs
cve-rs
is a piece of Rust code that introduces common memory safety bugs in 100%
Rust. They include #![deny(unsafe_code)] in their code to
easily display this.
As of today, you can just clone the repo, build it with Cargo, and blow a Rustacean's mind with a segfault in what is supposedly "Safe Rust".
It's derived from a soundness issue that's been waiting for a fix for 10+ years at this point.
Don't get me wrong. This is a convoluted structure explicitly designed to mess with the Rust compiler. This is not something that you'll accidentally program yourself into. This does not, in a practical sense, invalidate Rust.
But by definition, this problem casts a shadow onto Rust's promise of memory safety. It is my opinion that bugs like this could all be avoided with a formal specification.
For a project as committed to correctness as Rust, not having an official formal specification for 15+ years is peak irony. Not only does a formal spec guarantee the freedom of the language standard, but it also helps prevent bugs similar to those that give way to cve-rs.
As a formal methods enthusiast and as a proponent of FOSS, I feel like a formal spec is what would allow us to reason with Rust correctly and independently, and I care about that. Without a formal spec, rustc is a monopoly over what Rust is.
Recreating and reasoning with the reference implementation by meticulously studying it is admittedly possible, but most definitely not in line with the FOSS spirit. With enough time, we could recreate Windows NT bug-for-bug too, doesn't mean Windows NT is a freedom-respecting piece of software.
A formal spec would also help with bootstrappability, as you would not have to deal with older implementations and just go straight to implementation of the spec itself. Ken Thompson's Turing Award speech and the relevant article, Reflections on Trusting Trust, emphasize the importance of this better than I could hope to explain in a single blogpost.
I do realize that I'm saying all this as someone who never wrote a line of Rust in production. My criticism is not rooted in experience, it's rooted in my faith in formal methods and mathematical correctness.
I'm creating this challenge, because I want to be involved with correctness and safety professionally. And in 2025, that means being involved with Rust.
I believe this, because Rust is the only mainstream systems language that is even having the right conversations. Its commitment to memory safety, the existence of a Formal Verification team, and the ambition of its community are powerful signals. Rust isn't just a language, it's a project that is actively pushing the entire industry toward a more reliable and secure future.
That is why I'm exhilerated at the thought of being a part of such a project. I'm not complaining about the problems, I want Rust to be as safe as mathematically possible. If I can make it in time, I would like to be a part of the solution.
Because in FOSS, you don't wait for others to fix your problems. You step up to the challenge, and you get your hands dirty. People without dirty hands are wrong.
So, in order to understand Rust truly and become a part of it, I intend to get started with two simple actions.
That's right. The dates show October 13, and I intend to complete at least one problem per day, until it's all finished.
Around every 15 problems, I'll write how it's going in this blog.
Let's see what I can do to earn my place in the Rust community, as a whole. Let's see, what I can follow this challenge up with.
I invite you to follow along. You can follow my progress in this repository.
See you in two weeks.
Edited 2025-10-14: On second thought, maybe 10 updates for a coding challenge is a little too much. My next update will come when 30 problems are complete.
I'll see you November 13.