Der Borrow-Checker wurde nicht mit Geld im Sinn entworfen. Er sollte verhindern, dass eine C++-Programmiererin Speicher freigibt, auf den anderswo noch verwiesen wird, und das beim Kompilieren, bevor der Fehler ausgeliefert wird.
Diese eng gefasste Garantie verallgemeinert sich weiter, als ihre Entwickler vorgesehen hatten. Ein Reentrancy-Fehler, die Sorte, die mehr als einen Abwicklungsvertrag leergeräumt hat, hat strukturell dieselbe Form wie ein Use-after-free: Code übergibt die Kontrolle an etwas Externes, während der eigene Zustand mitten in der Aktualisierung steckt, und dieses Externe ruft zurück und liest oder verändert einen Zustand, der nicht mehr der Annahme der ursprünglichen Funktion entspricht. Speichersicherheit und Zustandssicherheit sind dasselbe Problem in anderer Verkleidung.
Rusts Eigentumsregeln wissen nichts von Tokens oder Kontoständen. Was sie wissen: Ein Datum hat zu jedem Zeitpunkt genau eine Besitzerin, veränderbarer Zugriff ist exklusiv, und der Compiler weigert sich, Code zu bauen, der diese Invarianten verletzen könnte. Auf einen Abwicklungspfad angewendet, ist genau diese Verweigerung die gewünschte Eigenschaft: Keine Funktion darf einen veralteten Kontostand halten, während ein anderer Pfad ihn gleichzeitig verändern könnte.
Ein Speicherfehler in einem Webserver kostet ein Patch-Release. Derselbe Fehlertyp in einem Abwicklungsvertrag kostet den Kontostand, einmalig, vollständig, an wen auch immer ihn zuerst gefunden hat.
Diese Asymmetrie ist der Grund, warum Teams, die abwicklungsreife Systeme bauen, zunehmend Sprachen wählen, die ganze Fehlerklassen unmöglich machen, statt sie nur unwahrscheinlich zu machen. Es geht nicht um Performance und nicht um Mode. Es geht darum, die Kosten eines Fehlers von der Produktion, wo sie in echten Kontoständen bemessen werden, zur Kompilierzeit zu verschieben, wo sie in einer roten Schlangenlinie und einem Nachmittag Arbeit bemessen werden.
Nichts davon macht Code automatisch korrekt. Ein Programm kann den Borrow-Checker vollständig zufriedenstellen und trotzdem die falsche Geschäftsregel mit vollkommener Speichersicherheit umsetzen. Was sich ändert, ist der Umfang dessen, was noch geprüft werden muss: Sobald eine ganze Kategorie von Zustandsfehlern strukturell ausgeschlossen ist, kann sich die verbleibende Prüfung auf die Logik konzentrieren, nicht auf die Verkabelung. Das ist ein kleineres, greifbareres Problem, und für Code, der Geld bewegt, ist kleiner und greifbarer genau der Punkt.