Go vs Rust Performance-Tiefenvergleich: Die neuesten Benchmark-Daten von 2026 sprechen für sich

Im Jahr 2026 sind Go und Rust die beiden am heißesten diskutierten Sprachen in der Backend-Entwicklung. Go besticht durch Einfachheit und Effizienz, Rust durch maximale Performance und Sicherheit. Aber was bedeutet „Performance" eigentlich konkret? Wie groß ist der Unterschied wirklich? Und wer gewinnt in welchem Szenario?

Dieser Artikel verzichtet auf Meinungen und setzt auf Daten. Alle Leistungswerte stammen von Programming Language Benchmarks (Stand Juni 2026), The Computer Language Benchmarks Game sowie diversen Community-Testprojekten. Die eingesetzten Compilerversionen: rustc 1.90.0 und go 1.26.1.

1. Testumgebung und Methode

• CPU: AMD EPYC 7763 64-Core (x86_64, 4 Kerne)
• Rust-Compiler: rustc 1.90.0
• Go-Compiler: go 1.26.1 / tinygo 0.40.0
• Testkategorien: CPU-intensive Berechnungen, JSON-Serialisierung, HTTP-Services, Parallelverarbeitung, Speicherverbrauch

Jeder Test wurde mehrfach ausgeführt — wir berücksichtigen sowohl Ausführungszeit als auch Speicherspitzen als Kernkennzahlen.

2. CPU-intensive Berechnungen: Rust dominiert

CPU-intensive Aufgaben sind Rusts Heimspiel. Dank Zero-Cost-Abstractions, fehlender GC-Pausen und tiefer LLVM-Optimierung spielt Rust bei reinen Rechenaufgaben in einer ganz eigenen Liga.

2.1 Benchmark-Ergebnisse

binarytrees (Binärbaum-Konstruktion und -Traversal, Input 18)

• Rust (schnellste): 1259 ms, Speicherspitze 33,8 MB
• Go (schnellste, tinygo): 1726 ms, Speicherspitze 51,9 MB
• Go (Standard-Compiler): 2343 ms, Speicherspitze 41,9 MB
• Fazit: Rust ist 1,86× schneller als Go (Standard) und verbraucht 21 % weniger Speicher

fannkuch-redux (Array-Permutationsberechnung, Input 11)

• Rust (schnellste, Intrinsics + Multithreading): 413 ms, Speicherspitze 2,1 MB
• Go (schnellste, Multithreading): 724 ms, Speicherspitze 5,5 MB
• Fazit: Rust ist 1,75× schneller und verbraucht 62 % weniger Speicher

mandelbrot (Mandelbrot-Mengen-Rendering, Input 5000)

• Rust (schnellste): 246 ms, Speicherspitze 4,8 MB
• Go (schnellste): 2666 ms, Speicherspitze 7,7 MB
• Fazit: Rust ist 10,8× schneller — ein Unterschied von über einer Größenordnung!

knucleotide (Nukleotidsequenz-Analyse, Input 2500000)

• Rust (schnellste, Multithreading): 219 ms, Speicherspitze 28,1 MB
• Go (schnellste, Multithreading): 676 ms, Speicherspitze 39,5 MB
• Fazit: Rust ist 3,09× schneller und verbraucht 29 % weniger Speicher

2.2 Codebeispiel: Mandelbrot-Rendering

Warum ist der Unterschied beim Mandelbrot so extrem? Weil die Aufgabe massenhaft Gleitkommaoperationen und SIMD-Vektorisierung erfordert. Rust kann LLVMs automatische Vektorisierung direkt nutzen, während Go keine SIMD-Unterstützung für Gleitkommazahlen bietet.

Rust-Implementierung:

use std::io::Write;

