Rust: Beyond the Syntax

The Premise: Tools That Think Back

There is a particular class of intellectual encounters that leave you slightly different than you found yourself before them. Not because they handed you a new technique or a sharper method, but because they quietly rearranged the furniture of your thinking. Gray’s article on Rust sits squarely in this category, and its central argument is deceptively simple: learning Rust is not primarily about acquiring syntax. It is about submitting yourself to a discipline that will, over time, alter how you reason about systems, ownership, and the passage of time through data.

This is not a claim about one language being better than another in any benchmarkable sense. It is a claim about cognitive formation — the idea that a sufficiently demanding tool will leave its shape in the hand that holds it.

The Context That Makes This Argument Necessary

We are living through a period of enormous productivity in software tooling. Frameworks, package managers, and AI-assisted editors have collectively lowered the cost of writing code to near zero. You can prototype almost anything in an afternoon. This is genuinely wonderful, and I say that without irony. But the flip side is that it has become possible to write enormous amounts of code without ever confronting the underlying mechanics of what that code is doing — where memory lives, who owns it, when it is safe to release it.

Languages like Python or JavaScript are designed, in part, to keep those concerns invisible. They are polite. Rust is not polite. It refuses to let you proceed until you have accounted for every edge. The ownership system, the borrow checker, the insistence on explicit lifetimes — these are not obstacles the Rust community forgot to remove. They are the point. Gray’s article situates itself in this moment precisely because the dominant mode of software development is trending toward abstraction and convenience, and he wants to ask what we lose when we never have to answer hard questions.

The Key Insight: Constraint as Cognitive Scaffold

The Dijkstra quote that Gray deploys early in the piece is worth sitting with: “It is not only the violin that shapes the violinist, we are all shaped by the tools we train ourselves to use, and in this respect programming languages have a devious influence: they shape our thinking habits.” What I find striking about the word “devious” here is its moral charge. Dijkstra is not saying tools are neutral shapers. He is warning that the influence is indirect, operating below the level of conscious choice. You do not decide to start thinking in recursions because you use a functional language; it happens to you as a consequence of repeated exposure.

Rust makes this deviousness explicit and, crucially, beneficial. When the borrow checker rejects your code, it is not being arbitrary. It is surfacing a real logical error about who owns what at what moment in time. The friction is honest friction. And what happens after you have battled the borrow checker a thousand times is that you begin, before you write a line, to think spatially and temporally about data. You ask: who owns this? For how long? What guarantees are safe to make about it after I pass it somewhere else? These are not questions that most developers in garbage-collected environments are trained to ask. They are questions that, once internalized, transfer. They sharpen how you think about APIs, about concurrency, about the implicit contracts embedded in every function signature.

The Perlis aphorism — “A language that doesn’t affect the way you think about programming is not worth knowing” — functions here as a kind of challenge rather than a mere observation. Gray uses it to raise the stakes: if a language leaves your thinking unchanged, you have consumed a tool without receiving an education. Rust, by this measure, is almost aggressively worth knowing.

Adjacent Territories: Embodied Cognition and Skill Acquisition

This line of thinking connects naturally to what cognitive scientists describe as embodied cognition — the idea that thinking is not separate from the physical or procedural constraints of the medium you work in. A sculptor thinks differently about form than a painter does, not because sculptors are smarter, but because three-dimensional resistance teaches lessons two-dimensional surfaces cannot. The borrow checker is, in a meaningful sense, resistance. It pushes back. And resistance, when it is principled, is pedagogically valuable in ways that frictionless tools simply cannot replicate.

There is also an interesting parallel to the study of constraint-based creativity. Musicians who compose under strict formal rules — a fugue’s counterpoint requirements, say — often report that the constraint does not limit expression so much as it forces a deeper engagement with possibility space. The rules become a kind of scaffolding on which genuine understanding is built, after which the scaffolding can be internalized rather than merely followed. Something analogous seems to happen with experienced Rust programmers: they stop fighting the borrow checker and start thinking like it.

Why This Matters

The deeper implication of Gray’s argument is one about intentionality in tool selection. If our tools shape our thinking without our always noticing, then choosing which tools to train ourselves on is a form of intellectual self-determination. There is a difference between using a language because it is convenient and using a language because of what it will require of you. Rust demands that you take seriously the question of what your program is doing in time and memory, and that demand, repeated across months of practice, produces a different kind of programmer — one who carries certain questions into every subsequent context, regardless of what language they happen to be writing in.

That seems worth the discomfort of the learning curve. More than that, it seems like exactly the kind of productive difficulty that a serious intellectual life ought to make room for.