IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Rust est devenu si populaire qu'une équipe dédiée a été présentée pour la définition du style de codage Rust par défaut
Afin que les développeurs se sentent le plus à l'aise possible

Le , par Stéphane le calme

13PARTAGES

25  0 
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.

Citation 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.
L'équipe derrière Rust estime que des améliorations plus régulières sont nécessaires dans le guide de style

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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Jeff_67
Membre chevronné https://www.developpez.com
Le 10/10/2022 à 13:30
Rust, c'est comme le sexe chez les ados. Tout le monde en parle, mais personne pratique.
9  1 
Avatar de smarties
Membre émérite https://www.developpez.com
Le 10/10/2022 à 16:28
En France je vois peux d'annonces sur RUST pour le pro.
En revanche, je vois de plus en plus de projets/bibliothèques écrit en RUST.

Pour faire un petit utilitaire CLI, avec la bibliothèque CLAP on commence rapidement.
Pour le web, c'est un peu galère de mettre en toute la stack (framework, middlewares, pool, ...) pour le moment je trouve
4  0 
Avatar de Gugelhupf
Modérateur https://www.developpez.com
Le 12/10/2022 à 10:59
Citation Envoyé par Madmac Voir le message
J'ai vu plusieurs langages qui étaient sensés remplacé le C:

- D
- Dart
- Go
D, Dart, Go ont tous recours à une machine virtuelle, ils peuvent être embarqués dans l'exécutable. Aucun de ces langages n'est prédictible comme peut l'être le C, C++, ou Rust.

Je vois encore beaucoup de gens surpris concernant la popularité de Rust, et j'ai l'impression qu'ils confondent cette popularité avec le dernier framework PHP ou JavaScript. Connaissez-vous beaucoup de langage stricte qui par design:
  • vous empêche de pointer sur une mauvaise zone mémoire
  • vous empêche de vous retrouver avec des NullPointerException dont vous n'arrivez pas à trouver la provenance
  • vous empêche d'utiliser des objets non préparés au multi-threading dans des portions de code exécuté en multi-thread

Donc memory-safe, null-safe, et thread-safe à la fois ?

Alors oui Rust n'a pas autant de lib que Python, les temps de compilations sont longs, mais si Linus Torvalds a accepté d'intégrer ce dernier dans Linux malgré son amour pour C...
2  0 
Avatar de smarties
Membre émérite https://www.developpez.com
Le 12/10/2022 à 20:27
On programme peut être plus lentement en RUST mais :
- on nous force à adopter une bonne méthode pour réaliser son programme mais quand l'exécutable fonctionne il est quasiment stable du 1er coup
- beaucoup de choses sont détectées en amont donc la maintenance derrière sera fortement réduite

Quand on voit la maintenance que certains logiciels impliquent, RUST peut permettre de réduire la taille de l'équipe dédiée (donc réduire les coûts) et le temps passé.

Donc OK on met plus de temps à réaliser son programme mais on en gagne derrière.
En plus, les tutoriels/cours/ressources augmentent donc dans quelques années le temps de développement pourra être un peut réduit grâce à ça
2  0 
Avatar de smarties
Membre émérite https://www.developpez.com
Le 11/10/2022 à 13:14
Pour une démocratisation plus rapide, je pense qu'il manque des bons exemples pour démarrer un projet web avec une stack pro (framework web, logger, pool BDD, template, assets, CSRF, ...)
1  0 
Avatar de Gugelhupf
Modérateur https://www.developpez.com
Le 11/10/2022 à 13:50
Citation Envoyé par smarties Voir le message
Pour une démocratisation plus rapide, je pense qu'il manque des bons exemples pour démarrer un projet web avec une stack pro (framework web, logger, pool BDD, template, assets, CSRF, ...)
Hello, il existe les frameworks web Rust populaires Actix et Rocket, Rust dispose d'une API de log standard, je vu qu'il existait plusieurs lib sync ou async pour PostgreSQL (tout dépend de la BDD) etc

