Discussion :

[Bill Fassinou]

L'équipe de npm choisit Rust pour gérer les goulots d’étranglement liés au CPU au détriment de Go, C, C++ et Java
voici les raisons de ce choix

npm Inc., la société derrière npm, le gestionnaire de paquets officiel de Node.js, a publié le 25 février passé, un rapport d’étude décrivant que le langage de programmation Rust possède une meilleure façon de gérer les dépendances que d’autres langages tels que Go, C et C++. L’équipe a donc choisi Rust pour faire une nouvelle implémentation d’un service du registre npm pour éviter à la longue les problèmes de performance. npm demeure à ce jour le plus grand registre de logiciel au monde avec environ 1,3 milliard de téléchargements de paquets par jour. C’est un outil (programme) gérant les bibliothèques de programmation JavaScript pour Node.js. Les développeurs utilisent npm pour partager et emprunter des packages, et de nombreuses organisations l’utilisent également pour gérer le développement privé.

Cela aide les nouveaux projets à éviter de réécrire des composants de base ou certaines bibliothèques en utilisant les extraits de code partagés. Chacun de ces extraits de code peut dépendre de nombreux autres codes sources ouverts. C’est cet état de choses qui faire ressortir la nécessité de disposer d’outils de gestion de bibliothèque ou de dépendances. Dans le cas contraire, cela obligerait les développeurs à fournir plus d’efforts qu’il n’en faut pour gérer ces bibliothèques. Il existe des équivalents du npm comme Maven ou Gradle pour gérer les bibliothèques Java. Il y a également un autre outil concurrent du npm développé par Facebook portant le nom de Yarn pour gérer les bibliothèques JavaScript. Dans le rapport d’étude présenté par la société, il est question des performances d’un service lié au CPU (processeur).

En effet, explique l’équipe d’évaluation, en analysant le service d'autorisation qui détermine si un utilisateur est autorisé à publier un paquet particulier, par exemple, ils ont découvert une tâche liée au processeur qui, à la longue, pourrait devenir un goulot d'étranglement de performance. L’équipe npm a donc profité de l'occasion pour envisager d'autres implémentations pour moderniser le code et améliorer les performances avant la dégradation du service, écrit npm Inc. dans son rapport. Parmi les premières technologies auxquelles a pensé l’équipe pour réaliser sa nouvelle implémentation du service figuraient le C++, le C et le Java. Cependant, ces derniers ont vite été abandonnés par l’équipe à cause de leur gestion plus que compliquée de la mémoire. Pour Chris Dickinson, ingénieur chez npm Inc., le C et le C++ nécessitent une expertise en gestion de la mémoire afin d’éviter de faire des erreurs pouvant causer des problèmes catastrophiques. Ils constituent donc un choix avec un risque élevé pour écrire une application HTTP à l’endroit du Web.

Dans le même temps, Java a, lui aussi, été exclu de la considération en raison de l'exigence de déployer la JVM et les bibliothèques associées ainsi que tout programme sur leurs serveurs de production. Il s'agissait d'une quantité de complexité opérationnelle et de frais généraux de ressources qui était aussi indésirable que l'insécurité du C ou du C++, explique l'équipe. En résumé à cela, l’équipe indique que ces trois langages ne répondaient simplement pas aux trois critères recherchés pour pouvoir implémenter le service. Elle cherchait plutôt un langage capable de gérer la mémoire de manière sécurisée, qui peut être compilé en un binaire autonome et facilement déployable et avec des performances surpassant celles du JavaScript. Go et Rust semblaient y correspondre. Seulement, après la réécriture du système d’autorisation à l’aide de Go, l’équipe s’est dite déçue de l’absence d’une solution de gestion des dépendances au sein du langage. « La perspective d'installer des dépendances globalement et de partager des versions sur n'importe quel projet Go (la norme dans Go au moment de l'évaluation) n'était pas attrayante », s’est-elle justifiée.

Quant à l’implémentation avec Rust, ils ont dit avoir constaté un contraste frappant dans la gestion des dépendances. D’après l’équipe, Rust possède un outil en ligne de commande appelé Cargo qui partage des similitudes avec l’outil en ligne de commande de npm. Cargo coordonne les versions de chaque dépendance indépendamment pour chaque projet afin que l'environnement dans lequel un projet est construit n'affecte pas l'exécutable final, a expliqué l’équipe. Elle témoigne que même si la prise en main de Rust a pris plus de temps qu’il en fallait, les résultats en valaient la peine. À en croire les propos de l’équipe, la conception du langage Rust charge en début de processus les décisions concernant l'utilisation de la mémoire afin d'assurer la sécurité de la mémoire d'une manière différente des autres langages de programmation courants. L’équipe dit avoir réussi à réimplémenter le service d’autorisation et à déployer la version Rust pour la production qui plus d’un an après, n’a encore présenté aucun problème.

