For engineers new to Rust, build wait time overtakes borrow-checker errors as the main logged friction within the first two months

Hypothesis

The usual account of learning Rust puts the borrow checker at the centre: the first weeks are spent fighting ownership and lifetime errors until the model clicks. The hypothesis is that this account describes only the first phase. Once ownership errors become routine to fix, the dominant complaint in a newcomer's own records becomes the wait for the compiler: full builds after dependency changes, slow incremental builds in large crates, test runs that rebuild, and CI builds. cargo check reduces this, since the Cargo documentation describes it as compiling without the final step of code generation, which is faster than cargo build, but tests and binaries still need the full build. The claim is about the crossover point: within two months of daily Rust work, entries about build wait time outnumber entries about borrow-checker errors in a newcomer's friction log.

Prediction

In weekly friction logs kept by engineers new to Rust, the share of entries categorised as ownership or borrowing errors is highest in the first two weeks and declines week over week; the share categorised as build or test wait time rises and exceeds the ownership share by week eight at the latest. The crossover comes earlier in larger projects and later for engineers who work in small crates or who came from C++ rather than a garbage-collected language. If, at week eight, ownership entries still outnumber build-wait entries for most participants, the hypothesis is false.

Proposed test

1. Recruit engineers starting daily Rust work on an existing codebase, and record their previous language, the project's crate count and a clean build time on their machine.
2. Ask each to log, at the end of every working day, each moment of friction as one line with a category from a fixed list: ownership or borrowing error, type or trait error, build or test wait, tooling, library API, other. Give examples per category before the study starts.
3. Collect the logs weekly for ten weeks; compute per person and per week the share of entries per category and the week of crossover, if any.
4. Cross-check with objective data where possible: compiler error codes from the editor's diagnostics log, and build durations from the report that cargo build --timings writes.
5. Report per-person trajectories rather than a pooled curve, since the claim is about when the crossover happens for most people.

Status

No result is claimed. Friction logs measure what people notice, and a wait is noticed differently from an error; the cross-check in step 4 shows whether the logged shares track the underlying counts. Ten weeks with a handful of engineers can show whether the crossover exists and roughly when, not its precise timing.