Pour un service HTTP classique, Go et Rust sont tous deux tout à fait à la hauteur. Un mauvais choix ne mettra pas le projet en péril, mais un bon choix permettra de gagner un temps considérable. Voici les critères à prendre en compte.
Vitesse d'intégration des nouveaux arrivants
Go l'emporte haut la main. Le langage est volontairement minimaliste : une personne connaissant un autre langage peut comprendre le code Go en quelques jours et commencer à l'écrire en quelques semaines. Il faut plusieurs mois pour se familiariser avec les concepts de propriété et de cycle de vie en Rust.
Pour une équipe qui effectue souvent des remplacements ou un projet sur lequel de nombreuses personnes interviennent pour apporter des modifications, c'est le facteur le plus déterminant.
Retard de queue
Go dispose d'un système de ramasse-miettes. Ce système moderne est déjà très performant, avec des temps d'arrêt généralement inférieurs à une milliseconde, mais il persiste et s'accentue lorsque la mémoire est saturée.
Rust ne connaît aucun temps d'arrêt. Si votre exigence est que « 99,9 % des requêtes doivent être inférieures au seuil X » et que ce seuil est strict, cette différence devient déterminante. Si l'indicateur qui vous intéresse est la médiane, elle est pratiquement négligeable.
Mémoire et coûts des serveurs
Le service Rust utilise généralement beaucoup moins de mémoire vive, car il ne nécessite pas de zone tampon pour le ramasse-miettes. À l'échelle de quelques serveurs, cette différence n'est pas significative. À l'échelle de plusieurs milliers, elle devient toutefois importante.
Suggestion concise
- Services métier, API internes, outils d'exploitation — Go, presque toujours la bonne solution
- Composants en temps réel, proxys, traitement de flux de données volumineux — Rust en vaut la peine
- L'équipe ne maîtrise pas encore les deux — Go en premier, puis Rust lorsqu'on atteint une limite réelle et non imaginaire
Thảo luận