Go vs Rust : Comparaison approfondie des performances — Les chiffres de 2026

En 2026, Go et Rust sont les deux langages les plus populaires dans le développement backend. Go est reconnu pour sa simplicité et son efficacité. Rust est célèbre pour ses performances extrêmes et sa sécurité. Mais concrètement, quelle est la différence de performance ? Et dans quels cas l'un est-il plus rapide que l'autre ?

Dans cet article, on ne parle pas de ressenti, on parle de chiffres. Toutes les données proviennent de Programming Language Benchmarks (mis à jour en juin 2026), de The Computer Language Benchmarks Game et de plusieurs projets de tests communautaires. Les versions des compilateurs sont rustc 1.90.0 et go 1.26.1.

1. Environnement et méthodologie de test

• CPU : AMD EPYC 7763 64-Core (x86_64, 4 cœurs)
• Compilateur Rust : rustc 1.90.0
• Compilateur Go : go 1.26.1 / tinygo 0.40.0
• Dimensions testées : calcul intensif CPU, sérialisation JSON, service HTTP, concurrence, utilisation mémoire

Chaque test est exécuté plusieurs fois et on retient le meilleur résultat. Deux indicateurs clés sont suivis : le temps d'exécution et la mémoire maximale.

2. Calcul intensif CPU : l'écrasante domination de Rust

Les tâches de calcul intensif sont le domaine de prédilection de Rust. Grâce à ses abstractions à coût zéro, l'absence de pauses GC et l'optimisation approfondie de LLVM, Rust domine largement Go dans les scénarios de calcul pur.

2.1 Données de benchmark

binarytrees (construction et parcours d'arbres binaires, Input 18)

• Rust le plus rapide : 1259ms, mémoire max 33,8 Mo
• Go le plus rapide (tinygo) : 1726ms, mémoire max 51,9 Mo
• Go compilation standard : 2343ms, mémoire max 41,9 Mo
• Conclusion : Rust est 1,86x plus rapide que Go en compilation standard, et utilise 21% de mémoire en moins

fannkuch-redux (calcul de permutations de tableaux, Input 11)

• Rust le plus rapide (intrinsics + multithread) : 413ms, mémoire max 2,1 Mo
• Go le plus rapide (multithread) : 724ms, mémoire max 5,5 Mo
• Conclusion : Rust est 1,75x plus rapide, avec 62% de mémoire en moins

mandelbrot (rendu de l'ensemble de Mandelbrot, Input 5000)

• Rust le plus rapide : 246ms, mémoire max 4,8 Mo
• Go le plus rapide : 2666ms, mémoire max 7,7 Mo
• Conclusion : Rust est 10,8x plus rapide, un écart de plus d'un ordre de grandeur !

knucleotide (analyse de séquences de nucléotides, Input 2500000)

• Rust le plus rapide (multithread) : 219ms, mémoire max 28,1 Mo
• Go le plus rapide (multithread) : 676ms, mémoire max 39,5 Mo
• Conclusion : Rust est 3,09x plus rapide, avec 29% de mémoire en moins

2.2 Exemple de code : Rendu de l'ensemble de Mandelbrot

Pourquoi un tel écart sur Mandelbrot ? Parce que ce test implique beaucoup d'opérations en virgule flottante et de vectorisation SIMD. Rust peut utiliser directement la vectorisation automatique de LLVM, alors que les opérations en virgule flottante de Go ne supportent pas SIMD.

Implémentation Rust :

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();
}

Implémentation Go :

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()
}

La logique est quasiment identique. Mais le compilateur Rust vectorise automatiquement la boucle interne, pas Go. C'est l'origine de cet écart de 10x.

2.3 Conclusion pour le calcul intensif

Rust est en moyenne 2 à 10 fois plus rapide que Go pour les tâches de calcul intensif, pour ces raisons :

1. Pas de pauses GC — Rust n'a pas de ramasse-miettes, donc pas de fluctuations de performance dues au GC
2. Optimisation approfondie par LLVM — vectorisation automatique, inlining, déroulage de boucles : ces optimisations dépassent largement celles du compilateur Go
3. Abstractions à coût zéro — itérateurs, fermetures : tout est complètement inliné à la compilation, sans surcoût à l'exécution
4. Meilleur support SIMD — utilisation explicite possible via std::simd (nightly) ou des bibliothèques tierces

3. Sérialisation JSON : l'écart des bibliothèques standard

