What Rust is good for in AI development

I have been thinking about Rust’s features lately. A language with strong compile-time verification catches most of the potential problems at compile time, which means that even without tests, anything you manage to write already comes with tests built in, and that degree of verifiability makes it a very good fit for the AI era. You could even say that if I come up with a good design and wrap the business logic directly inside its type checking, that saves some of the work of writing tests.

I don’t think it replaces tests, of course, but as a constraint it at least stops the AI from going off and inventing things. The next thing is that it cut classes out entirely, forcing you to build your business logic out of composition, and that clears away some of the latent coupling hazards along the way. The structure itself is what guarantees the boundaries have to be clear. And clarity is what the AI era needs most. Without it the agent drifts while it writes, and to stop it drifting I have to use a lot of “verifiable” material to hold it to being correct.

// C#
User user = GetUser();     // may return null
Console.WriteLine(user.Name);  // compiles fine. at runtime, if user is null → NullReferenceException

// Rust
let user: Option<User> = get_user();
println!("{}", user.name);  // ❌ fails to compile: Option<User> has no field called .name

A front-loaded compile-time feature like the one above also forces whoever writes the code to deal with the possible non-existence case at compile time, or it simply won’t compile, which blocks at the root the kind of boundary break that compiles perfectly and then fails when it runs. The thing AI coding fears most is code that looks fine and blows up at runtime, and in that situation hunting the bug burns an enormous amount of time, which is the thorniest problem in development.

After that comes contention under concurrency. Ownership, the most distinctive thing Rust has, takes a problem that only surfaces at runtime and exposes it at compile time. For a variable with a single dependent, you can pin ownership, or the right to use it, onto that user, permanently or for a while, and release it when they’re done. During that window the other concurrent contenders simply can’t use it, so the fight over it is settled at compile time. This whole thing does nothing for variables that are shared by nature, a counter for instance, and there Rust forces you to handle the problem explicitly with Mutex, forcing something the compiler can’t detect out into the open instead of leaving you to keep a lock in order of your own accord the way other languages do.

// shared counter, the way it's written below won't work
let mut counter = 0;
let handle = thread::spawn(|| {
    counter += 1;     // the new thread wants to change counter
});
counter += 1;         // the main thread wants to change counter too

use std::sync::{Arc, Mutex};

// Arc: shared ownership across threads; Mutex: only one thread gets in to change it at a time
// forced to handle this kind of sharing explicitly
let counter = Arc::new(Mutex::new(0));   
let c = Arc::clone(&counter);
let handle = thread::spawn(move || {
    let mut num = c.lock().unwrap();   // want to touch the value inside? take the lock first. can't get it, wait
    *num += 1;
});                                    // num leaves scope → lock released automatically

Put another way, in Rust’s case contention is either handled by ownership guaranteeing a single user at any one moment, or by explicit handling that wraps the boundary inside a range that has been compiled.

I’ve always thought verifiability matters a great deal for holding AI to quality. Tests are only one expression of that verifiability. But how do you guarantee verifiability at the language level? By doing what Rust’s design philosophy does, making everything explicit, having it surface all sorts of problems plainly at compile time, refusing to compile when something isn’t written well, constraining everything that should be constrained. That kind of thing has always been painful for a human to write, but AI doesn’t care about any of it, so from any angle it fits.

Strict constraints at the compile level that make everything explicit, the way Rust does it. The other side of it, no less necessary, sits at the level of business logic, and is guaranteed by tests, especially tests with strong coverage. And a strictly designed language makes writing those tests more convenient. Unit tests, integration tests. If the language already suppresses, at compile time, all the ways you might blur things together or write something untestable. Or maybe put it this way, Rust’s own design makes a well-specified structure the default choice, and although bad code still isn’t something a language can rule out, as long as you follow the basic principles the baseline quality comes out fairly high.

Whether a piece of code is testable is, strictly speaking, guaranteed by structure. The language is only a tool, and a language with stricter rules is a tool that’s good to use, which is the level at which I agree about Rust. That isn’t to say a language with loose rules can’t use structure to get the same guarantee. TS, or Python, can also secure testing through pure functions. But for AI there will be some compile-level problems, and more problems that only surface at runtime to write around. For Rust it can be solved right at compile time. The trouble with runtime problems is that you don’t know what you’re going to run into, and Rust’s insistence that you cover the boundaries as a backstop catches a large share of the problems that only show up at runtime, at least tying off one end so it doesn’t collapse catastrophically. And thinking about it from this angle, there’s a loop question involved too. Especially with the sort of AI that runs on its own, if you don’t give it a clear pointer at the error it has no way to debug at all, which is hard. It can’t notice a smell the way a human can. So explicit, decent error handling matters a lot for AI debugging.

---

Translation note. I wrote this in Chinese. This English version is an LLM translation, so the wording is not mine even though the thinking is. Original: rust在ai开发中的优势.