Einblicke - Was Rust meinem Go beigebracht hat

Beim Review einer Rust-Codebasis fiel mir wieder auf, was diese Sprache so besonders macht: Der Compiler weigert sich. Ein vergessener Fehlerfall? Kompiliert nicht. Ein nicht behandelter Arm in einem match? Kompiliert nicht. Ganze Fehlerklassen sind schlicht nicht ausdrückbar.

Danach die unbequeme Frage: Warum verzeiht mein Go all das?

Go ist toleranter. Ein Fehler lässt sich stillschweigend ignorieren. Ein switch darf Fälle vergessen. Das rächt sich nicht sofort. Es rächt sich in sechs Monaten, nachts, in Produktion.

Also haben wir den Transfer versucht: nicht die Sprache portieren, sondern die Garantien. Für jede Rust-Eigenschaft gibt es in Go ein Prüfwerkzeug. Ignorierte Fehler: errcheck. Schlampige Fehlervergleiche: errorlint. HTTP-Requests ohne Context, nie geschlossene Response-Bodies: noctx und bodyclose. Achtzehn Prüfungen laufen inzwischen unter golangci-lint, und die Pipeline macht sie verbindlich: kein Release, solange eine rot ist. Vieles von dem, was Rusts Compiler verbietet, meldet jetzt unsere Pipeline.

Ergebnis in einem einzigen Go-Projekt: rund 60 echte Korrekturen. Keiner der behobenen Fehler hatte je sichtbaren Schaden verursacht. Die beste: require-Assertions in einem HTTP-Mock-Handler. Schlägt die Assertion fehl, stirbt die falsche Goroutine, und der Test kann nicht einmal richtig fehlschlagen. Genau die Sorte Fehler, die später ein rätselhaftes Ticket wird.

Sprachen kann man nicht portieren. Disziplin schon.

Und weil es so gut lief: Python hat dieselbe Behandlung bekommen. Drei Projekte, drei Sprachen, ein gemeinsames Regelwerk, jeweils im Dialekt der Sprache.

Ehrlicherweise: Nicht jede strenge Regel haben wir übernommen. goconst hielt Testdaten wie „John“ für magische Konstanten, prealloc optimiert Mikrosekunden, die kein CLI je spürt. Beide sind aus, mit einem Decision Record, der das Warum festhält. Strenge ohne Urteilsvermögen ist auch nur Lärm.

Mein Go ist nicht strenger geworden. Meine Pipeline ist es.