JSON est le format de données le plus utilisé en développement backend. Les deux écosystèmes ont des solutions matures, mais l'écart de performance reste significatif.

3.1 Données de benchmark

Protocole de test : analyse d'un JSON de réponse API de 2,4 Ko (avec objets imbriqués, tableaux, chaînes), répété 100 000 fois. Mesure du temps total et de la mémoire maximale.

Conclusion : - Rust serde_json est 6,5x plus rapide que la stdlib Go, avec 86% de mémoire en moins - Même avec la bibliothèque tierce la plus rapide de Go (sonic), Rust reste 2,2x plus rapide - L'avantage clé de Rust : zéro allocation mémoire. La désérialisation zero-copy de serde référence directement les octets d'origine, alors que le GC de Go doit allouer de la mémoire heap pour chaque chaîne

3.2 Exemple de code

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();
        // La désérialisation est zero-copy, les chaînes ne sont pas réallouées
        assert_eq!(response.total, 256);
    }
}

Go (encoding/json stdlib) :

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)
        // Chaque désérialisation génère beaucoup d'allocations heap
    }
}

Causes fondamentales de l'écart de performance : 1. encoding/json de Go utilise la réflexion (reflect) pour analyser les champs des structs, ce qui a un coût énorme 2. Les chaînes en Go sont des types valeur, chaque assignation fait une copie 3. serde de Rust utilise de la génération de code à la compilation, pas de réflexion ; et supporte la désérialisation zero-copy 4. interface{} (any) en Go provoque du boxing, avec des allocations supplémentaires

💡 Conseil d'optimisation : si la performance JSON est critique dans votre projet Go, utilisez sonic de ByteDance. C'est la bibliothèque JSON la plus rapide de l'écosystème Go, utilisant JIT et SIMD en interne.

4. Performance des services HTTP : le duel le plus réaliste

Le scénario le plus courant en développement backend, c'est écrire des services HTTP. Cette dimension est la plus proche d'un environnement de production, et celle qui intéresse tout le monde.

4.1 Données du benchmark TechEmpower

TechEmpower est le benchmark de frameworks web le plus权威 (faire autorité). Voici les deux scénarios les plus représentatifs : sérialisation JSON et texte brut.

Sérialisation JSON (sérialiser un objet simple et le retourner)

Réponse texte brut (retourner "Hello, World!")

Conclusion : - Rust actix-web est 2,9x plus rapide que la stdlib Go en texte brut, et 4,3x plus rapide que Gin - fasthttp de Go se défend bien, mais il reste un écart de 1,8x - L'écart de latence P99 est encore plus marqué : la latence de queue de Rust est bien plus stable que celle de Go, grâce à l'absence de pauses GC

4.2 Exemple de code : le service HTTP le plus simple

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 stdlib) :

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))
}

La complexité du code est similaire, Go est même plus simple. Mais l'écart de performance se situe au niveau du runtime :

1. Rust utilise le runtime asynchrone tokio, tous les traitements de requêtes sont des Future à abstraction à coût zéro
2. Les goroutines de Go sont légères, mais le planificateur a son propre coût, et le GC suspend toutes les goroutines
3. Rust n'a pas de GC, la latence de queue est extrêmement stable ; la latence P99 de Go peut être 3 à 5 fois la latence moyenne

5. Comparaison approfondie des modèles de concurrence : goroutine vs async/await

La concurrence est l'un des domaines où Go et Rust diffèrent le plus. Les deux utilisent des modèles de concurrence radicalement différents, chacun avec ses forces et ses faiblesses.

5.1 Comparaison des modèles

Modèle CSP de Go (goroutine + channel) : - Les goroutines sont des threads verts, avec une pile initiale de seulement 2 Ko, redimensionnable dynamiquement - Le planificateur utilise un planificateur M:N (modèle G-M-P), planification en espace utilisateur, coût de commutation très faible - Les channels offrent une communication inter-coroutines typée - Style d'écriture : synchrone, on écrit comme du multithreading, mais c'est en fait de la coroutine - Courbe d'apprentissage : faible, les goroutines ne présentent quasiment aucune difficulté

Modèle async/await de Rust (tokio/async-std) : - Les fonctions async sont compilées en machines à états (State Machine), chaque Future est un type enum - L'exécution dépend d'un runtime asynchrone (tokio est le plus courant), basé sur epoll/kqueue - Coroutine sans pile : la taille de chaque Future est déterminée à la compilation, l'utilisation mémoire est contrôlable - Style d'écriture : asynchrone, nécessite un marquage explicite avec async/await - Courbe d'apprentissage : élevée, les concepts de durée de vie, Pin, Send/Sync constituent un seuil important

