Introduction

Matt Weisfeld opens The Object-Oriented Thought Process with an observation that has aged better than most of the technology it was written about: a programmer can learn the syntax of an object-oriented language over a weekend and then go on writing procedural code in it for years. The compiler never objects. The classes are there, the methods are there, and underneath them sits the same program the same person would have written in C, with the data in one place and the logic in another. What was missing was never syntax. It was a way of thinking about where responsibility lives.

Rust sets the same trap and then springs it immediately. The syntax is learnable in a weekend, and a programmer who arrives with the habits of Java, Python, C# or Go will write something that looks reasonable and will be told no. Not once, but persistently, in long messages about moved values and borrowed content and lifetimes that do not live long enough. The usual reaction at that point is to treat the compiler as an obstacle and go looking for the incantation that will make it stop talking. There is always one. clone() will silence most of these errors, Rc<RefCell<T>> will silence the rest, and a program built out of those two moves will compile, run, and teach its author nothing.

This book is about the thought process that makes those incantations unnecessary. The premise is that nearly every complaint the Rust compiler makes is a design question wearing an error message. Who owns this value. Who is allowed to change it, and who is only allowed to look. How long does this thing need to be valid, and what guarantees that. What states can this type actually be in, and which of those states are ones you never want to handle. Those questions have answers in every program ever written, in every language. Most languages let you leave the answers implicit, in a comment, in a convention, or in the head of whoever wrote the module three years ago. Rust asks you to write them down in the program, and then it holds you to them.

The payoff for answering them is not only that the program compiles. It is that the design gets better in ways that have nothing to do with Rust. A programmer who has spent a year making ownership explicit writes clearer Go, because the question of who is responsible for a thing does not stop being a real question in a language that declines to ask it.

The intended audience

You can already program. You have written and shipped something in some language, you can read a function and see what it does, and terms like compilation, heap, stack, reference and type are not new to you. Where you are coming from matters less than you might expect, but it does matter, and the book assumes you are coming from somewhere: a class-based object-oriented language, most likely, or a garbage-collected language with structs and interfaces, or C and C++ if you took the low road. Each chapter names the habit it is asking you to put down and where that habit came from.

If Rust is your first language, this book will still work, but it is aimed over your shoulder at the reader who has something to unlearn. The Rust Programming Language, the free official book, is the better starting point, and this one will be waiting afterward.

What you do not need is prior exposure to Rust. Syntax is introduced as it becomes necessary, and never for its own sake.

This book’s scope

This is a book about thinking, so it is short on syntax and long on argument. The reference material exists already and is excellent: the standard library documentation, the Rust Programming Language, the Rust API Guidelines. None of them is trying to do what this book is trying to do, which is to describe the model a Rust programmer holds in their head and to show how it produces particular designs.

The consequence is that the book is incomplete on purpose. Macros appear only where they change how you design something. Async appears in one chapter, as an extension of the ownership model rather than as a subject in itself. unsafe appears as the place where you take responsibility back from the compiler, not as a tutorial. Cargo, formatting, tooling and the ecosystem are barely present. You will need other sources for all of that, and you will find them easily.

The chapters run in the order the ideas depend on each other. Ownership before borrowing, borrowing before lifetimes, all three before anything about types and traits, because the reason Rust’s type system looks the way it does is that it was built on top of that model rather than beside it. Reading out of order is possible but the early chapters are the ones the rest lean on.

This book’s conventions

Code appears in fenced blocks, and nearly all of it compiles. Examples are written against the standard library alone unless a crate is named, and they are checked by mdbook test as part of building the book, so an example that claims to work does work.

Some examples are meant to fail. Teaching the borrow checker without showing it rejecting something would be teaching the rules without the enforcement, so rejected programs appear throughout, marked as rejected, with the compiler’s actual complaint underneath. Those examples are checked too: the build verifies that they still fail, which means the book cannot quietly drift into claiming an error that a later compiler accepts.

Two kinds of aside interrupt the text. A note adds something useful that does not belong in the argument.

Note

Notes look like this. Skipping them costs you nothing structural.

A comparison names the habit under discussion and where you learned it.

Coming from Java, C# or Python

Asides like this one translate. They are not there to tell you that your old language was wrong; they are there because a habit is much easier to put down once you can see it.

Each chapter ends with a conclusion that states what changed in your model, and with a short set of questions to think through. The questions are not exercises in the homework sense and mostly do not have code answers. They are there because a thought process is practiced rather than read.