Go oder Rust für einen neuen Dienst wählen: ein Entscheidungsverfahren ohne Benchmarks

Ziel

Eine dokumentierte Entscheidung zwischen Go und Rust für einen Dienst anhand von Eigenschaften treffen, welche die eigene Dokumentation der Sprachen festhält, ausdrücklich ohne Benchmark-Zahlen Dritter, die bestimmte Programme messen und nicht Sprachen.

Voraussetzungen

Eine Beschreibung des Dienstes in einem Absatz (Form der Anfragen, Latenzempfindlichkeit, Speicherbudget, zu integrierende Systeme, die Personen, die ihn pflegen werden) sowie eine Vorlage für einen Architekturentscheid (Architecture Decision Record) für das Ergebnis.

Schritte

1. Speicherverwaltung. Die Go-FAQ erklärt, dass Go sich für Garbage Collection entschieden hat, um Programmierenden die Buchführung über Objektlebensdauern abzunehmen; das Rust-Buch stellt Ownership als Alternative zu einem Garbage Collector dar. Zu fragen ist: Gibt es eine harte Speicherobergrenze, den Bedarf an vorhersagbaren Pausen oder eine Einbettungsbeschränkung (eine gemeinsam genutzte Bibliothek, WebAssembly, Firmware)? Das spricht für Rust; ohne diese Punkte wird sein struktureller Hauptvorteil nicht benötigt.
2. Nebenläufigkeitsstil. Gos Goroutines und Channels machen eine Goroutine pro Anfrage zum Standard. Das Rust-Buch hält fest, dass durch die Nutzung von Ownership und Typprüfung viele Nebenläufigkeitsfehler zu Kompilierzeitfehlern statt zu Laufzeitfehlern werden, dass asynchrones Rust aber eine zusätzliche Laufzeitwahl und Lifetime-Wechselwirkungen mit sich bringt. Zu fragen ist: Besteht der Dienst hauptsächlich aus I/O-Fan-out (beides passt; Go ist kürzer zu schreiben) oder aus CPU-lastiger Datenverarbeitung (Rusts Kontrolle über Allokation zählt stärker)?
3. Fehlerbehandlung und Korrektheitsbudget. Beide Sprachen verwenden explizite Fehlerwerte; Rust kodiert zusätzlich Abwesenheit, erschöpfende Musterabgleiche und Aliasing-Regeln zur Kompilierzeit. Zu fragen ist: Wie teuer ist ein Laufzeitfehler in diesem Dienst, einem Buchhaltungssystem oder einem internen Dashboard?
4. Passung zum Ökosystem. Die konkret benötigten Bibliotheken auflisten (Datenbanktreiber, Broker-Client, Cloud-SDK, gRPC, Observability) und prüfen, dass jede davon existiert, gepflegt wird und bereits in anderen Diensten des Teams genutzt wird.
5. Personen. Zählen, wer heute Code in jeder Sprache reviewen kann und wer Bereitschaftsdienst übernehmen wird. Eine Sprache, die sonst niemand im Team liest, ist unabhängig von ihren Vorzügen ein Pflegerisiko.
6. Build und Betrieb. Kompilierzeiten, Cross-Compilation und das Container-Basisimage berücksichtigen; beide Sprachen erzeugen eine einzelne native ausführbare Datei, und die Go-FAQ merkt an, dass Go standardmässig statisch linkt.
7. Die Entscheidung als ADR festhalten, mit den Antworten aus den Schritten 1 bis 6 sowie den Bedingungen, unter denen sie neu zu überdenken wäre.

Erwartetes Ergebnis

Eine Entscheidung, die die zwei oder drei ausschlaggebenden Eigenschaften benennt, sodass eine später lesende Person erkennen kann, ob diese Eigenschaften noch gelten.

Grenzen und Prüfbasis

Das Verfahren gewichtet dokumentierte Eigenschaften und lokale Beschränkungen; es sagt weder Durchsatz noch Latenz voraus, die vom Programm abhängen und am tatsächlichen Dienst gemessen werden müssen. Beide Sprachen eignen sich für die meisten Netzwerkdienste; dass das Kriterium der Personen häufiger entscheidet als die technischen Kriterien, ist die Synthese der beitragenden Instanz, kein gemessenes Ergebnis.