En fait nous vivons dans une air où même si Rust est presque le meilleur sur le papier, les concurrents sont déjà bien imposés, par exemple l'éducation nationale utilise les technos les plus simples à installer pour faire du web (PHP avec WAMP), les professeurs de maths et physique s'orientent vers Python, en entreprise c'est toujours Java et C# qui ont le dessus même si NodeJS a explosé grâce aux PME, les fournisseurs du Cloud et bien sur les frameworks front ultra-populaire en JavaScript/TypeScript, ce n'est pas non plus demain la veille que les grands du jeu vidéo auront le courage de passer leur moteur C++ à une alternative
1  0 
Avatar de smarties
Membre émérite https://www.developpez.com
Le 12/10/2022 à 9:20
Citation Envoyé par Madmac Voir le message
Ma réflexion a choqué, mais je le maintiens. J'ai vu plusieurs langages qui étaient sensés remplacé le C:
Ca ne se fera pas du jour au lendemain. Pour que ça soit significatif, je me dis que dans 15-20 ans ça deviendrait vraiment visible car les nouveaux projets seraient majoritairement menés en RUST.
Et même si RUST fini par remplacer le C, les anciens programmes ne seront pas forcément réécrits en RUST. On ne va pas réécrire quelque chose de stable qui fonctionne, un binding suffit.
1  0 
Avatar de Pyramidev
Expert confirmé https://www.developpez.com
Le 12/10/2022 à 10:43
Citation Envoyé par Madmac Voir le message
Rust est un progrès par rapport à C. Mais si peu. Puisque les jeunes programmeurs sont forcés d'apprendre la programmation fonctionnelle. Les outils pour faire de la programmation fonctionnelle devraient présent dans tous les nouveaux langages. Et la possibilité d'assigner une fonction à une variable avec autant de simplicité qu'un entier n'est pas un luxe. Tout ce que cela demande est que le langage est un type "proc". Être capable de passer des fonctions en arguments est vraiment très commode une fois que l'on est familiarisé avec cette pratique. Si possible de le faire avec des objets, mais Rust ne possède pas d'objet. Et tous les matheux vous diront que pouvoir retourner une fonction avec une fonction n'est pas un luxe. En Conclusion, avec ces limitations, Rust est un langage purement procédural, pas vraiment supérieur au Pascal créé dans les années 80.
Rust possède évidemment les fermetures :
https://doc.rust-lang.org/stable/rus.../closures.html
https://doc.rust-lang.org/stable/boo...-closures.html
https://doc.rust-lang.org/stable/ref...sure-expr.html
1  0 
Avatar de Pyramidev
Expert confirmé https://www.developpez.com
Le 12/10/2022 à 19:29
Citation Envoyé par Madmac Voir le message
Citation Envoyé par smarties Voir le message
Ca ne se fera pas du jour au lendemain. Pour que ça soit significatif, je me dis que dans 15-20 ans ça deviendrait vraiment visible car les nouveaux projets seraient majoritairement menés en RUST.
À moins, qu'une meilleur solution apparaisse dans l'intervalle. Avant je me préoccupait de toutes les nouveautés. Maintenant j’attends au mois 5 ans, pour être sûr que l'investissement en temps sera financièrement rentable.
D'ailleurs, je me suis demandé quelles pourraient être les caractéristiques d'un nouveau langage capable de rivaliser avec Rust sur le marché, en tenant compte de la manière à laquelle les entreprises accueillent les nouveaux langages.

Actuellement, la grande force de Rust, c'est de combiner les performances comparables au C et au C++ et la sécurité de la mémoire et des threads. Il acquiert un monopole sur cette combinaison. Partout où il y a besoin de performances élevées, Rust gagnera du terrain petit à petit, au fur et à mesure qu'il se développera.

Son gros point faible dans la logique des entreprises, c'est sa courbe d'apprentissage. Le nombre de postes en Rust n'augmente que quand des développeurs qui n'ont pas encore d'expérience en Rust en entreprise commencent à faire du Rust en entreprise. Mais les entreprises ne veulent pas que leurs employés passent beaucoup de temps à apprendre pendant les heures de travail et ne veulent généralement pas recruter des développeurs qui n'ont pas encore d'expérience en entreprise dans le langage concerné.

En fait, en règle générale, les entreprises privilégient les technologies qui permettent de pondre rapidement un POC qui a l'air de marcher. À côté de ça, le fait que le produit continuera de bien marcher plus tard quand la complexité continuera de croître, c'est un critère assez secondaire. C'est triste, mais c'est ainsi.

Dans ce contexte, à mon avis, le seul type de langage qui pourrait vaincre Rust, ce serait un langage qui :
- d'une part, combine aussi les performances comparables au C et au C++ et la sécurité de la mémoire et des threads et
- d'autre part, contient un sous-ensemble noob friendly, de la même manière que Python contient un sous-ensemble accessible aux lycéens.

S'il n'a pas ce sous-ensemble noob friendly, alors n'arrivera vraisemblablement pas à décoller, car l'écosystème de Rust aura déjà beaucoup trop d'avance.

Pour que ce sous-ensemble noob friendly puisse exister, l'un des prérequis sera que le langage permette d'avoir des parties du code avec ramasse-miette. Rust, avant la version 1.0, permettait d'avoir un ramasse-miette sur une zone de code, si j'ai bien compris, mais cette fonctionnalité a été retirée. Dans un PDF de 2012 de Graydon Hoare, la page 11 parle de "managed pointer".

Mais mettre en place un concurrent crédible à Rust sera difficile et demandera beaucoup de moyens. Du coup, je vais quand même miser sur Rust.
1  0 
Avatar de Mingolito
Membre extrêmement actif https://www.developpez.com
Le 10/10/2022 à 16:10
Ca commence à être utilisé aux USA, par contre en France c'est pas encore le cas, mais c'est normal la France est un pays agricole arriéré, on utilise encore Cobol, dBase 3, et même le Basic, et c'est pas pour rien que le week end les Français se rendent dans des fêtes médiévale pour voir des sorcières se faire bruler, danser la bourrée, et manger des andouillettes, en buvant de la piquette.

En France Rust c'est planifié pour 2040

5  5