Bei Personen, die neu mit Rust arbeiten, überholt die Wartezeit auf Builds innerhalb der ersten zwei Monate die Borrow-Checker-Fehler als grösste protokollierte Reibung

Hypothese

Die übliche Darstellung des Rust-Lernens stellt den Borrow Checker ins Zentrum: Die ersten Wochen verbringt man damit, gegen Ownership- und Lifetime-Fehler zu kämpfen, bis das Modell «klick» macht. Die Hypothese lautet, dass diese Darstellung nur die erste Phase beschreibt. Sobald das Beheben von Ownership-Fehlern zur Routine wird, wird die dominierende Klage in den eigenen Aufzeichnungen einer neu einsteigenden Person das Warten auf den Compiler: vollständige Builds nach Abhängigkeitsänderungen, langsame inkrementelle Builds in grossen Crates, Testläufe, die neu bauen, und CI-Builds. cargo check verringert dies, da die Cargo-Dokumentation es als Kompilieren ohne den letzten Schritt der Codegenerierung beschreibt, was schneller ist als cargo build, doch Tests und Binärdateien brauchen weiterhin den vollständigen Build. Die Behauptung betrifft den Kreuzungspunkt: Innerhalb von zwei Monaten täglicher Rust-Arbeit übersteigen Einträge über die Build-Wartezeit im Reibungsprotokoll einer neu einsteigenden Person die Einträge über Borrow-Checker-Fehler.

Vorhersage

In wöchentlichen Reibungsprotokollen, die von Personen geführt werden, die neu mit Rust arbeiten, ist der Anteil der als Ownership- oder Borrowing-Fehler kategorisierten Einträge in den ersten zwei Wochen am höchsten und sinkt Woche für Woche; der Anteil der als Build- oder Test-Wartezeit kategorisierten Einträge steigt und übersteigt spätestens ab Woche acht den Ownership-Anteil. Der Kreuzungspunkt tritt bei grösseren Projekten früher ein und später bei Personen, die in kleinen Crates arbeiten oder aus C++ statt aus einer Sprache mit Garbage Collection kommen. Übersteigen in Woche acht die Ownership-Einträge bei den meisten Teilnehmenden weiterhin die Build-Wartezeit-Einträge, ist die Hypothese falsch.

Vorgeschlagener Test

1. Personen rekrutieren, die tägliche Rust-Arbeit an einer bestehenden Codebasis beginnen, und ihre vorherige Sprache, die Anzahl der Crates des Projekts sowie eine Clean-Build-Zeit auf ihrem Rechner festhalten.
2. Jede Person bitten, am Ende jedes Arbeitstags jeden Reibungsmoment als eine Zeile mit einer Kategorie aus einer festen Liste zu protokollieren: Ownership- oder Borrowing-Fehler, Typ- oder Trait-Fehler, Build- oder Test-Wartezeit, Tooling, Bibliotheks-API, Sonstiges. Vor Beginn der Studie Beispiele je Kategorie geben.
3. Die Protokolle zehn Wochen lang wöchentlich sammeln; je Person und Woche den Anteil der Einträge je Kategorie sowie, falls vorhanden, die Woche des Kreuzungspunkts berechnen.
4. Wo möglich mit objektiven Daten gegenprüfen: Compiler-Fehlercodes aus dem Diagnoseprotokoll des Editors und Build-Dauern aus dem Bericht, den cargo build --timings schreibt.
5. Verläufe pro Person berichten statt einer gepoolten Kurve, da die Behauptung betrifft, wann der Kreuzungspunkt für die meisten Personen eintritt.

Status

Es wird kein Ergebnis behauptet. Reibungsprotokolle messen, was Personen bemerken, und eine Wartezeit wird anders bemerkt als ein Fehler; die Gegenprüfung in Schritt 4 zeigt, ob die protokollierten Anteile den zugrunde liegenden Zahlen folgen. Zehn Wochen mit einer Handvoll Personen können zeigen, ob der Kreuzungspunkt existiert und ungefähr wann, nicht seinen genauen Zeitpunkt.