Over the past two years, I've been involved with designing and implementing a new feature of rustc, called "externally implementable items". This is not a finished feature, though if you'd like you can try it on nightly already! This is the story of how externally implementable items were invented, implemented, and how some day they might be stabilized. I'm sure that is interesting to some of those who read this.

That's not the main thing this blog post is about, though. Instead, I'm using it as an example, to show you how the Rust project operates. To show how many people are involved with a change, how they learn from each other, how I've learned so much from them myself. An example of how important social interaction is to open source. Much more than writing the code itself.

This is a written-out version of a talk I gave at Rust in Paris 2026.

While writing some machinery for dealing with spans on built-in attributes last month, I was slightly bothered by a missing method on Iterator. I usually work on the compiler, not the library, but I decided to write a little proposal, which was then accepted, so today it was time to try and implement it. In fairness, that implementation itself was mostly trivial, and yet right now there's no way to stabilize it. What I actually want to share is the incredible compiler work going on as we speak that will unblock it.

The rust compiler is a giant project. Hundreds of contributors help maintain it. I consider myself quite lucky that this maintenance work has become my full time job. Most of that time though, isn't spent to work on new language features, though there is a bit of that. In fact, most maintenance is barely visible to users of the language. So what does maintaining the compiler look like?

I woke up last weekend, and someone assigned me to a PR to review. That's quite common. It fixed a crash with attributes, something I've worked a lot on. Some code crashed the compiler, but the code to reproduce it used a specific nightly feature called "contract attributes", and I didn't believe that that was the only way to reproduce the crash. So, I tried to see if any currently stable attribute would the same so the reproducer was more general. It turned out: I was wrong! But playing with it I found a complely new way to crash the compiler in a single line of code.

Deprecated is an attribute you can put on items to mark them as, well, deprecated. Any use of that item will give a warning, telling you that you're using something that's deprecated. The thing is, it doesn't always work...

Sometimes you just really need an arena. Sometimes for performance reasons, other times for lifetime-related reasons. In their most basic forms, they're just a vec with some extra guarantees. However, it's those extra guarantees that matter. I've found myself looking for the right kind of arena too many times, so here's an overview of literally everything there is. I think, let me know if I forgot something.

You might not have considered this before, but tests in Rust are rather magical. Anywhere in your project you can slap #[test] on a function and the compiler makes sure that they're all automatically run. This pattern, of wanting access to items that are distributed over a crate and possibly even multiple crates, is something that projects like bevy, tracing, and dioxus have all expressed interest in but it's not something that Rust supports except for tests specifically.