Rust vs. Go im Backend: wie wir entscheiden

Wir bauen Produktivsysteme sowohl in Rust als auch in Go, und unser eigenes Produkt läuft auf beiden: Go, wo Iterationstempo zählt, Rust, wo Latenz und Speichersicherheit nicht verhandelbar sind. Wenn uns also jemand fragt, welche Sprache er für ein neues Backend nehmen soll, lautet unsere Antwort: Es kommt darauf an. Wer Ihnen mit einem einzigen Wort antwortet, will Ihnen etwas verkaufen.

Dieser Beitrag ist der Vergleich, den wir uns öfter wünschen würden. Statt eines Benchmark-Duells geht es um die praktischen Abwägungen, die bei echten Projekten den Ausschlag geben.

Was sie gemeinsam haben

Beginnen wir mit den Gemeinsamkeiten, denn die sind groß. Beide kompilieren zu nativem Code, beide sind so schnell, dass die Sprache selten Ihr Engpass ist, beide liefern ein einzelnes statisches Binary, das sich problemlos in einem Container ausrollen lässt, und beide bieten erstklassige Nebenläufigkeit und ein gesundes Ökosystem. Jede der beiden ist eine vertretbare Wahl für einen Backend-Dienst. Die „falsche“ zu wählen, werden Sie längst nicht so sehr bereuen, wie Debatten im Netz nahelegen.

Wo Go gewinnt

Go optimiert vor allem auf eines: ein Team produktiv zu machen und produktiv zu halten. Die Sprache ist klein genug, um sie in einer Woche zu lernen, die Standardbibliothek deckt das meiste ab, was ein Dienst braucht, und Goroutinen machen nebenläufigen Code zugänglich statt furchteinflößend. Kompiliert wird nahezu sofort, was die Feedbackschleife kurz hält.

• Klassische Backend-Dienste: REST- und gRPC-APIs, Microservices, Orchestrierungsdienste, Worker.
• Teams, die schnell vorankommen und neue Entwicklerinnen und Entwickler rasch einarbeiten müssen.
• Netzwerkdienste mit hoher Nebenläufigkeit, in denen Goroutinen glänzen und die Laufzeitumgebung den schwierigen Teil übernimmt.
• Alles, bei dem Einfachheit und Lesbarkeit wichtiger sind, als die letzten paar Prozent Leistung herauszuholen.

Der Preis: Go arbeitet mit Garbage Collection. Für die überwältigende Mehrheit der Dienste ist das kein Thema, denn der Collector ist hervorragend. Es bedeutet aber gelegentliche Pausen und weniger Kontrolle über das Speicherlayout, und das zählt bei einer bestimmten Klasse latenzkritischer Aufgaben.

Wo Rust gewinnt

Rust bietet Leistung auf C-Niveau, Speicher- und Thread-Sicherheit, die schon beim Kompilieren erzwungen wird, und keinen Garbage Collector. Der Borrow Checker, der Einsteiger frustriert, ist genau der Mechanismus, der ganze Fehlerklassen (Use-after-free, Data Races, Null-Dereferenzierungen) gar nicht erst in die Auslieferung gelangen lässt. Wenn Korrektheit und Geschwindigkeit gleichermaßen zählen, ist diese Garantie die steilere Lernkurve wert.

• System- und Netzwerksoftware: Protokolle, Proxys, Agenten, die Datenebene.
• Echtzeit-Pipelines, in denen eine Pause des Garbage Collectors inakzeptabel ist, etwa bei Live-Medien.
• Leistungskritische Komponenten innerhalb eines größeren Systems, oft per FFI oder als fokussierter Dienst.
• WebAssembly, wo Rust ein vollwertiger Bürger ist, um Code mit nativer Geschwindigkeit in den Browser zu bringen.

Der Preis ist real: Rust braucht länger zum Lernen, länger zum Schreiben und länger zum Kompilieren. Ein Team, das neu damit arbeitet, wird in den ersten Monaten langsamer sein. Im richtigen Einsatzgebiet zahlt sich diese Investition aus, im falschen ist sie reiner Mehraufwand.

Wie wir tatsächlich entscheiden

Auf unserer eigenen Plattform hat sich die Aufteilung von selbst ergeben: Go, wo Iterationstempo und Lesbarkeit am meisten zählen, Rust, wo Latenz und Speichersicherheit nicht verhandelbar sind. Wir haben uns für keine Seite entschieden, sondern das Werkzeug passend zur Aufgabe gewählt.

Greifen Sie zu Rust, wenn Sie sich einen Absturz, ein Data Race oder eine Collector-Pause nicht leisten können. Für fast alles andere nehmen Sie Go. Die meisten Backends sind „alles andere“.

Eine brauchbare Faustregel: Beginnen Sie ein neues Backend in Go, sofern Sie keinen konkreten Grund dagegen haben, und setzen Sie Rust gezielt für die Komponenten ein, die es wirklich brauchen. Sie müssen sich nicht für eine einzige Sprache für das ganze System entscheiden. Ein Go-Dienst mit einer Rust-Komponente hinter FFI oder ein kleiner Rust-Dienst hinter einer Go-API ist eine absolut vernünftige Architektur.

Wenn Sie diese Entscheidung für ein echtes Projekt abwägen und eine zweite Meinung von Leuten wollen, die beides ausliefern, ist das genau die Art Gespräch, die wir gern führen.