fn main() {
    let width = 5000;
    let height = 5000;
    let mut buf = Vec::with_capacity(width * height / 8);

    for y in 0..height {
        let ci = 2.0 * y as f64 / height as f64 - 1.0;
        for x_bit in 0..(width / 8) {
            let mut byte = 0u8;
            for x_inner in 0..8 {
                let x = (x_bit * 8 + x_inner) as usize;
                let cr = 2.0 * x as f64 / width as f64 - 1.5;
                let mut zr = 0.0f64;
                let mut zi = 0.0f64;
                let mut escaped = false;
                for _ in 0..50 {
                    let zr2 = zr * zr;
                    let zi2 = zi * zi;
                    if zr2 + zi2 > 4.0 {
                        escaped = true;
                        break;
                    }
                    zi = 2.0 * zr * zi + ci;
                    zr = zr2 - zi2 + cr;
                }
                if !escaped {
                    byte |= 1 << (7 - x_inner);
                }
            }
            buf.push(byte);
        }
    }
    let stdout = std::io::stdout();
    let mut handle = stdout.lock();
    write!(handle, "P4\n{} {}\n", width, height).unwrap();
    handle.write_all(&buf).unwrap();
}

Go-Implementierung:

package main

import (
    "bufio"
    "fmt"
    "os"
)

func main() {
    width := 5000
    height := 5000
    w := bufio.NewWriter(os.Stdout)
    fmt.Fprintf(w, "P4\n%d %d\n", width, height)

    for y := 0; y < height; y++ {
        ci := 2.0*float64(y)/float64(height) - 1.0
        for xBit := 0; xBit < width/8; xBit++ {
            var b byte
            for xInner := 0; xInner < 8; xInner++ {
                x := xBit*8 + xInner
                cr := 2.0*float64(x)/float64(width) - 1.5
                zr, zi := 0.0, 0.0
                escaped := false
                for i := 0; i < 50; i++ {
                    zr2 := zr * zr
                    zi2 := zi * zi
                    if zr2+zi2 > 4.0 {
                        escaped = true
                        break;
                    }
                    zi = 2*zr*zi + ci
                    zr = zr2 - zi2 + cr
                }
                if !escaped {
                    b |= 1 << uint(7-xInner)
                }
            }
            w.WriteByte(b)
        }
    }
    w.Flush()
}

Die Logik ist nahezu identisch. Aber der Rust-Compiler vektorisiert die innere Schleife automatisch — Go nicht. Das erklärt den Faktor 10.

2.3 Fazit: CPU-intensive Aufgaben

Rust ist bei CPU-intensiven Aufgaben im Durchschnitt 2–10× schneller als Go. Die Gründe:

1. Keine GC-Pausen — Rust hat keine Garbage Collection und damit keine Performance-Schwankungen
2. Tiefe LLVM-Optimierung — Automatische Vektorisierung, Inlining, Loop Unrolling übertreffen Go bei Weitem
3. Zero-Cost-Abstractions — Iteratoren und Closures werden zur Compile-Zeit vollständig inliniert
4. Bessere SIMD-Unterstützung — Über std::simd (Nightly) oder Drittanbieter-Bibliotheken direkt nutzbar

3. JSON-Serialisierung: Unterschied in der Standardbibliothek

JSON ist das meistgenutzte Datenformat im Backend. Sowohl Rust als auch Go bieten hier ausgereifte Lösungen, doch der Performance-Unterschied bleibt signifikant.

3.1 Benchmark-Ergebnisse

Testszenario: Parsen eines typischen 2,4 KB großen API-Response-JSON (verschachtelte Objekte, Arrays, Strings), 100.000 Wiederholungen, gemessen werden Gesamtdauer und Speicherspitze.

Fazit: - Rust serde_json ist 6,5× schneller als Gos Standardbibliothek und verbraucht 86 % weniger Speicher - Selbst mit dem schnellsten Go-Bibliotheks-Ökosystem (sonic) ist Rust noch 2,2× schneller - Rusts Kernvorteil: Zero-Allocation — serdes Zero-Copy-Deserialisierung referenziert Strings direkt im Original-Byte-Array, während Gos GC für jeden String Heap-Speicher allokieren muss

3.2 Codebeispiel

Rust (serde_json):

use serde::{Deserialize, Serialize};

#[derive(Serialize, Deserialize, Debug)]
struct ApiResponse {
    status: String,
    total: u64,
    items: Vec<Item>,
}

#[derive(Serialize, Deserialize, Debug)]
struct Item {
    id: u64,
    name: String,
    tags: Vec<String>,
    metadata: serde_json::Value,
}

