Warum wir kritische Backends in Go bauen

Wenn wir gefragt werden, warum ein Backend in Go und nicht in Node, Java oder Rust entstehen soll, kommt die Antwort selten von den Benchmarks. Go ist schnell, ja. Aber schnell sind viele. Der Grund ist ein anderer: Go zwingt zu einer Einfachheit, die man drei Jahre später noch lesen kann.

Die Sprache hat wenig Meinung – und genau das ist die Meinung

Go hat keine Vererbung, keine Exceptions, keine Generics-Akrobatik, keine drei Wege, eine Schleife zu schreiben. Was auf den ersten Blick wie ein Mangel wirkt, ist im Betrieb ein Geschenk: Code, den ein Junior schreibt, sieht fast so aus wie Code, den ein Senior schreibt. Reviews drehen sich um Fachlichkeit, nicht um Stil.

Ein Backend, das man nicht mehr lesen kann, ist kein Backend mehr. Es ist eine Hypothek.

Für Systeme, die zehn Jahre laufen sollen – und das ist bei Behörden, Banken und Infrastruktur die Regel –, wiegt Lesbarkeit schwerer als jede Feature-Liste.

Fehler sind Werte, keine Überraschungen

if err != nil wird gern belächelt. Wir mögen es. Jeder Fehler ist ein sichtbarer Pfad im Code, den man behandelt oder bewusst weiterreicht. Es gibt keinen Stack, der irgendwo drei Ebenen höher aufschlägt und die Anfrage still verschluckt.

order, err := repo.FindOrder(ctx, id)
if err != nil {
    return fmt.Errorf("find order %s: %w", id, err)
}

Die Fehlerkette, die daraus entsteht, ist im Log lesbar wie ein Satz: handle payment: find order 4711: connection refused. Das ist Observability, für die man kein Tool kaufen muss.

Ein Binary, ein Container, kein Rätsel

Go kompiliert zu einem statischen Binary. Das Deployment ist ein FROM scratch-Container mit einer Datei darin – kein Runtime-Image, kein Paket-Manager, kaum Angriffsfläche. Für Kubernetes-Umgebungen heisst das: kleine Images, schnelle Starts, wenig CVE-Rauschen.

Nebenläufigkeit, die man erklären kann

Goroutines und Channels sind kein Zauber, aber sie erlauben es, nebenläufige Abläufe so zu schreiben, wie man sie am Whiteboard zeichnet: ein Worker-Pool, eine Pipeline, ein Fan-out. Wer das Modell einmal verstanden hat, liest fremden Code ohne Angst.

Wann wir nicht zu Go greifen

Ehrlichkeit gehört dazu: Für datenlastige Explorationen und ML-Pipelines bleibt Python die richtige Wahl. Für Frontends selbstverständlich TypeScript. Und wo ein Team bereits tief in einem Ökosystem steckt und gut damit fährt, ist ein Sprachwechsel selten die wichtigste Entscheidung.

Aber wo ein System die kritische Infrastruktur eines Unternehmens ist – Zahlungen, Identität, Verwaltung –, ist Go für uns die Sprache, die den geringsten Preis für Klarheit verlangt.