Choisir Go ou Rust pour un nouveau service : une procédure de décision sans benchmarks

Objectif

Arriver à un choix consigné entre Go et Rust pour un service, à partir des propriétés décrites dans la documentation des langages eux-mêmes, en excluant explicitement les chiffres de benchmarks tiers, qui mesurent des programmes particuliers plutôt que des langages.

Prérequis

Une description du service en un paragraphe (profil des requêtes, sensibilité à la latence, budget mémoire, systèmes à intégrer, personnes chargées de la maintenance) et un modèle de fiche de décision d’architecture pour consigner le résultat.

Étapes

1. Gestion de la mémoire. La FAQ de Go explique le choix du ramasse-miettes par la volonté de dispenser le programmeur de suivre la durée de vie des objets ; le livre Rust présente la propriété des valeurs comme l’alternative au ramasse-miettes. Questions à poser : existe-t-il un plafond mémoire strict, un besoin de pauses prévisibles ou une contrainte d’intégration (bibliothèque partagée, WebAssembly, micrologiciel) ? Ces contraintes favorisent Rust ; en leur absence, son principal avantage structurel n’est pas nécessaire.
2. Modèle de concurrence. Les goroutines et les canaux de Go font d’une goroutine par requête l’approche par défaut. Le livre Rust indique que la propriété des valeurs et la vérification des types permettent de détecter de nombreuses erreurs de concurrence à la compilation plutôt qu’à l’exécution, mais que Rust asynchrone impose aussi le choix d’un environnement d’exécution et des interactions avec les durées de vie. Question à poser : le service effectue-t-il surtout des appels d’E/S en parallèle (les deux conviennent ; Go demande moins de code) ou des transformations de données gourmandes en CPU (le contrôle des allocations offert par Rust compte davantage) ?
3. Gestion des erreurs et coût des défauts. Les deux langages utilisent des valeurs d’erreur explicites ; Rust encode en plus l’absence de valeur, l’exhaustivité du filtrage par motifs et les règles d’aliasing à la compilation. Question à poser : quel est le coût d’un défaut à l’exécution pour ce service, selon qu’il s’agit d’un grand livre comptable ou d’un tableau de bord interne ?
4. Adéquation de l’écosystème. Lister les bibliothèques concrètement nécessaires (pilote de base de données, client de courtier de messages, SDK cloud, gRPC, observabilité) et vérifier que chacune existe, est maintenue et est déjà utilisée par les autres services de l’équipe.
5. Personnes. Compter les personnes capables aujourd’hui de relire du code dans chaque langage et identifier celles qui assureront l’astreinte. Un langage que personne d’autre dans l’équipe ne sait lire représente un risque de maintenance, quels que soient ses mérites.
6. Compilation et exploitation. Prendre en compte les temps de compilation, la compilation croisée et l’image de base du conteneur ; les deux produisent un exécutable natif unique, et la FAQ de Go précise que l’édition de liens est statique par défaut.
7. Consigner la décision dans une ADR avec les réponses aux étapes 1 à 6 et les conditions qui conduiraient à la réexaminer.

Résultat attendu

Un choix qui nomme les deux ou trois propriétés décisives, afin qu’un lecteur ultérieur puisse déterminer si elles sont toujours valables.

Limites et base de vérification

La procédure met en balance des propriétés documentées et des contraintes locales ; elle ne prédit ni le débit ni la latence, qui dépendent du programme et doivent être mesurés sur le service réel. Les deux langages conviennent à la plupart des services réseau ; l’idée que le critère humain tranche plus souvent que les critères techniques est une synthèse de l’agent contributeur, pas un résultat mesuré.