5.2 Performance en concurrence

Scénario de test : lancement de 100 000 tâches concurrentes, chaque tâche effectue un calcul simple (30ème terme de la suite de Fibonacci). Mesure du temps total et de la mémoire maximale.

Conclusion : - Chaque tâche async de Rust consomme moins de mémoire (0,6 Ko vs 2,4 Ko), car Future est un enum déterminé à la compilation, alors que les goroutines ont la surcharge de la gestion de pile au runtime - Rust est 2,15x plus rapide, principalement grâce à l'absence de pauses GC et une meilleure efficacité de planification

5.3 Comparaison des styles de code concurrent

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);
}

Résumé des différences de style : - Le code Go est plus concis et intuitif, go func() lance une coroutine en une ligne, la communication par channel est limpide - Rust nécessite un traitement explicite de async/await et du type Result, le code est un peu plus long - Le pattern sync.WaitGroup de Go est remplacé par JoinHandle en Rust, la sémantique est similaire mais l'écriture diffère

5.4 Sécurité de la concurrence

Sécurité de la concurrence en Go : - Repose sur la discipline du développeur : go vet -race détecte les courses aux données - Les channels encouragent « ne communiquez pas en partageant de la mémoire, partagez de la mémoire en communiquant » - Mais en pratique, sync.Mutex est très utilisé, et les courses aux données restent une source fréquente de bugs

Sécurité de la concurrence en Rust : - Garantie à la compilation : les traits Send et Sync empêchent les courses aux données à la compilation - Le système de propriété prévient naturellement les pointeurs pendants et les use-after-free - spawn de tokio exige que les Future implémentent Send, garantissant à la compilation la sécurité entre threads - Coût : courbe d'apprentissage raide, les débutants luttent souvent contre le compilateur

💡 Différence fondamentale : la sécurité de la concurrence en Go est une « discipline au runtime », en Rust c'est une « loi à la compilation ». Rust est plus sûr, mais Go est plus libre.

6. Analyse approfondie de l'utilisation mémoire : le coût du GC

La mémoire est le facteur qui impacte le plus directement les coûts à l'ère du cloud. Un service économe en mémoire signifie moins de serveurs et des factures plus basses.

6.1 Comparaison des modèles mémoire

Gestion mémoire de Go : - Utilise un GC mark-and-sweep (marquage concurrent amélioré dans Go 1.24) - Objectif de pause GC : moins de 0,5ms (configuration par défaut GOGC=100) - Le runtime lui-même occupe environ 4 à 8 Mo (planificateur de goroutines, métadonnées GC, etc.) - Chaque goroutine a une pile initiale de 2 Ko, pouvant croître jusqu'à 1 Go - Les pauses GC sont courtes, mais en haute concurrence elles peuvent se produire plusieurs fois par seconde

Gestion mémoire de Rust : - Pas de GC, repose entièrement sur le système de propriété et RAII - Surcoût runtime proche de zéro (uniquement les enregistrements epoll de tokio et autres overheads minimaux) - Utilisation mémoire totalement prévisible, pas de pics mémoire dus au GC - La taille de chaque Future/Task est déterminée à la compilation, pas de croissance dynamique de pile

6.2 Comparaison mémoire en situation réelle

Scénario : exécution d'un service Web API en charge moyenne (1000 QPS, avec requêtes base de données et sérialisation JSON)

Constat clé : - La mémoire en état stable de Rust n'est que 1/5 à 1/9 de celle de Go - La mémoire de Go fluctue beaucoup, il faut réserver plus de mémoire pour le « gonflement » du GC - En cas de pic de haute concurrence, la mémoire max de Go est 9 fois celle de Rust - Cela signifie qu'un serveur de 2 Go peut supporter 5 à 8 fois plus de charge avec Rust

6.3 Risques de fuites mémoire

• Go : les fuites de goroutines sont le problème le plus courant. Oublier de fermer un channel, une goroutine bloquée en attente d'un signal qui n'arrive jamais : tout cela fait croître la mémoire indéfiniment
• Rust : le système de propriété élimine à la compilation la plupart des possibilités de fuites mémoire. Mais les références circulaires de Rc/Arc peuvent encore en causer (il faut utiliser Weak pour les briser)