fn main() {
    let json_data = std::fs::read_to_string("test.json").unwrap();

    for _ in 0..100_000 {
        let response: ApiResponse = serde_json::from_str(&json_data).unwrap();
        // Deserialisierung ist Zero-Copy, Strings werden nicht neu allokiert
        assert_eq!(response.total, 256);
    }
}

Go (encoding/json Standardbibliothek):

package main

import (
    "encoding/json"
    "os"
)

type ApiResponse struct {
    Status string `json:"status"`
    Total  int    `json:"total"`
    Items  []Item `json:"items"`
}

type Item struct {
    ID       int               `json:"id"`
    Name     string            `json:"name"`
    Tags     []string          `json:"tags"`
    Metadata map[string]any    `json:"metadata"`
}

func main() {
    data, _ := os.ReadFile("test.json")

    for i := 0; i < 100000; i++ {
        var response ApiResponse
        json.Unmarshal(data, &response)
        // Jede Deserialisierung erzeugt massenhaft Heap-Allokationen
    }
}

Warum ist der Unterschied so groß? 1. Gos encoding/json nutzt Reflection (reflect) zur Strukturfeld-Parsung — enormer Overhead 2. Go-Strings sind Werttypen — jede Zuweisung erzeugt eine Kopie 3. Rusts serde erzeugt Code zur Compile-Zeit — keine Reflection, dazu Zero-Copy-Deserialisierung 4. Gos interface{} (any) erzeugt Boxing — zusätzliche Speicherzuweisungen

💡 Optimierungstipp: Für Go-Projekte mit JSON-Performance-Ansprüchen empfiehlt sich ByteDances sonic. Es ist die schnellste JSON-Bibliothek im Go-Ökosystem und setzt intern auf JIT und SIMD.

4. HTTP-Service-Performance: Das praxisnahe Duell

Der häufigste Anwendungsfall im Backend: HTTP-Services schreiben. Diese Kategorie ist am nächsten an der Produktionsrealität — und für die meisten Entwickler die interessanteste.

4.1 TechEmpower-Benchmark-Daten

TechEmpower ist der maßgeblichste Web-Framework-Benchmark. Wir betrachten zwei repräsentative Szenarien: JSON-Serialisierung und Plain-Text.

JSON-Serialisierung (einfaches Objekt serialisieren und zurückgeben)

Plain-Text-Antwort (Rückgabe von „Hello, World!")

Fazit: - Rust actix-web ist bei Plain-Text 2,9× schneller als Gos Standardbibliothek und 4,3× schneller als Gin - Gos fasthttp überzeugt, hat aber immer noch 1,8× Rückstand - Bei der P99-Latenz klafft die Lücke noch weiter auseinander: Rusts Tail-Latenz ist deutlich stabiler — weil keine GC-Pausen existieren

4.2 Codebeispiel: Minimaler HTTP-Service

Rust (actix-web):

use actix_web::{get, App, HttpServer, HttpResponse};

#[get("/json")]
async fn json_handler() -> HttpResponse {
    HttpResponse::Ok().json(serde_json::json!({
        "message": "Hello, World!",
        "status": "ok"
    }))
}

#[get("/plaintext")]
async fn plaintext_handler() -> &'static str {
    "Hello, World!"
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new()
            .service(json_handler)
            .service(plaintext_handler)
    })
    .bind("0.0.0.0:8080")?
    .workers(num_cpus::get())
    .run()
    .await
}

Go (net/http Standardbibliothek):

package main

import (
    "encoding/json"
    "log"
    "net/http"
)

func jsonHandler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(map[string]string{
        "message": "Hello, World!",
        "status":  "ok",
    })
}

func plaintextHandler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "text/plain")
    w.Write([]byte("Hello, World!"))
}

func main() {
    http.HandleFunc("/json", jsonHandler)
    http.HandleFunc("/plaintext", plaintextHandler)
    log.Fatal(http.ListenAndServe(":8080", nil))
}

Die Komplexität ist ähnlich, Go ist sogar etwas simpler. Der Unterschied liegt in der Runtime:

