Il s’agit d’un benchmark dans lequel l’auteur, contributeur Ruby, a demandé à Claude Code d’implémenter un mini Git dans 13 langages et a mesuré le temps, le coût et le nombre de lignes de code. Il a effectué 20 exécutions par langage, soit 600 exécutions au total, en utilisant le modèle Claude Opus 4.6.
Les résultats montrent que Ruby (0,36 $) → Python (0,38 $) → JavaScript (0,39 $) ont été les plus rapides et les moins coûteux, tandis que les langages à typage statique étaient 1,4 à 2,6 fois plus lents et plus chers. Avec l’ajout d’un vérificateur de types, Python/mypy est devenu 1,6 à 1,7 fois plus lent, et Ruby/Steep 2 à 3,2 fois plus lent. OCaml et Haskell, malgré un faible nombre de lignes de code, sont restés dans le bas du classement intermédiaire en raison d’une consommation élevée de tokens de réflexion.
L’auteur souligne que « la différence entre 30 et 60 secondes influence la concentration et le flux de développement, et que la vitesse de développement est en elle-même une dimension de la qualité ». Il ajoute toutefois que l’expérience reste limitée à une tâche unique de type prototypage et qu’à grande échelle, le typage statique peut avoir des avantages.
6 commentaires
Il semble que cela mesure un total où se mélangent des variables autres que les caractéristiques propres au langage. Sur GitHub, il y a les résultats du temps requis par expérimentation, mais pas les logs d’exécution. Il est difficile de vérifier ne serait-ce que le temps passé par sous-tâche, qui est pourtant l’indicateur le plus courant, et étant donné la nature des sorties de LLM, la reproduction semble impossible.
L’auteur reconnaît lui-même, dans la section sur les limites, qu’il s’agit d’un travail ponctuel au stade du prototype. Malgré cela, je pense dans l’ensemble qu’il s’agit d’une expérience manquant de transparence et dont les variables n’ont pas été correctement contrôlées.
Ce serait bien de pouvoir comparer différents langages à travers une seule grande expérience,
mais comme ce genre de test n’est pas mené à l’échelle d’une entreprise et qu’il est réalisé par un membre de la communauté, il est sans doute difficile d’obtenir une expérimentation vraiment précise.
J’ai cherché un peu partout, mais il n’est vraiment pas facile de trouver des informations satisfaisantes.
Et c’est assez logique : qui serait prêt à dépenser son propre argent pour concevoir correctement une expérience afin de déterminer quel langage est meilleur ?..
Moi aussi, je pensais que c’était une expérience avec beaucoup de limites, mais j’ai tout de même trouvé positif de voir au moins une tentative..^^
Ce fichu Ruby
L’auteur de Ruby l’a testé, donc évidemment il va dire que Ruby est bien
Mais avec les caractéristiques propres à Ruby, la consommation de tokens ne peut qu’être plus faible. Comme il est bien adapté à l’écriture d’un code concis, cela réduit d’autant la consommation de tokens, notamment le nombre de tokens en sortie.
Haha, il faut garder à l’esprit que je peux être légèrement partial, puisque je suis committer du langage Ruby.
À quelle implémentation en quel langage ferais-tu le plus confiance ? … hahaha