Chez Galadrim, nous avons l'habitude de travailler avec de nombreux langages et frameworks Web différents. Si chaque équipe et chaque développeur ont leur préférences, nous sommes convaincus que choisir l'outil le plus adapté au projet est la meilleure solution.
En ce sens, nous avons été amenés à réaliser de nombreux backends en TypeScript et Python -nos stacks les plus communes- mais également en Go, Rust, PHP, ou encore C#. A force, nous nous sommes demandés s'il existait de vraies différences de performance entre ces langages et certains de leurs frameworks respectifs à l'échelle de nos projets. Quand et comment privilégier une technologie plutôt qu'une autre ?
Afin de répondre à cette question, nous avons réalisé un benchmark interne comparant 4 langages populaires, Go, Rust, Python et JavaScript pour un projet web typique, une API REST à destination d'un mini réseau social.
Voici notre retour d'expérience.
I. Grafana K6, un outil de test de charge moderne
Pour réaliser ce benchmark, nous avons utilisé Grafana K6, un outil open-source, écrit en Go, et conçu par Grafana Labs qui vient faire concurrence à des outils tels que JMeter construit sur la JVM (Java).
Ce qui change la donne
Simple d'utilisation : Conçu pour être utilisé en CLI, K6 est très simple d'utilisation et les scénarios de tests sont de simples scripts JavaScript (ou TypeScript). N'importe quel développeur de l'équipe peut lire, écrire et maintenir les tests sans formation spécifique.
Performance et efficacité : Étant écrit en Go, K6 consomme très peu de mémoire et est très performant. Une seule machine standard peut ainsi simuler des milliers d'utilisateurs virtuels là où d'autres outils nécessiteraient un cluster entier.
Intégration CI/CD : Étant un outil CLI scriptable, il s'intègre nativement dans vos pipelines (GitHub Actions, GitLab CI, etc.) pour automatiser les tests de non-régression de performance.
Comment ça marche ?
K6 orchestre des VUs (Virtual Users). Chaque VU agit comme un utilisateur obéissant à un script prédéfini répété indéfiniment :
Il exécute des requêtes HTTP (ou WebSocket, gRPC).
Il vérifie les réponses (status 200, contenu du JSON...).
Il respecte des temps de pause (sleep) pour simuler un comportement humain réaliste.
L'outil agrège ensuite les résultats en temps réel et fournit des métriques bien plus pertinentes qu'une simple "moyenne" pour comprendre la latence ressentie par les utilisateurs. Une métrique intéressante est le 95ème centile ou p95 qui correspond à la valeur telle que 95% des latences observées sont en dessous et 5% sont au-dessus.
II. Le protocole de test : un mini réseau social
Pour que les résultats soient pertinents, nous avons simulé un cas d'usage représentatif des projets que nous développons pour nos clients : un mini réseau social. Ainsi, nos backends de test doivent implémenter les fonctionnalités suivantes :
Authentification : Login, récupération du profil courant.
Gestion des utilisateurs : Création, listing, modification de profil.
Gestion des posts : Publication, lecture de flux, suppression.
Fonctionnalités d'un réseau social : Commentaires, likes / unlikes.
Environnement technique
Nous voulions également limiter au maximum l'utilisation d'outils propres à chaque écosystème pour une raison double : ne pas alourdir les tests avec des dépendances supplémentaires et éviter d'introduire des biais lors de la comparaison des performances.
Dans ce but, nous avons décidé de partir d'un simple fichier OpenAPI décrivant l'API puis d'implémenter de façon minimaliste les routes dans chaque langage sans utiliser d'ORM ou d'outil de mapping JSON. Nous avons écrit nos requêtes de manipulation de la base de données directement en SQL, afin que chaque backend exécute exactement la même requête avec la même base, de la même façon.
Les tests ont été réalisés sur un MacBook Pro M3 (36 GB RAM) avec des conteneurs Docker limités à 4 CPUs et 8 GB de RAM pour chaque backend. Les valeurs absolues de requêtes par seconde (RPS) mentionnées ci-après ne sont pas à prendre telles quelles mais plutôt à comparer entre elles car dépendantes de votre configuration.
Le scénario de test de chaque VU
Notre workflow de test ne se contente pas de spammer une route, il simule le parcours complet d'un utilisateur :
Login administrateur et création d'un nouvel utilisateur.
Login du nouvel utilisateur.
Publication d'un post.
Lecture du feed.
Ajout de commentaire et like sur un post.
Suppression des données (nettoyage).
Nous avons fait varier la charge de 50 VUs à 1000 VUs simultanés pour voir quand les backends craquent.
Ci-dessous un exemple d'exécution pour Express (Bun, 1000 VUs).
III. Les enseignements
Performance brute : le duel Go vs Rust
Si vous cherchez la performance pure pour des systèmes à très fort trafic, le match se joue entre Go et Rust. Sur l'échelle de nos tests, il n'y a pas de gagnant clair et les deux langages atteignent des performances similaires (> 20 000 RPS). Ces langages brillent également par leur résilience sous forte charge avec des p95s autour de 85ms, bien en-dessous des 200ms acceptées dans le cadre de ce test.
Go (avec Fiber) : Sa simplicité et sa gestion des goroutines en font un monstre d'efficacité pour les API web.
Rust (avec Axum) : Avec de très solides performances, Rust offre également des garanties de sécurité mémoire et de stabilité inégalées malgré une prise en main plus complexe.
Verdict : Si vous avez besoin de performance brute, Go et Rust sont des choix solides. Tandis que le premier met l'accent sur l'expérience de développement, le second brille dans la confection de systèmes robustes.
Rapidité de développement : Python vs JavaScript (Node/Bun)
Pour la majorité des projets (MVP, startups, outils internes), la vitesse de développement prime souvent sur la performance brute. En effet, le langage de programmation choisi est rarement le facteur limitant pour la performance d'un backend en comparaison avec l'optimisation de l'architecture, de la base de données, et des entrées / sorties réseaux ou systèmes.
Python (FastAPI) : Facile à prendre en main, avec une syntaxe concise et claire, excellent pour la data, il montre des limites en terme de performance sous forte charge. Par ailleurs, Python a rapidement un impact important sur la mémoire utilisée côté serveur et ne conviendra donc pas forcément pour des applications à forte contraintes hardware (p.ex. applications embarquées). Dans nos tests, il tient bien la charge "moyenne" mais commence à échouer sous une charge lourde (500+ utilisateurs simultanés) avec un p95 de 420ms pour 1 000 VUs. C'est un excellent compromis entre la productivité et la performance, tant que le trafic reste raisonnable (~7 000 RPS).
JavaScript (Node vs Bun) : Node.js est le runtime JavaScript le plus populaire, et il est basé sur le moteur V8 de Google. Bun est un runtime JavaScript plus récent, et il est construit sur le moteur JavaScript d'Apple. JavaScript (mais aussi TypeScript) est un langage de programmation qui permet de développer des applications web. Il a l'énorme avantage de pouvoir être exécuté côté client et côté serveur, ce qui permet de développer des applications web full-stack avec un seul langage. Cela implique la possibilité de partager du code commun entre le client et le serveur (business logic, validation de données, types, etc.), mais aussi de n'utiliser et ne maîtriser qu'un seul langage pour le développement de l'application. Avec environ 10 000 RPS atteintes dans les deux cas, l'écosystème JavaScript propose de solide performances tout en conservant un p95 de ~170ms dans le pire scénario.
Verdict : Si vous avez une équipe plutôt full-stack, JavaScript/TypeScript est une option très solide pour obtenir d'excellentes performances sans changer de langage. Pour de l'utilisation purement backend ou de la Data Science avec une itération rapide Python est une très bonne alternative mais demandera une architecture plus robuste (caching, scaling horizontal) et plus d'attention à l'optimisation du code pour atteindre des performances comparables.
