Discussion :

[Patrick Ruiz]

Le langage Rust est la meilleure chance offerte à l’industrie informatique pour la mise sur pied d’applications système sécurisées
D’après Microsoft

Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. De façon graduelle, Microsoft migre vers ce dernier au détriment de la paire C/C++ que l’entreprise ne juge plus acceptable pour la mise sur pied d’applications dites système. Motif : Rust offre de meilleures garanties en matière de sécurisation des logiciels que le couple C/C++.

C’est un avis formulé il y a peu par Ryan Levick, développeur qui travaille sur l’infrastructure cloud du géant technologique (Microsoft), lors de la conférence virtuelle AllThingsOpen.

Le noyau Linux par exemple est le produit de développements en langages C et assembleur. Dans la filière de la mise au point de drivers pour le système d’exploitation open source, c’est encore ce tandem qui règne en maître. Les développeurs engagés sur cet axe le plébiscitent pour les énormes possibilités qu’il offre en matière de manipulation des ressources matérielles d’un système informatique. Dans le jargon du milieu, on parle de « proximité avec le hardware. »

Seulement, de plus en plus de voix s’élèvent pour appeler au passage au langage Rust – l’un de ceux pressentis comme remplaçant du C sur le terrain du contrôle du matériel. Il y a seulement que les rapports de chercheurs en sécurité s’enchaînent et ne cessent de mettre le doigt sur l’une des plus grosses tares que les langages C et C++ traînent : les problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoire invalides ou libérées, etc. Les chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE) abondent dans le même sens : 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des dépassements de mémoire tampon.

Ryan Levick revient sur ces détails dans le cadre de sa présentation et coupe court : « Quels que soient les investissements que les entreprises de la filière du développement de logiciels peuvent mettre sur pied, le fait est que C++ [C] n’est pas par essence un langage fait pour la mise sur pied d’applications sécurisées. » L’an dernier, Alex Gaynor – un ex contributeur de l’équipe sécurité du navigateur Firefox – émettait un avis similaire : « Le C++ moderne ne nous sauvera pas, car il est moins sécurisé que les nouveaux langages [Rust, Swift]). »

L’une des approches envisageables est de multiplier les formations des programmeurs à l’écriture d’applications sécurisées en langage C/C++. Une autre est de faire recours à l’analyse statique. Enfin, la piste des vérifications lors de l’exécution reste valable. Mais l’ingénieur de Microsoft est d’avis qu’aucune de ces solutions n’apporte une solution entière à l’absence d’orientation du langage C++ vers la sécurité dans sa conception. C’est pour cet ensemble de raisons que ce dernier estime que le langage Rust est la meilleure chance offerte à l’industrie informatique pour la mise sur pied d’applications sécurisées.

Les initiatives allant dans le sens de faire un usage plus extensif du langage se multiplient donc chez la firme de Redmond. L’une des plus récentes et remarquées est Rust/WinRT – une projection du langage Rust pour les API Windows Runtime. De façon ramassée, l’annonce signifie que les développeurs peuvent créer des composants pour Windows en utilisant Rust. En parallèle, Microsoft pilote l’effort « Safe Systems Programming Languages » au travers duquel l’entreprise apporte plus d’éclaircissements sur son intérêt pour des langages de programmation comme Rust.

Sur cinq années consécutives, Rsut a obtenu la reconnaissance de « plus aimé » des développeurs habitués de la plateforme de questions-réponses sur des sujets liés à l’informatique – StackOverflow. Toutefois, ce dernier reste très utilisé dans le cadre de projets personnels. Les entreprises ne s’en servent pas. En toile de fond, on a un lot de raisons techniques susceptibles de justifier le positionnement des entreprises qui ne s’appuient pas sur Rust pour leurs projets : manque de bibliothèques, absence de prise en charge de plus d’ environnements de développement intégré, manque de documentation, etc. En effet, le manque de bibliothèques est l’une des raisons que certains développeurs soulignent comme un frein à la productivité.

Après, Rust a désormais l’un des plus grands de l’histoire de l’informatique pour le pousser. Ce sont des ressources supplémentaires qui peuvent être allouées à l'amélioration et au développement du langage lui-même : du temps d'ingénierie, probablement des propositions et pistes d'amélioration. En sus, l’appui de Microsoft apparaît comme une étiquette qualité pour le langage de programmation. Cela devrait permettre de rehausser son niveau d’adoption en entreprise.

Et vous ?

Êtes-vous en accord avec les griefs portés à l'endroit de C/C++ en matière de sécurité ? Le problème n'est-il pas plutôt celui de la qualité des développeurs ?
Voyez-vous aussi la présence de Microsoft derrière ce langage comme une force ?
Votre entreprise a-t-elle adopté le langage Rust ? Si oui, sur des projets de quelle taille ?
Quels sont les ingrédients susceptibles de conduire à une adoption plus importante de Rust, mais qui lui font encore défaut de votre point de vue ?