1. Rust nutzt die Tokio-Async-Runtime — alle Requests werden als Zero-Cost-Abstraction Future verarbeitet
2. Gos Goroutinen sind leichtgewichtig, aber der Scheduler selbst erzeugt Overhead, und der GC pausiert alle Goroutinen
3. Rust hat keinen GC — die Tail-Latenz ist extrem stabil; Gos P99-Latenz kann das 3–5× der Durchschnittslatenz betragen

5. Parallelmodelle im Detail: Goroutine vs. Async/Await

Parallelverarbeitung ist einer der Bereiche, in dem Go und Rust am stärksten divergieren. Beide setzen auf völlig unterschiedliche Modelle — jedes mit eigenen Stärken.

5.1 Modellvergleich

Gos CSP-Modell (Goroutine + Channel): - Goroutinen sind Green Threads mit initialem Stack von nur 2 KB, dynamisch skalierbar - Der Scheduler folgt dem M:N-Modell (G-M-P-Modell) — Userspace-Scheduling mit minimalen Wechselkosten - Channels bieten typsichere Kommunikation zwischen Goroutinen - Schreibstil: Imperativ-synchron, fühlt sich an wie Multithreading, läuft aber als Coroutinen - Lernkurve: Flach — Goroutinen sind quasi selbsterklärend

Rusts Async/Await-Modell (Tokio/Async-Std): - Async-Funktionen werden zu State Machines kompiliert — jedes Future ist ein Enum-Typ - Ausführung erfordert eine Async-Runtime (Tokio ist der Standard), darunter epoll/kqueue - Stackless Coroutinen: Die Größe jedes Future ist zur Compile-Zeit festgelegt, Speicherbedarf vorhersehbar - Schreibstil: Asynchron — explizite Markierung mit async/await nötig - Lernkurve: Steil — Lifetimes, Pin, Send/Sync sind Hürden

5.2 Performance-Vergleich bei Parallelverarbeitung

Testszenario: 100.000 parallele Tasks starten, jeder berechnet eine einfache Aufgabe (Fibonacci bis Stelle 30), gemessen werden Gesamtdauer und Speicherspitze.

Fazit: - Rusts Async-Tasks verbrauchen weniger Speicher pro Task (0,6 KB vs. 2,4 KB), weil Futures zur Compile-Zeit als Enums festgelegt sind, während Goroutinen Laufzeit-Stack-Management-Overhead haben - Rust ist 2,15× schneller — primär wegen fehlender GC-Pausen und effizienterem Scheduling

5.3 Code-Stil-Vergleich

Go (Goroutine + Channel):

package main

import (
    "fmt"
    "sync"
)

func fibonacci(n int) int {
    if n <= 1 {
        return n
    }
    return fibonacci(n-1) + fibonacci(n-2)
}

func main() {
    results := make(chan int, 100000)
    var wg sync.WaitGroup

    for i := 0; i < 100000; i++ {
        wg.Add(1)
        go func(n int) {
            defer wg.Done()
            results <- fibonacci(n % 30)
        }(i)
    }

    go func() {
        wg.Wait()
        close(results)
    }()

    sum := 0
    for r := range results {
        sum += r
    }
    fmt.Println("Sum:", sum)
}

Rust (Tokio Spawn):

use tokio::task;

fn fibonacci(n: u32) -> u64 {
    if n <= 1 {
        return n as u64;
    }
    let mut a: u64 = 0;
    let mut b: u64 = 1;
    for _ in 2..=n {
        let temp = a + b;
        a = b;
        b = temp;
    }
    b
}

#[tokio::main]
async fn main() {
    let mut handles = Vec::with_capacity(100_000);

    for i in 0..100_000u32 {
        handles.push(tokio::spawn(async move {
            fibonacci(i % 30)
        }));
    }

    let mut sum: u64 = 0;
    for handle in handles {
        sum += handle.await.unwrap();
    }
    println!("Sum: {}", sum);
}

Stilunterschiede auf einen Blick: - Go-Code ist kompakter und intuitiver — go func() startet eine Coroutine in einer Zeile, Channel-Kommunikation ist klar lesbar - Rust erfordert explizite Behandlung von async/await und Result-Typen, etwas mehr Code - Gos sync.WaitGroup wird in Rust durch JoinHandle ersetzt — ähnliche Semantik, andere Syntax

