Go en Rust : deux réponses au même problème

Go et Rust occupent aujourd'hui la même niche : le système, l'infrastructure, le réseau, les conteneurs. On les compare sans arrêt, souvent pour de mauvaises raisons. Ils ne se disputent pas le même poste.

Ce que Go a voulu résoudre

Go naît chez Google à la fin 2007. Robert Griesemer, Rob Pike et Ken Thompson posent les objectifs sur un tableau blanc le 21 septembre 2007. Le problème n'était pas théorique : les builds de C++ chez Google duraient des heures, la gestion des dépendances était un cauchemar, et personne n'avait envie d'attendre dix minutes pour compiler une modification d'une ligne.

La réponse tient en trois mots : simplicité, vitesse, concurrence.

Go compile vite. Très vite. Il gère les goroutines et les channels nativement, ce qui rend le code réseau lisible sans empiler des callbacks. La bibliothèque standard contient un serveur HTTP utilisable en production sans dépendance externe.

Le prix à payer, tu le découvres après quelques semaines. Les génériques n'arrivent qu'en 2022, avec Go 1.18, et restent limités. La gestion d'erreurs se fait à coups de `if err != nil` répétés jusqu'à l'écœurement. Le garbage collector fait son travail, mais tu ne décides pas quand.

Go sort en open source le 10 novembre 2009. La version 1.0 arrive en mars 2012, avec une promesse qui compte pour les entreprises : le code écrit pour Go 1 continuera de compiler. Cette promesse a été tenue.

Docker, Kubernetes, Terraform, Prometheus, etcd. Tous écrits en Go. Ce n'est pas un hasard : Go est fait pour les outils d'infrastructure, pas pour les noyaux.

Ce que Rust a voulu résoudre

Rust commence en 2006 comme projet personnel de Graydon Hoare. Pas de commanditaire, pas d'équipe. Juste quelqu'un qui en avait assez des bugs mémoire en C++.

Mozilla Research sponsorise le projet à partir de 2009, en cherchant un remplacement à C++ pour le moteur de Firefox. La version 1.0 sort en mai 2015. Entre le début et la 1.0, neuf ans. Ce délai dit quelque chose sur la difficulté du problème.

Le borrow checker est le cœur de Rust. Il vérifie à la compilation que tu ne peux pas avoir deux références mutables simultanées, ni utiliser une valeur après l'avoir déplacée. Pas de null, pas de double free, pas de data race. Le compilateur refuse de produire un binaire qui contiendrait ces erreurs.

C'est une garantie que ni C ni C++ n'offrent. C'est aussi une contrainte qui te fait réécrire ton architecture au lieu de contourner le compilateur.

Rust n'a pas de garbage collector. Tu contrôles la mémoire, comme en C, mais le compilateur t'empêche de te tirer une balle dans le pied. Pour un driver, un noyau, un système embarqué, c'est exactement ce qu'il faut.

Pour un service web qui doit sortir en trois semaines, c'est une autre histoire.

Le coût réel de chaque choix

Choisir Go, c'est choisir la vitesse de développement. Un développeur qui connaît Python ou Java produit du Go utile en quelques jours. La syntaxe tient sur une page. Les outils (`gofmt`, `go test`, `go mod`) sont intégrés et ne se battent pas entre eux.

Choisir Go, c'est aussi accepter que le langage te protège peu. Une interface nil provoquera un panic à l'exécution, pas à la compilation. Un accès concurrent à une map sans verrou fera planter le programme de manière imprévisible. Le langage ne t'empêche pas d'écrire du mauvais code, il rend juste le bon code facile à lire.

Choisir Rust, c'est choisir la correction. Une fois que ton code compile, une catégorie entière de bugs a disparu. Les performances égalent celles du C, parfois les dépassent. Le contrôle sur l'allocation est total.

Choisir Rust, c'est aussi accepter une courbe d'apprentissage qui décourage. Le borrow checker rejette ton premier design, puis le deuxième. Les temps de compilation sont longs. L'écosystème asynchrone, avec Tokio, reste plus complexe à maîtriser que les goroutines. Tu écriras moins de code par jour, mais tu le débogueras moins la nuit.

Il n'y a pas de version de Rust qui compile plus vite que Go. Il n'y a pas de version de Go qui garantit l'absence de data races. Ces deux phrases sont définitives.

Ce que ça donne en production

Go s'impose là où il faut livrer des services qui tiennent la charge. Une API REST, un proxy, un orchestrateur, un exporter de métriques. Le déploiement se fait avec un binaire statique unique, ce qui simplifie les images Docker à l'extrême. Tu copies le binaire, tu le lances, ça tourne.

Rust s'impose là où une erreur coûte cher. Un pare-feu, un moteur de base de données, un runtime de conteneurs, un composant cryptographique. Firecracker, le micro-VM d'AWS, est écrit en Rust. Les composants critiques de Windows et du noyau Linux accueillent du Rust depuis quelques années.

Tu peux écrire un serveur web en Rust. Beaucoup le font, avec Axum ou Actix. Tu peux écrire un outil système en Go. Beaucoup le font aussi. Mais dans les deux cas, tu travailles contre le grain du langage, et ça se sent au bout de quelques mois.

Ce que personne ne te dira à la place du patron

Le choix ne se joue pas sur les benchmarks. Il se joue sur ton équipe.

Si tu es seul, ou avec deux ou trois personnes qui découvrent le sujet, Go te mènera plus vite à quelque chose qui fonctionne. Rust te demandera de comprendre la propriété, les lifetimes et les traits avant d'écrire quoi que ce soit d'utile. Ce n'est pas impossible, c'est juste plus long.

Si tu as une équipe expérimentée en C++ et un composant dont un bug mémoire peut coûter une journée d'astreinte, Rust vaut son prix. La compilation stricte remplace une partie de la revue de code et des tests de charge.

Si tu dois recruter, regarde le marché. Les développeurs Go sont nombreux et le langage s'apprend vite. Les développeurs Rust sont rares, chers, et souvent déjà employés ailleurs.

Aucun des deux langages ne disparaîtra dans les cinq prochaines années. Aucun des deux ne remplacera l'autre. Go reste l'outil par défaut de l'infrastructure cloud, Rust devient celui des composants où la sécurité mémoire n'est pas négociable.

La question n'est pas « lequel est meilleur ». Elle est : quel type de bug peux-tu te permettre de découvrir en production, et combien de temps tu as avant la première mise en ligne.