Voir aussi :

L'équipe Microsoft Security Response Center recommande l'utilisation de Rust comme approche proactive pour un code plus sécurisé
Quel langage pourrait remplacer C ? Après avoir comparé Go, Rust et D, le choix d'Andrei Alexandrescu se porte sur D
C2Rust : un outil qui permet de faire la traduction et la refactorisation de votre code écrit en langage C vers le langage Rust

[Jimskapt]

J'ai appris les fondamentaux de Rust en profondeur en participant beaucoup à la traduction du livre de référence "The Rust Programming Language".
Pour ceux que cela intéresse, la traduction est librement consultable à cette adresse : https://jimskapt.github.io/rust-book-fr/ (ou https://github.com/Jimskapt/rust-book-fr)

J'ai appris et manipulé pas mal de langages ces deux dernières décennies et maintenant que j'ai "gravi" le plus gros de la courbe d'apprentissage de Rust ces deux dernières années, je m'amuse beaucoup avec et j'en suis toujours autant amoureux !
Je suis très satisfait que mon code soit aussi stable à long terme, tout en restant flexible et productif !
Je pense aussi que ce langage a toutes ses chances d'être un des plus stables et sécurisés, à condition que les développeurs qui l'utilisent ou le développent jouent bien le jeu.
Par exemple, il faut utiliser avec modération `unwrap` sur un produit fini, et éviter l'usage non justifié et/ou non maîtrisé de `unsafe`.

Voyez-vous aussi la présence de Microsoft derrière ce langage comme une force ?

Je suis ravi de voir que le *nouveau Microsoft* se rapproche de Rust depuis quelques mois !
Par contre, leur "projet Verona" va me faire mal au cœur s'il atteint maturité.
Autant regrouper les forces et faire évoluer les mentalités pour adopter Rust plutôt que d'en forker une partie !

Quels sont les ingrédients susceptibles de conduire à une adoption plus importante de Rust, mais qui lui font encore défaut de votre point de vue ?