5.4 Parallel-Sicherheit

Gos Parallel-Sicherheit: - Abhängig von Entwicklerdisziplin: go vet -race erkennt Data Races - Channels fördern das Prinzip „Kommuniziere, statt Speicher zu teilen" - In der Praxis wird sync.Mutex aber extrem häufig eingesetzt — Data Races bleiben eine häufige Fehlerquelle

Rusts Parallel-Sicherheit: - Compile-Zeit-Garantie: Send- und Sync-Traits verhindern Data Races schon beim Kompilieren - Das Ownership-System eliminiert hängende Zeiger und Use-After-Free naturgemäß - Tokios spawn verlangt, dass Futures Send implementieren — Compile-Zeit-Sicherheit für Cross-Thread-Zugriffe - Preis: Steile Lernkurve, Anfänger kämpfen oft mit dem Compiler

💡 Kernunterschied: Gos Parallel-Sicherheit ist „Disziplin zur Laufzeit", Rusts Parallel-Sicherheit ist „Gesetz zur Compile-Zeit". Rust ist sicherer, Go ist freier.

6. Speicherverbrauch im Detail: Der Preis des GC

Speicher ist in der Cloud-Ära der direkteste Kostenfaktor. Ein speichersparender Service bedeutet weniger Server und niedrigere Rechnungen.

6.1 Speichermodelle im Vergleich

Gos Speicherverwaltung: - Nutzt Mark-and-Sweep-GC (ab Go 1.24 mit Concurrent Marking verbessert) - GC-Pausenziel: unter 0,5 ms (Standardkonfiguration GOGC=100) - Die Runtime selbst belegt ca. 4–8 MB (Goroutine-Scheduler, GC-Metadaten etc.) - Jede Goroutine startet mit 2 KB Stack, kann auf bis zu 1 GB wachsen - GC-Pausen sind kurz, können aber bei hoher Parallelität mehrmals pro Sekunde auftreten

Rusts Speicherverwaltung: - Kein GC, vollständig abhängig vom Ownership-System und RAII - Runtime-Overhead nahe Null (nur minimale Tokio-epoll-Registrierung) - Speicherverbrauch vollständig vorhersehbar — keine GC-bedingten Speicher-Spikes - Größe jedes Future/Task zur Compile-Zeit festgelegt, kein dynamisches Stack-Wachstum

6.2 Speicherverbrauch in der Praxis

Szenario: Ein mittel belasteter Web-API-Service (1000 QPS, mit Datenbankabfragen und JSON-Serialisierung)

Wichtige Erkenntnisse: - Rusts Stabil-Speicher beträgt nur 1/5 bis 1/9 von Go - Go schwankt stark — man muss Puffer für den GC-„Blähbauch" einplanen - Bei Burst-Last ist Gos Speicherspitze 9× höher als bei Rust - Auf einem 2-GB-Server kann Rust damit die 5–8× gleiche Parallelität bedienen

6.3 Memory-Leak-Risiken

• Go: Goroutine-Leaks sind das häufigste Problem. Vergessenes Schließen von Channels, blockierte Goroutinen — all das führt zu kontinuierlichem Speicherzuwachs
• Rust: Das Ownership-System eliminiert die meisten Leaks schon zur Compile-Zeit. Aber zyklische Referenzen mit Rc/Arc können trotzdem lecken (hier braucht man Weak)

💡 Kostenimpact: Wenn dein Service 100 Go-Server benötigt, reichen mit Rust möglicherweise 15–20. Bei großen Microservice-Architekturen bedeutet das sechsstellige jährliche Einsparungen bei der Infrastruktur.

7. Technologieauswahl: Go oder Rust?

Die Daten sind klar — aber eine Sprachentscheidung hängt von mehr ab als nur Benchmarks. Produktivität, Team-Kompetenz und Ökosystem-Reife spielen eine ebenso große Rolle. Hier ist ein praxisorientierter Entscheidungsrahmen.

7.1 Wann Go wählen?

