Rust vs Go, c’est une guerre de religion. Voici la version pragmatique de quelqu’un qui ship les deux : Go pour la vitesse de dev CRUD, Rust pour la latence de queue, le coût et la fiabilité à l’échelle.
En deux mots#
| Rust (Axum) | Go (Chi/Gin) | |
|---|---|---|
| Latence p50 (JSON+BDD simple) | ~1 à 3 ms | ~2 à 5 ms |
| p99 sous charge | Excellente, stable | Bonne, pauses GC visibles |
| Mémoire par instance | 10 à 30 Mo | 30 à 80 Mo |
| Binaire | Unique, ~5 à 15 Mo | Unique, ~10 à 20 Mo |
| Vitesse de dev (CRUD) | Plus lente (taxe borrow checker) | Plus rapide |
| Confiance au refactor | Très haute | Moyenne (les tests te portent) |
| Recrutement | Plus dur, plutôt senior | Plus facile |
| Écosystème (HTTP/ORM) | Mûrit vite (Axum, SQLx) | Très mature |
Ces chiffres sont des ordres de grandeur sur un petit VPS, Postgres à côté, --release, connexions poolées. Ta charge sera différente. Benchmarke.
Où Rust gagne#
1. Latence de queue. Pas de pauses GC. À 5k à 20k rps avec JSON + BDD, la p99 Rust reste plate pendant que la p99 Go tremble (surtout avec de gros heaps). Si ton SLO c’est p99 < 50ms, Rust te donne de la marge — encore faut-il aller la chercher : voir comment j’ai réduit la p99 de 60 %.
2. Coût. 2x moins de mémoire + plus de rps par cœur = moins d’instances. Passer de 4 à 2 instances paie vite le temps de dev en plus.
3. Fiabilité. Result, match exhaustifs, vérification SQL à la compilation avec sqlx::query!. Des classes entières de bugs null-pointer et d’erreurs non gérées disparaissent. Refactorer 30k lignes fait se sentir en sécurité.
4. Un seul langage pour les chemins chauds. Besoin de JSON SIMD, de parsing custom ou de logique embarquée plus tard ? Tu es déjà en Rust.
Où Go gagne#
1. Vitesse. net/http + sqlc/pgx + golang-migrate : du CRUD shippé en quelques heures. Rust prend 1,5 à 2x plus longtemps pour le même CRUD ennuyeux, surtout avec des juniors.
2. Recrutement. 10x plus de devs backend Go dispos. Le recrutement Rust est lent et senior.
3. Écosystème ennuyeux (en bien). Chaque middleware, chaque SDK cloud, chaque réponse StackOverflow existe. Avec Rust, il faut parfois coller des bouts — la sélection que j’utilise est figée dans les meilleures crates Rust pour une API.
Ma règle#
- CRUD interne, 3 devs, à livrer le mois prochain ? Go.
- API publique, SLO p99, gros rps par cœur, sensible au coût ? Rust + Axum.
- Migration ? Ne réécris pas tout. Extrais d’abord le service chaud (passerelle d’auth, bidding, ingestion). Pattern strangler. Voir mon freelance si tu veux un plan de migration.
Le coût réel du passage à Rust#
Les comparaisons de latence sont les plus faciles à publier et les moins utiles pour décider. Ce qui décide, c’est ce que tu paies pour y arriver.
Le temps de dev#
Compte le double pour du CRUD, sur les deux premiers mois. Pas parce que Rust
est lent à écrire, mais parce que la courbe d’apprentissage se paie sur des
choses précises : les durées de vie dans les types partagés, Arc contre clone,
les erreurs async, le moment où spawn_blocking devient obligatoire.
Passé ce cap, l’écart se resserre sur du code neuf. Il s’inverse sur les gros refactors : changer une signature dans un service Rust de 30 000 lignes, c’est une liste d’erreurs de compilation à traiter. La même opération en Go, c’est une liste de tests à espérer suffisante.
Le recrutement#
C’est le vrai point de friction, et il ne s’améliore pas en six mois. Le vivier Rust backend francophone est petit, plutôt senior, donc plus cher. Beaucoup d’équipes résolvent ça en formant en interne, ce qui reporte le coût sur le temps de dev ci-dessus.
Un test honnête avant de décider : si la personne qui pousse pour Rust part demain, est-ce que quelqu’un d’autre peut maintenir le service ? Si la réponse est non, le problème n’est pas technique.
Le temps de build#
Un service Axum de taille moyenne compile en 1 à 3 minutes à froid, contre quelques secondes en Go. En CI, sans cache de dépendances, chaque pull request le paie. C’est réglable (cargo-chef, cache d’artefacts), mais c’est du travail d’infrastructure que Go ne demande pas.
Une grille pour décider en dix minutes#
Compte un point par ligne vraie. Quatre points ou plus, Rust se défend.
| Signal | Pourquoi ça compte |
|---|---|
| Tu as un SLO p99 écrit, et il est violé | C’est là que les pauses du ramasse-miettes se voient |
| La facture d’instances est un sujet en réunion | Deux à trois fois moins de mémoire par instance change le calcul |
| Le service tourne sur beaucoup d’instances | Le gain par instance se multiplie |
| Le service vit longtemps sans être réécrit | Le coût d’apprentissage s’amortit |
| Un bug de production coûte cher (paiement, santé, embarqué) | Le compilateur écarte des classes entières de bugs |
| Tu as déjà au moins une personne à l’aise en Rust | Sinon, tout le reste devient théorique |
À l’inverse, un seul de ces signaux suffit à rester sur Go : livrer le mois prochain, une équipe qui ne connaît pas Rust et personne pour l’accompagner, ou un service dont on sait déjà qu’il sera jeté dans un an.
Une tactique de migration qui marche#
- Mets le service Rust derrière le même Postgres / NATS / Kafka
- Bascule 10 % du trafic en shadow, compare p50/p99 et taux d’erreur
- Bascule route par route, garde Go en fallback pendant 2 semaines
- Mesure le coût : instances, mémoire, violations p99 avant et après
Ce que j’ai mesuré sur un service que je connais bien, en passant le chemin chaud de Node à Axum : p99 de 220 à 85 ms et mémoire divisée par deux, à charge égale. Un seul cas, sur une charge donnée, ce n’est pas une loi. Le détail de la méthode est dans l’article p99, et l’intérêt n’est pas le chiffre, c’est que tu puisses refaire la mesure chez toi avant de décider. Sur du CRUD ennuyeux, le gain est nul. Ne t’embête pas.
Verdict#
Go optimise le débit de l’équipe. Rust optimise l’efficacité machine et la fiabilité. Choisis selon ta contrainte : time-to-market ou coût et latence à l’échelle.
Tu construis le côté Rust ? Commence par le guide Axum + Postgres et la structure de projet.