💡 Impact sur les coûts : si votre service nécessite 100 serveurs Go, passer à Rust pourrait n'en nécessiter que 15 à 20. Pour une architecture microservices à grande échelle, cette différence impacte directement les coûts d'infrastructure annuels à hauteur de millions.

7. Recommandations de choix technologique : Go ou Rust ?

On a vu les chiffres, mais le choix d'un langage ne se résume pas à des benchmarks. L'efficacité d'ingénierie, les compétences de l'équipe et la maturité de l'écosystème sont tout aussi importants. Voici un cadre de décision pratique.

7.1 Quand choisir Go

Go est recommandé pour : - Services Web API à développement rapide : les frameworks comme gin/echo sont très productifs, idéaux pour les services CRUD centrés sur la logique métier - Architecture microservices : stdlib puissante, déploiement simple (binaire unique), les goroutines sont naturellement adaptées aux nombreuses connexions concurrentes - Outils DevOps/cloud native : Docker, Kubernetes, Terraform sont écrits en Go, l'écosystème est naturellement aligné - Équipe avec expérience limitée : la courbe d'apprentissage de Go est douce, un débutant peut écrire du code métier en une semaine - Itérations rapides nécessaires : compilation rapide (niveau seconde), rechargement à chaud pratique, adapté au développement agile

Utilisateurs typiques : ByteDance (backend TikTok), Google (nombreux services internes), Uber, Dropbox

7.2 Quand choisir Rust

Rust est recommandé pour : - Systèmes à performances extrêmes : moteurs de recherche, moteurs de base de données, files de messages, serveurs de jeux - Environnements à ressources limitées : appareils IoT, edge computing, systèmes embarqués (mémoire contrôlable à quelques Mo) - Systèmes à haute fiabilité : systèmes de trading financier, nœuds blockchain (les garanties de sécurité à la compilation réduisent les incidents en production) - Tâches intensives en calcul : traitement d'images, encodage/décodage audio et vidéo, cryptographie, calcul scientifique - Remplacement de C/C++ : programmation système, développement de pilotes, bibliothèques réseau haute performance

Utilisateurs typiques : Cloudflare (edge computing), Discord (migré de Go vers Rust), Dropbox (moteur de synchronisation de fichiers), Figma (moteur de rendu)

7.3 Tableau de décision rapide

Choisissez Go si : - ✅ Votre service est à forte intensité I/O (beaucoup de requêtes BDD, appels API externes) - ✅ Votre équipe n'a pas d'expérience en programmation système - ✅ Vous devez livrer rapidement, le temps compte plus que la performance - ✅ Le service tourne dans un environnement conteneurisé/K8s, la mémoire n'est pas un goulot

Choisissez Rust si : - ✅ Votre service est à forte intensité CPU (beaucoup de calcul, chiffrement, compression) - ✅ La latence de queue (P99) est critique pour votre activité - ✅ Le coût mémoire est la dépense principale, une optimisation extrême est nécessaire - ✅ Votre équipe a un background C/C++ et est prête à investir dans l'apprentissage - ✅ Le projet a un cycle de vie long, l'investissement dans la performance en vaut la peine

7.4 Solution hybride : pourquoi choisir l'un ou l'autre ?

En réalité, beaucoup d'équipes optent pour une architecture hybride Go + Rust :

• Go pour la couche logique métier : développement rapide, itérations flexibles
• Rust pour les modules goulots de performance : les tâches intensives en calcul sont écrites en Rust sous forme de bibliothèques C ABI, appelées par Go via cgo

package main

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

func ProcessData(input []byte) []byte {
    // Appel du module de calcul haute performance compilé en Rust
    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))
}

Cette approche vous donne à la fois la productivité de Go et les performances de Rust. Discord a adopté une solution similaire : Go pour les services métier, Rust pour le module de calcul central du service de notifications push.

Résumé : un tableau pour voir tous les écarts

Recommandation finale :

• Vous privilégiez la vitesse de développement et l'efficacité de l'équipe → choisissez Go
• Vous privilégiez les performances extrêmes et l'efficacité des ressources → choisissez Rust
• Vous voulez les deux → Go pour la couche métier + Rust pour les modules critiques en performance

Il n'y a pas de « meilleur » langage, seulement le langage le plus adapté à votre contexte. On espère que cette analyse basée sur les données vous aidera à faire un meilleur choix technologique.

Références :

• Programming Language Benchmarks
• The Computer Language Benchmarks Game
• TechEmpower Web Framework Benchmarks
• sonic - Bibliothèque JSON open source de ByteDance
• actix-web