Rust Ownership and the Fall
The borrow checker as a moral system — or, why memory safety is a theological category.
Rust’s ownership system is an unusual thing: a compiler that enforces relational rules. A value has exactly one owner. To share it, you borrow it — and the borrow must not outlive the owner. Violation is a compile error, not a runtime crash. The Rustonomicon calls this the dark arts of unsafe Rust; the ownership model is what keeps the rest of the language safe.
This is not just a memory model. It is a description of a certain kind of order.
The problem it solves
Languages without ownership — C, C++, JavaScript in its lower registers — permit aliasing: two names for the same value, each believing it has exclusive access. Aliasing causes bugs. Specifically, it causes the kind of bugs that make systems unreliable in ways they cannot predict or diagnose: use-after-free, data races, dangling pointers.
The traditional name for “using something as if you owned it when you don’t” is theft. This is not rhetoric. The structure of the error is identical.
What the borrow checker teaches
To program in Rust is to be forced, repeatedly, to clarify: who owns this? And then: who has borrowed it, for how long, and for what purpose?
These are questions that appear in contract law, in property law, in Patristic discussions of stewardship. The insight that data and physical things have analogous relational structures is not new.
fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
if x.len() > y.len() { x } else { y }
}The lifetime annotation 'a is the compiler demanding that you name the relationship. The code cannot compile until the relationship is explicit.
That demand — name the relationship before you proceed — is worth carrying into other domains.
