Appendix IV - The Psychological Transition From C To Rust

Appendix IV - The Psychological Transition From C To Rust

The transition from C to Rust is often described as a technical transition: from manual memory management to a language in which memory safety is enforced by the type system. From a psychological perspective, however, something more interesting is happening.

The programmer is not simply learning a new set of rules. The programmer is being asked to represent the program differently.

The central proposition of this appendix is:

The stronger the memory-safety constraints imposed by a programming language, the more the programmer must construct a mental model in which ownership, aliasing, mutation, and lifetime are explicit properties of the program.

This does not mean that memory-safe programming necessarily requires more thinking. Rather, it changes what the programmer must think about, when that thinking occurs, and which aspects of the program become cognitively salient.

Mental Models and Programming

Programming is fundamentally a cognitive activity. A programmer cannot manipulate an entire program directly; instead, the programmer constructs an internal representation of the program and reasons through that representation.

Research on programming has explicitly examined these internal representations as "mental models." Canas, Bajo, and Gonzalvo (1994), for example, demonstrated that different forms of programming instruction can produce differences in how programmers represent programming concepts. More broadly, research into programming expertise suggests that experienced programmers develop increasingly structured representations that allow them to recognize meaningful patterns without reasoning about every detail independently.

This distinction is important. A programmer can sometimes produce correct code without possessing the same conceptual representation as another programmer.

The question, therefore, is not merely whether a programmer can use Rust successfully. It is what the programmer has learned to regard as important when thinking about a Rust program.

In C, a programmer may be able to reason about a data structure principally in terms of values, addresses, pointers, and operations. In Rust, the same programmer must increasingly reason in terms of ownership, borrowing, mutability, movement, and lifetime.

The language has changed the problem representation.

The C Mental Model

C permits a relatively direct conceptual model of memory.

An object exists somewhere in memory. A pointer identifies an address. Code follows the pointer and performs an operation on the object.

Of course, experienced C programmers know that this model is incomplete. They understand allocation, deallocation, ownership conventions, aliasing rules, lifetime requirements, and the dangers of undefined behaviour.

The important point is that C does not require most of this knowledge to be represented explicitly in the language's type system.

A programmer can therefore maintain many important invariants informally.

For example:

this pointer belongs to this subsystem

this object must remain alive until this function returns

this function may mutate the object

this other function must not mutate it simultaneously

this allocation must eventually be freed

These facts may exist entirely in the programmer's head, in documentation, in naming conventions, or in the social conventions of a programming team.

C allows the programmer considerable freedom to decide how much of this structure to make explicit.

That freedom is powerful.

It is also cognitively consequential.

Rust Makes Relationships Explicit

Rust changes the situation.

The programmer is no longer concerned only with what a value is and what operation should be performed upon it. The programmer must also express important relationships between values.

Who owns this value?

Who may access it?

Is access shared or exclusive?

May the access modify the value?

How long may the reference remain valid?

What happens to the original binding after the value is moved?

These questions introduce concepts that are comparatively easy to leave implicit in C.

Psychologically, this matters because the programmer's attention is being redirected.

The programmer moves from thinking primarily about objects and operations toward thinking about relationships between objects.

A simplified contrast is:

C:

object -> address -> operation

Rust:

value -> owner -> permitted access -> lifetime

The second model is more relational.

The programmer must reason not only about the object, but about the rights and temporal conditions surrounding the object.

From Memory To Authority

This suggests that "memory safety" may be an incomplete description of the psychological transition.

Rust does not merely ask:

Where is this object?

It increasingly asks:

Who has authority over this object?

Ownership is a form of authority.

A mutable reference represents...