Pour moi, le langage sera adopté en entreprise lorsque la communauté aura mis à disposition des `crates` (l'équivalent de bibliothèques, comme npm, pour faire simple) puissantes et mâtures qui faciliterons l'intégration du langage (SMTP, LDAP, HTTP, GUI, ORM/BDD, ...).

[tutosfaciles48]

Il y a quand même certaines choses qui me choques et qui sont les suivantes:

la "stabilité" de rust de ces 5 dernières année provient notamment d'une phase de "maturation" dans laquelle le langage utilise le "semver": quand on le compare au c++ par exemple, on parle d'un langage qui vas bientôt avoir 40 ans, comment peux ton être sur que le rust ne vas pas dériver comme le python ou le c# ?

Un autre problème pointé semble être le manque de bibliothèques tierces comme souligné dans un autre message, et aussi la mode d'utiliser les nouveaux langages pour refaire la roue à chaques fois ...

Alors oui, rust semble permettre une souplesse au niveau des pointeurs, mais si c'était un si grand dérangement, d'autres gens auraient créer un autre langage il y a bien des années.

[imperio]

@Jimskapt: Wo, t'es payé par Rust pour dire tout ça ? XD

la "stabilité" de rust de ces 5 dernières année provient notamment d'une phase de "maturation" dans laquelle le langage utilise le "semver": quand on le compare au c++ par exemple, on parle d'un langage qui vas bientôt avoir 40 ans, comment peux ton être sur que le rust ne vas pas dériver comme le python ou le c# ?

Je dois avouer ne pas comprendre ce que tu veux dire par là...

Un autre problème pointé semble être le manque de bibliothèques tierces comme souligné dans un autre message, et aussi la mode d'utiliser les nouveaux langages pour refaire la roue à chaques fois ...

Ça c'est un problème récurrent à chaque nouveau langage. C'est pas pour autant que personne n'en écrit de nouveau.

Alors oui, rust semble permettre une souplesse au niveau des pointeurs, mais si c'était un si grand dérangement, d'autres gens auraient créer un autre langage il y a bien des années.

Je crois que t'as raté quelques CVE toi. Sans parler du fait que j'ai l'impression que t'as jamais touché à Rust pour parler de "souplesse au niveau des pointeurs"...

[Invité]

la "stabilité" de rust de ces 5 dernières année provient notamment d'une phase de "maturation" dans laquelle le langage utilise le "semver": quand on le compare au c++ par exemple, on parle d'un langage qui vas bientôt avoir 40 ans, comment peux ton être sur que le rust ne vas pas dériver comme le python ou le c# ?

Oui, rust est à peu près utilisable depuis à peine 5 ans. Donc on n'a pas vraiment de retour d'expérience "sur le long terme" de projet en rust. Hormis peut-être servo, mais c'est un peu particulier...

Alors oui, rust semble permettre une souplesse au niveau des pointeurs,

C'est plutôt l'inverse : rust force à gérer la mémoire correctement.

mais si c'était un si grand dérangement, d'autres gens auraient créer un autre langage il y a bien des années.

Ben c'est le cas en fait. Beaucoup de langages ont évolué ou ont été créé dans ce sens : le langage D par exemple.

j'ai "gravi" le plus gros de la courbe d'apprentissage de Rust ces deux dernières années, je m'amuse beaucoup avec et j'en suis toujours autant amoureux !

A mon avis, c'est le principal inconvénient de rust par rapport à C : il est (beaucoup) plus difficile à apprendre.

[archqt]

A mon avis, c'est le principal inconvénient de rust par rapport à C : il est (beaucoup) plus difficile à apprendre.

J'en suis qu'au début sur Rust, mais cela ne semble pas si difficile que cela. L'avantage que je vois est la notion d'emprunt, de possession et les références qui sont verrouillées, cela permet effectivement d'éviter le problèmes des pointeurs "fous".
Après en utilisant correctement des "smart-pointers" en C++ on a un truc similaire je trouve, si on ne passe jamais par de simples pointeurs. Il faut juste se fixer des règles pour les références et le déplacement des données pour avoir un truc similaire. Mais la force de Rust est que les mauvaises pratiques sont bloquées dans le language.

Dommage que la syntaxe change, un C++ avec ses blocages auraient été mieux. Pourquoi changer la syntaxe au lieu de faire un "fork" du C++,ce qui aurait en plus permis de bénéficier de toutes les bibliothèques existantes.

[frfancha]

J'ai appris les fondamentaux de Rust en profondeur en participant beaucoup à la traduction du livre de référence "The Rust Programming Language".
Pour ceux que cela intéresse, la traduction est librement consultable à cette adresse : https://jimskapt.github.io/rust-book-fr/ (ou https://github.com/Jimskapt/rust-book-fr)

Merci Jim.
Je n'avais pas encore pris le temps d'étudier Rust bien que cela me semble faire partie des pré-requis de connaissance générale en informatique dans le futur.
J'ai lu le chapitre 2 suite à ton message, et le style du livre est extrêmement clair.
Si le reste est comme cela apprendre Rust est "facile".

[Uther]

comment peux ton être sur que le rust ne vas pas dériver comme le python ou le c# ?

On n'est jamais sur de rien, il est en effet fort probable que dans 40 ans le Rust idiomatique sera différent du Rust actuel, il y déjà des différences avec le Rust d'il y a 5 ans. Mais si la compatibilité reste aussi bien gérée qu'actuellement, ça ne m'inquiète pas plus que ça.
Un point notable par rapport à C# ou Python, est que Rust a volontairement choisi une bibliothèque standard réduite pour limiter le risque d’accumuler de la dette technique. Ça reporte le problème sur les bibliothèques tierces, mais le langage lui même a moins de chance d’accumuler trop de fonctionnalités dépassées.

Un autre problème pointé semble être le manque de bibliothèques tierces comme souligné dans un autre message

Je trouve quand même qu'il s'en tire plutôt bien pour un langage si jeune. Le seul truc qui me manque vraimment c'est une bibliothèque de GUI cross-plateforme du niveau de Qt ou wxWidget.

aussi la mode d'utiliser les nouveaux langages pour refaire la roue à chaques fois ...

Il n'est pas question de refaire la roue. Personne ne demande de réécrire l’existant en Rust a moins d'avoir un intérêt particulier à le faire. Par contre pour un nouveau projet c'est un choix qui peut être pertinent.

Alors oui, rust semble permettre une souplesse au niveau des pointeurs, mais si c'était un si grand dérangement, d'autres gens auraient créer un autre langage il y a bien des années.

C'est justement tout l'inverse. Ce qui fait la particularité de Rust par rapport aux autres langages, c'est qu'il est absolument psychorigide sur les pointeurs. Il refusera de compiler si tu ne peux lui garantir que tu en fait bon usage.

Et il existe plein de langage qui sont nés du besoin de simplifier C++, particulièrement sur le problème de la gestion mémoire. On peut citer Java, D, Go, ... Ce qui fait l'originalité de Rust c'est que contrairement à la plupart des langages modernes, il a choisi de ne pas recourir à un GC. Il gère la mémoire à la manière de C++, sauf qu'il te force a lui prouver que tu l'utilise correctement.

Dommage que la syntaxe change, un C++ avec ses blocages auraient été mieux. Pourquoi changer la syntaxe au lieu de faire un "fork" du C++,ce qui aurait en plus permis de bénéficier de toutes les bibliothèques existantes.

La syntaxe de surface n'est pas vraiment un soucis pour la compatibilité avec les bibliothèques C++. C'est assez facile de faire correspondre des fonctionnalité identiques entre elles.
Ce qui pose souci, c'est les concepts qui ne sont pas partagés par les langages. Il y a des fonctionnalités intrinsèques au langage Rust, qui n'ont pas d’équivalent direct en C++, comme les lifetimes des références. Et inversement Rust n'a pas le système de hiérarchie des classes de C++. Même des fonctionnalités qui paraissent similaire comme les génériques/templates reposent parfois sur des mécaniques différentes.

Certaines différences du Rust sont volontaires pour éviter la complexité du C++. Cela permet notamment d'avoir des message d'erreur globalement plus clairs. Personnellement, passé le temps d'adaptation, je trouve le Rust plus lisible que le C++.

[Invité]

J'en suis qu'au début sur Rust, mais cela ne semble pas si difficile que cela.

C'est pour ça que j'ai dit "plus difficile à apprendre par rapport à C".
Avec les lifetime, traits, macro, etc, on ne peut quand même pas dire que rust est un langage simple.

On n'est jamais sur de rien, il est en effet fort probable que dans 40 ans le Rust idiomatique sera différent du Rust actuel, il y déjà des différences avec le Rust d'il y a 5 ans. Mais si la compatibilité reste aussi bien gérée qu'actuellement, ça ne m'inquiète pas plus que ça.
Un point notable par rapport à C# ou Python, est que Rust a volontairement choisi une bibliothèque standard réduite pour limiter le risque d’accumuler de la dette technique. Ça reporte le problème sur les bibliothèques tierces, mais le langage lui même a moins de chance d’accumuler trop de fonctionnalités dépassées.

Comme le C++ en fait : bibliothèque standard réduite, compatibilité avec les anciennes versions du langage...
De toute façon, il n'y a pas de miracle pour faire évoluer un langage : soit on assure la compatiblité et ça devient plus complexe, soit on essaie de remettre tout au propre et on a une phase de migration. Maintenant, Rust est plus récent donc il a pu éviter des problèmes que des langages plus anciens ont eu.

Il n'est pas question de refaire la roue. Personne ne demande de réécrire l’existant en Rust a moins d'avoir un intérêt particulier à le faire. Par contre pour un nouveau projet c'est un choix qui peut être pertinent.

Bah en fait si. C'est un troll classique à propos de rust, et ça a même un nom : RIIR
https://www.reddit.com/r/rust/commen...te_it_in_rust/

[Uther]

Bah en fait si. C'est un troll classique à propos de rust, et ça a même un nom : RIIR
https://www.reddit.com/r/rust/commen...te_it_in_rust/

Justement comme tu le dis ce n'est qu'un meme récurrent né de quelques débutants un peu trop enthousiastes à l'époque de la sortie du langage. Les gens qui font du Rust sont les premiers à s'en moquer.

Personne de sérieux ne propose de réécrire en Rust sans une bonne justification du contexte (problème de sécurité mémoire important, nécessité de réécrire de toute façon, ...)

[Jitou]

En 1995 Java c'est génial il va balayer tous les autres langages ...
En 1999 Python c'est génial il va balayer tous les autres langages ...
En 2005 .Net c'est génial il va balayer tous les autres langages ...

j'abrège là ...

En 2010 Go c'est génial il va balayer tous les autres langages ...
En 2015 Rust c'est génial il va balayer tous les autres langages ...

What's next ?

Recoder le noyau Linux prendra des années et les petits jeunes qui s'y pencheront devront malgré tout maitriser parfaitement le C et l'assembleur pour faire ce travail donc Rust ou un autre langage qui arrivera l'année prochaine ne remplacera pas de sitôt le C pour maintenir le noyau Linux. Quant à la pérennité des langages il suffit de se pencher sur ceux qui ont réussi à passer plus de 2 décennies ...

[Uther]

Ça tombe bien personne de sérieux ne prétend que Rust va remplacer C partout du jour au lendemain. Il faut sortir du mythe du langage qui prétend remplacer tous les autres, tout comme Java et Python ont trouvés leur place sans forcément faire disparaitre les autres langages.

Rust est particulièrement intéressant dans certaines situations. Pour nouveaux projets, ou pour des portions de projets qui ont de toute façon besoin d'un réécriture, la question d'employer Rust peut tout à fait se poser. Mais évidement le choix d'un nouveau langage n'est pas une situation anodine et c'est une décision qui doit être pesée.