Le langage de programmation Rust devient si populaire que l'équipe responsable de son développement a décidé de monter une équipe dédiée à la définition du style de codage Rust par défaut. Ce n'est pas l'un des langages les plus populaires au même titre que Java ou Python, mais il est utilisé par les développeurs sur de grands projets d'infrastructure. Rust a été officiellement accueilli par le créateur du noyau Linux Linus Torvalds et a fait des percées dans Android, Windows, Amazon Web Services et le parent Meta de Facebook, pour n'en nommer que quelques-uns.Un engouement pour Rust qui va grandissant
Après 31 ans, un deuxième langage est admis pour le développement du noyau Linux : Rust
Linus Torvalds l’avait promis lors du dernier Open Source Summit : il pousserait pour l’inclusion de Rust for Linux à la version 6.1 du noyau. La manœuvre est désormais en cours comme le confirme un récent Pull Request. Après 31 ans, un deuxième langage sera donc admis pour le développement du noyau : c’est le Rust. Les débats y relatifs tournent au tour de la possibilité d’une mise au rebut du C au profit du langage Rust compte tenu des avantages qu’il introduit. Petite précision néanmoins : pour le moment, le Rust gagne juste une API officielle pour permettre de développer des modules séparés ou pilotes.
Les principaux mainteneurs du noyau Linux ont un âge qui commence par le chiffre 5. Certains se rapprochent même de la soixantaine. Aussi, la communauté du célèbre noyau open source commence à penser au changement de générations. Une nouvelle dont la tranche d’âge se situe dans la trentaine gravit les échelons, mais comme Linus lui-même le souligne : « Il s'avère qu'il est vraiment difficile de trouver des personnes qui sont des mainteneurs » ; un fait lié à ceci que le développement du kernel Linux continue de se faire en C et assembleur – des langages auxquels la vieille génération est plus accoutumée ? C’est une possibilité et elle est susceptible d’expliquer pourquoi 2022 pourrait être l’année du langage Rust au sein du noyau Linux.
« C'est le moment d'arrêter d'initier de nouveaux projets en C ou C++ et de passer à Rust », selon Mark Russinovich de Microsoft
Go, C3, D, … La liste des langages présentés comme des alternatives au C ou au C++ s’allonge avec les années qui passent. Celui qui a frappé un grand coup dans ces tentatives multiples de mise au rebut du langage C est le Rust. En effet, le noyau Linux s’ouvre de plus en plus au langage de programmation système de Mozilla. Ainsi, des voix s’élèvent de plus en plus pour en faire le successeur attitré des langages C et C++. Sans détour Mark Russinovich de Microsoft vient de déclarer que « c’est le moment d’arrêter d’initier de nouveaux projets en langages C ou C++ et de passer à Rust. »
Chez Amazon par exemple, on est d’avis que « choisir Rust c’est opter pour une meilleure sécurisation des logiciels qu’avec le C, mais une efficacité énergétique et une performance d’exécution que seul le C offre. » En effet, certains benchmarks suggèrent que les applications Rust sont plus rapides que leurs équivalents en langage C. Et c’est justement pour ces atouts que sont la parité en termes de vitesse d’exécution en comparaison avec le C, mais surtout pour la sécurisation et la fiabilité que Mark Russinovich recommande le Rust plutôt que le C ou le C++.
ICU4X 1.0, la nouvelle bibliothèque d'internationalisation hautes performances du consortium Unicode, est écrite en Rust
International Components for Unicode (ICU) est un projet open source de bibliothèques C/C++ et Java matures pour la prise en charge d'Unicode, l'internationalisation des logiciels et la mondialisation des logiciels. ICU est largement portable sur de nombreux systèmes d'exploitation et environnements. Il donne aux applications les mêmes résultats sur toutes les plateformes et entre les logiciels C, C++ et Java. Le projet ICU est un comité technique du Consortium Unicode et sponsorisé, soutenu et utilisé par IBM et de nombreuses autres sociétés.
Envoyé par ICU
Partout dans le monde, les gens se connectent avec des smartphones, des montres connectées et d'autres petits appareils à faibles ressources. L'industrie technologique a besoin d'une solution d'internationalisation pour ces environnements qui s'adapte à des dizaines de langages de programmation et à des milliers de langages humains.
Vient alors ICU4X. Comme son nom l'indique, ICU4X est une émanation de la bibliothèque i18n standard de l'industrie publiée par le Consortium Unicode, ICU (Composants internationaux pour Unicode), qui est intégrée dans tous les principaux appareils et systèmes d'exploitation.
Cette semaine, après 2 ans et demi de travail par Google, Mozilla, Amazon et les partenaires de la communauté, le Consortium Unicode a publié ICU4X 1.0, sa première version stable. Conçu à partir de zéro pour être léger, portable et sécurisé, ICU4X tire les leçons de décennies d'expérience pour apporter un formatage de date localisé, un formatage de nombre, un classement, une segmentation de texte, etc. à des appareils qui, jusqu'à présent, n'avaient pas de solution appropriée.
Vient alors ICU4X. Comme son nom l'indique, ICU4X est une émanation de la bibliothèque i18n standard de l'industrie publiée par le Consortium Unicode, ICU (Composants internationaux pour Unicode), qui est intégrée dans tous les principaux appareils et systèmes d'exploitation.
Cette semaine, après 2 ans et demi de travail par Google, Mozilla, Amazon et les partenaires de la communauté, le Consortium Unicode a publié ICU4X 1.0, sa première version stable. Conçu à partir de zéro pour être léger, portable et sécurisé, ICU4X tire les leçons de décennies d'expérience pour apporter un formatage de date localisé, un formatage de nombre, un classement, une segmentation de texte, etc. à des appareils qui, jusqu'à présent, n'avaient pas de solution appropriée.
Chaque langage a des guides de style et, s'il est assez populaire, peut avoir plusieurs guides de style d'utilisateurs majeurs, comme Google, qui a son guide pour C++ (le langage dans lequel Chrome est écrit). Guido van Rossum de Python a également publié ses conventions de style.
Rust, qui a atteint la version 1.0 en 2015, a un guide de style dans le "rustfmt" ou "Rust formatting tool" publié sur GitHub.
L'outil formate automatiquement le code Rust pour permettre aux développeurs de se concentrer sur la sortie et vise à réduire la courbe d'apprentissage abrupte à laquelle sont confrontés les nouveaux développeurs Rust. Le guide demande aux développeurs « d'utiliser des espaces, pas des tabulations » et indique que « chaque niveau d'indentation doit être de 4 espaces », par exemple.
Comme l'explique Josh Triplett dans un récent billet de blog Rust : « Le style standardisé aide les développeurs Rust à se sentir à l'aise et à l'aise dans de nombreux projets différents, et le support d'outils de rustfmt facilite la maintenance et l'intégration dans l'intégration continue ».
Mais l'équipe responsable de la rédaction du guide de style entre 2016 et 2018 a « par conception » pris fin. Aussi, il a été décidé de créer l'équipe de style Rust, composée de Triplett, Caleb Cartwright, Michal Goulet et Jane Lusby.
L'équipe s'attaquera d'abord à un « arriéré de nouvelles constructions de langage qui manquent de conseils de formatage » et passera à « la définition et la mise en œuvre des mécanismes pour faire évoluer le style Rust par défaut, puis commencera à introduire des améliorations de style ».
Le travail comprend des changements de langage mineurs, de grands changements structurels et une rétrocompatibilité. L'équipe de style veut concevoir l'outil pour le rendre actuel pour un codage plus facile dans Rust et aider à l'adoption.
Message de Josh Triplett au nom de l'équipe Rust Style
Rust a un style standardisé et une implémentation de ce style dans l'outil rustfmt. Le style standardisé aide les développeurs Rust à se sentir à l'aise et à l'aise dans de nombreux projets différents, et le support d'outils de rustfmt facilite la maintenance et l'intégration dans l'intégration continue. rustfmt fournit également de nombreuses options pour personnaliser le style, mais le guide de style définit les valeurs par défaut et la plupart des projets utilisent ces valeurs par défaut.
Le style Rust standard est le résultat du développement et des discussions au sein de l'équipe de style Rust, entre 2016 et 2018. Après avoir publié le guide de style, l'équipe de style Rust a conclu son travail actif, par conception.
Cependant, à mesure que le langage Rust se développe, nous avons régulièrement besoin d'améliorations du guide de style, par exemple pour prendre en charge de nouvelles constructions de langage. Cela inclut des changements de langage mineurs, ainsi que de nouvelles fonctionnalités très attendues telles que le let-chaining (RFC 2497) et let-else (RFC 3137). De nouvelles constructions comme celles-ci, par défaut, sont ignorées et non formatées par rustfmt, et nécessitent par la suite un formatage ajouté. Une partie de ce travail est revenue à l'équipe de rustfmt ces dernières années, mais l'équipe de rustfmt préférerait mettre en œuvre les déterminations de style faites par une autre équipe plutôt que de faire ces déterminations elle-même.
De plus, rustfmt maintient des garanties de rétrocompatibilité : le code qui a été correctement formaté avec rustfmt ne sera pas formaté différemment avec une future version de rustfmt. Cela évite le désabonnement et évite de créer des échecs CI lorsque les gens utilisent rustfmt pour vérifier le style dans CI. Cependant, cela empêche également de faire évoluer le style Rust pour prendre en compte les désirs de la communauté et améliorer le formatage au fil du temps. rustfmt fournit diverses options de configuration pour modifier sa mise en forme par défaut, et nombre de ces options représentent des modifications que de nombreuses personnes de la communauté aimeraient voir activées par défaut.
Par exemple, de nombreuses personnes préfèrent formater leurs lignes d'utilisation en trois blocs*: les importations depuis la bibliothèque standard, les importations depuis des caisses externes, puis les importations depuis des modules au sein du même projet. rustfmt prend en charge cela via l'option group_imports = StdExternalCrate, mais ne peut pas en faire la valeur par défaut sans provoquer des échecs de CI dans les projets existants. Nous avons besoin d'un moyen de faire évoluer le style Rust par défaut de manière compatible, similaire dans l'esprit aux mécanismes que nous utilisons pour les éditions Rust : permettre au style existant de continuer à fonctionner et permettre aux gens d'opter pour un nouveau style.
Pour résoudre ces deux problèmes, la RFC 3309 a relancé l'équipe de style Rust, avec trois objectifs*:
- Prendre des décisions sur le style des nouvelles constructions Rust
- Faire évoluer le style Rust existant
- Définir des mécanismes pour faire évoluer le style Rust en tenant compte de la rétrocompatibilité
Nous ne prévoyons pas d'apporter des changements de style bouleversants*; l'aspect et la convivialité de Rust resteront en grande partie les mêmes. Les évolutions vers le style Rust par défaut consisteront en grande partie en des options rustfmt établies que les gens activent déjà largement, ou activeraient si elles étaient stables.
Nous nous attendons à ce que le travail initial de l'équipe de style se concentre sur la suppression d'un arriéré de nouvelles constructions de langage qui manquent de conseils de formatage. Ensuite, nous chercherons à définir et à mettre en œuvre les mécanismes pour faire évoluer le style Rust par défaut, puis commencerons à introduire des améliorations de style.
Source : Rust
Et vous ?
Que pensez-vous de Rust en général ? Qu'est-ce qui, selon vous, peut justifier sa popularité ? Que pensez-vous de cette décision de dédier une équipe à la définition du style de codage Rust par défaut ?Voir aussi :
Rust 1.64 est disponible et apporte des améliorations à .await avec IntoFuture, rust-analyzer est désormais disponible via rustup 