Go empfiehlt sich für: - Schnell entwickelte Web-APIs: gin/echo ermöglichen extrem schnelle Entwicklung, ideal für CRUD-Lastiges - Microservice-Architekturen: Starke Standardbibliothek, einfache Deployment (ein Binary), Goroutinen perfekt für viele parallele Verbindungen - DevOps/Cloud-Native-Tools: Docker, Kubernetes, Terraform — alles Go, das Ökosystem passt perfekt - Begrenzte Team-Erfahrung: Go ist leicht zu lernen, Neueinsteiger schreiben nach einer Woche produktiven Code - Schnelle Iteration nötig: Kompilierung in Sekunden, Hot-Reload praktisch, ideal für agile Entwicklung

Bekannte Nutzer: ByteDance (TikTok-Backend), Google (zahlreiche interne Services), Uber, Dropbox

7.2 Wann Rust wählen?

Rust empfiehlt sich für: - Maximale Performance: Suchmaschinen, Datenbank-Engines, Message Queues, Game-Server - Ressourcenbeschränkte Umgebungen: IoT-Geräte, Edge Computing, Embedded Systems (Speicher im MB-Bereich möglich) - Hochverfügbare Systeme: Finanztransaktionen, Blockchain-Nodes (Compile-Zeit-Sicherheit reduziert Produktionsfehler) - Rechenintensive Aufgaben: Bildverarbeitung, Audio/Video-Codecs, Kryptografie, wissenschaftliches Rechnen - C/C++-Ersatz: Systemprogrammierung, Treiber, Hochleistungs-Netzwerkbibliotheken

Bekannte Nutzer: Cloudflare (Edge Computing), Discord (von Go zu Rust migriert), Dropbox (Dateisynchronisation), Figma (Rendering-Engine)

7.3 Entscheidungstabelle

Wähle Go, wenn: - ✅ I/O-lastige Services (viele Datenbankabfragen, externe API-Calls) - ✅ Keine Systemprogrammierungs-Erfahrung im Team - ✅ Schnelles Go-Live ist wichtiger als letzte Performance-Optimierung - ✅ Container/K8s-Umgebung, Speicher ist kein Engpass

Wähle Rust, wenn: - ✅ CPU-lastige Services (Berechnungen, Verschlüsselung, Komprimierung) - ✅ P99-Tail-Latenz ist geschäftskritisch - ✅ Speicherkosten sind Haupttreiber, Optimierung ist essentiell - ✅ Team hat C/C++-Hintergrund und investiert gerne in Einarbeitung - ✅ Lange Projektlebensdauer, Performance-Investition lohnt sich

7.4 Hybrid-Ansatz: Warum sich entscheiden?

Viele Teams setzen auf Go + Rust im Hybrid-Betrieb:

• Go für die Business-Logik: Schnelle Entwicklung, flexible Iteration
• Rust für Performance-Engpässe: Rechenintensive Module als Rust-Bibliotheken mit C-ABI, von Go via cgo aufgerufen

package main

// #cgo LDFLAGS: -L./lib -lrust_engine
// #include "rust_engine.h"
import "C"

func ProcessData(input []byte) []byte {
    // Aufruf des hochperformanten Rust-Moduls
    result := C.process_data(
        (*C.char)(unsafe.Pointer(&input[0])),
        C.size_t(len(input)),
    )
    defer C.free_result(result)
    return C.GoBytes(unsafe.Pointer(result.data), C.int(result.len))
}

So bekommst du Gos Produktivität und Rusts Performance gleichzeitig. Discord nutzt einen ähnlichen Ansatz: Go für Business-Services, Rust für die Kernberechnungen des Push-Services.

Zusammenfassung: Alles auf einen Blick

Unsere Empfehlung:

• Produktivität und Team-Effizienz → Go
• Maximale Performance und Ressourceneffizienz → Rust
• Beides → Go für die Business-Schicht + Rust für performancekritische Module

Es gibt keine „beste" Sprache — nur die passende für dein Szenario. Wir hoffen, diese datenbasierte Analyse hilft dir bei einer fundierten Technologieentscheidung.

Quellen:

• Programming Language Benchmarks
• The Computer Language Benchmarks Game
• TechEmpower Web Framework Benchmarks
• sonic - ByteDance Open-Source JSON-Bibliothek
• actix-web