Néanmoins, explique l’équipe, l'ajout de Rust aux services de production de npm présente un inconvénient. Il s’agit de la charge de maintenance que représentent les solutions séparées de surveillance, de journalisation et d'alerte pour la pile JavaScript existante ainsi que la nouvelle pile Rust. Étant donné la jeunesse du langage, continue d'expliquer l'équipe, Rust n'a pas encore de bibliothèques aux normes de l'industrie et de meilleures pratiques à ces fins. L'équipe dit qu'elle espère que cela soit fait à l'avenir. Pour l’heure, npm Inc. voit Rust comme une solution évolutive et simple à déployer. Il maintient l'utilisation des ressources à un faible niveau sans compromettre la sécurité de la mémoire. La gestion des dépendances par Cargo apporte des outils modernes dans le domaine de la programmation de systèmes. Selon l’entreprise, bien qu'il existe encore des pratiques exemplaires et des outils qui pourraient être améliorés, la communauté est mise sur pied pour assurer son succès à long terme. C'est pour ces raisons que npm a choisi Rust pour gérer les goulots d'étranglement liés au CPU, a conclu l'équipe.

Source : Rapport de l'étude

Et vous ?

Que pensez-vous du choix de l'équipe de npm ?
Comme l'équipe npm, pensez-vous que Rust gère mieux la mémoire que les autres langages ? Quelles sont vos raisons ?
Quels autres langages suggéreriez-vous à l'équipe npm pour la gestion du CPU ?

Voir aussi

L'équipe en charge de Rust annonce Rust 2018, deux mots-clés ont été ajoutés, async et await pour faciliter l'écriture de code asynchrone

La version stable de Rust 1.29 est désormais disponible ! premier jet de l'auto-correction des lints et potentielle compatibilité avec Clippy

La rubrique Rust : Cours et tutoriels Rust et la FAQ sur la programmation en langage Rust

Quel langage pourrait remplacer C ? Après avoir comparé Go, Rust et D, le choix d'Andrei Alexandrescu se porte sur D

Rust, en bref

[Invité]

npm demeure à ce jour le plus grand registre de logiciel au monde avec environ 1,3 milliard de téléchargements de paquets par jour.

En même temps, quand il faut un paquet pour avoir une fonction isOdd et un autre paquet pour avoir isEven et que isEven dépend de isOdd, c'est normal d'avoir 1 milliard de téléchargement par jour. Les autres langages, ils ont juste une lib standard...

[Invité]

Conclusion

Rust is a solution that scales and is straightforward to deploy. It keeps resource usage low without the possibility of compromising memory safety. Dependency management through Cargo brings modern tools to the systems programming domain. While there are still best practices and tooling that could be improved, the community is set up for long-termsuccess. For these reasons, npm chose Rust to handle CPU-bound bottlenecks.

[Aurelien.Regat-Barrel]

En effet d'après leur papier ils ont codé leur besoin en 2j avec Go et 1 semaine avec Rust (ce qui n'est pas surprenant car les langages ne jouent pas dans la même catégorie) mais ils voulaient un package manager qui suive les principes de leur propre philosophie (ce qui peut se comprendre).

Mais accessoirement l'utilisation de Rust chez NPM n'est pas nouveau: y'a ce talk (qui a presque 2 ans) où une dev explique comment elle s'y est prise pour introduire le langage chez NPM:

[vivid]

excusez-moi, mais qui garde leur mer..
on est pas dans la même catégorie.
En plus du bonnet elle doit programmer avec des moufles.

[plop718]

@vivid : Je viens de tomber sur ton commentaire et après que la nausée soit passée je me suis dit que je ne pouvait pas laisser ton commentaire conclure ce thread alors voila ma réponse, pour toi spécialement :

Cette femme est non seulement une grande développeuse mais a plus œuvré pour l'informatique et le développement en règle générale que quiconque sur ce thread. Elle est l'une des personnes qui a créer le language rust (elle fait partie de la team core rust) et le WASM. Elle est passé par la team core npm, nodejs et mozzilla et maintenant cloudflare. Enfin bref elle a bien plus de légitimité dans le milieu du dev que toi et pourtant tu te crois autoriser a dire :

on est pas dans la même catégorie.
En plus du bonnet elle doit programmer avec des moufles.

Je t'invite a te renseigner sur son travail actuel est passé, peut être y réfléchira tu a 2 fois avant de balancer une énormité comme tu viens de le faire.

Les misogyne sont la honte de la profession, nous décrédibilisent et nous empêche d'avancer plus vite en nous privant de talents comme Ashley qui n'osent se démarquer à cause des commentaires de petits gars de ton envergure.


PS: je serais curieux de savoir ce que tu as fait dans ta vie qui mérite de rentrer dans la postérité ? De quel catégorie fait tu parti qui te t’autorise a avoir un tel jugement sur cette femme ?