Rust se lance à la conquête des développeurs C/C++
Mozilla publie la première version stable de son langage de programmation multiparadigme

0PARTAGES

5  0 
Près de cinq ans après la première présentation publique de son langage de programmation Rust, la fondation Mozilla lance la version stable qui peut désormais être utilisée en environnement de production.

Rust est développé par la fondation Mozilla. C’est un langage de programmation compilé, multiparadigme (orienté objet, fonctionnel et procédural) qui tire parti des langages fonctionnels comme Haskell et ML, du langage orienté objet C++ et bien plus.

Le but de Mozilla est de mettre à la disposition des développeurs « un langage orienté objet statique, typé, sûr, concurrentiel et efficace ». Selon la fondation Mozilla, il s’agit d’un nouveau langage de programmation visant à rendre plus facile le développement des systèmes fiables et efficaces.

Sur le site du projet, on peut lire en guise d’introduction que « Rust est un langage de programmation système qui fonctionne incroyablement rapidement, empêche presque toutes les erreurs de segmentation, et garantit la sécurité des threads. »

Ce qui rend Rust différent des autres langages de programmation est son système de type, selon Mozilla. Le langage fournit la sécurité et la commodité des langages modernes, tout en maintenant l’efficacité et le contrôle de bas niveau des langages C et C++.

À partir de cette version, il n’y aura plus de changement pouvant briser la rétrocompatibilité.

Parallèlement à cette version, Mozilla a publié la version stable de Cargo, le gestionnaire de packages pour le langage de programmation. Cargo est écrit en Rust et simplifiera la création et la distribution des bibliothèques Rust par les développeurs.

Mozilla a lancé le premier référentiel pour les bibliothèques Rust. crates.io est la plateforme officielle pour rechercher et installer les paquets Rust. Les développeurs peuvent également y publier leurs bibliothèques.

Le langage continuera à évoluer suivant un modèle de développement open source, autour des processus de RFC. Une RFC (request for comments) est une liste de discussions sur de nouvelles fonctionnalités du langage de programmation.

Les développeurs du langage ont adopté un nouveau cycle de développement inspiré du système de canaux utilisé pour Firefox et Chrome. Ainsi, les évolutions de la plateforme pourront être suivies au travers des canaux Nightly, Beta et Stable, qui seront mis à jour toutes les six semaines.

De ce fait, parallèlement, Mozilla a publié la version beta de Rust 1.1.

Télécharger la version stable de Rust 1.0

Source : Mozilla

Et vous ?

Que pensez-vous du langage de programmation Rust ?

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

Avatar de pierreact
Membre du Club https://www.developpez.com
Le 19/05/2015 à 10:48
Je ne vois pas ce que rust ou go peuvent apporter de plus.
Avatar de mangobango
Membre actif https://www.developpez.com
Le 19/05/2015 à 11:13
C'est vrai que les dernières évolutions de C++ apportent pas mal de réponses aux menus soucis de partage de ressources et de gestion de la mémoire. Mais ça reste au programmeur de bien vouloir utiliser le bon type de "XXXX_ptr" au bon endroit. Disons que C++ est permissif par défaut. Rust, de ce que j'en lis, est plutôt restrictif par défaut.

Je creuserais bien la question si j'avais un peu de temps.

Daniel
Avatar de FlyersWeb
Membre à l'essai https://www.developpez.com
Le 19/05/2015 à 12:01
Il est vrai que C++ aborde déjà les problèmes que souhaitent résoudre Go et Rust mais la différence majeur étant que C++ n'a pas été pensé dans cette optique au départ, c'est pourquoi il est plus facile de faire de la programmation concurrente (structure de données, gestion mémoire et synchronisation) avec ces langages.

Certes il est possible de faire de la programmation concurrente, fonctionnelle, etc... dans à peu près n'importe quel langage mais ces options ont été pensé dans cette optique contrairement à d'autres (PHP pour le web, Python pour l'analyse scientifique, Perl pour la gestion de chaînes, etc...)

La vrai force de Rust, à mon avis, est son système de typage qui lui permet de prévenir un grand nombre de problème de gestion mémoire/accès concurrent qui sont donc corrigés lors de la compilation plutôt qu'après du debug (debuggé une application avec accès concurrents à la mémoire est particulièrement horrible, de nombreux crackme se basent sur cette technique).

L'inconvénient, je pense, sera une courbe d'apprentissage un peu plus longue que d'autres langages puisqu'il faut bien comprendre ses erreurs pour pouvoir les corriger avec une analyse statique. On peut faire l'analogie avec le reversing, l'analyse statique est bien plus complexe qu'une analyse en debug puisque que l'on n'a pas l'état de la machine à l'instant t.

Bref Rust m'apparaît comme un langage avec un fort potentiel pour de la programmation concurrentielle grâce à son typage de données très fort.
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 19/05/2015 à 12:14
Citation Envoyé par pierreact Voir le message
Je ne vois pas ce que rust ou go peuvent apporter de plus.
Ils ont tous les deux clairement leur intérêt mais n'apportent clairement pas la même chose :

Go se veut une version très épurée de C++ : il vise la simplicité au prix de l'absence de certaine fonctionnalités (Les générique tout particulièrement) et de la présence d'autre qui le rendent moins proche du système (Garbage Collector).

Rust lui reste avec une vision proche de la machine : contrairement à Go il ne fait pas de compromis sur la maitrise des performances. Il est clairement prévu pour être utilisable pour des applications de très bas niveau comme un kernel, des drivers ou de l'embarqué temps réel.
Il permet lui aussi d'éviter certains points complexes du C++ mais n'est pas aussi radical : il a notamment des génériques et un système de macros(bien plus propre que celui de C++ quand même).
Il est par contre plus complexe sur un point particulier il surveille à la compilation la durée de chaque variable ce qui fait qu'une utilisation des pointeur qu'il ne peut garantir sure refusera de compiler. Pour éviter cela il faut bien assimiler les notions de propriété et de durée de vie d'un pointeur qui permettent de garantir que le code est sur.
Cela permet d'avoir une garantie absolue qu'il n'y aura aucune erreur de sécurité mémoire.
Avatar de DonQuiche
Expert confirmé https://www.developpez.com
Le 19/05/2015 à 13:55
Citation Envoyé par pierreact Voir le message
Je ne vois pas ce que rust ou go peuvent apporter de plus.
Si ton programme Rust compile (en deux secondes et non pas en deux minutes contrairement au C++), alors tu es sûr que ton modèle de concurrence et ta gestion de la mémoire sont correctes (*). Y compris si certains de tes stagiaires ou programmeurs juniors ont mis leurs mains dedans ! A l'heure où les gains de performances se font sur le parallélisme de masse, c'est un très gros avantage.

Ce ne sera jamais le cas avec le C++ et ses pointeurs qui prolifèrent, au mieux tu peux t'arranger pour utiliser aussi souvent que possible des constructions sûres que peu savent correctement utiliser et dont tu sortiras pourtant régulièrement et dont tu ne pourras pas détecter et inspecter les violations (je te laisse chercher et passer en revue tous les pointeurs de ton code et examiner à la main tous les graphes d'appels conduisant à des appels asynchrones).

Clamer que le C++ 11 résout les problèmes de concurrence et de productivité, et qu'il n'y a rien à attendre des nouveaux langages, c'est comme clamer que le minitel rend Internet inutile. Quand le C++ est-il devenu une religion ?!

Citation Envoyé par FlyersWeb Voir le message
L'inconvénient, je pense, sera une courbe d'apprentissage un peu plus longue que d'autres langages puisqu'il faut bien comprendre ses erreurs pour pouvoir les corriger avec une analyse statique.
En même temps si un dév comprend comment gérer la mémoire manuellement en C++, il comprend tout de suite ce que Rust attend de lui. Et s'il ne le comprenait pas, mieux vaut que Rust le lui enseigne plutôt que de le laisser semer le champ de mines en C++.
Avatar de white_tentacle
Membre émérite https://www.developpez.com
Le 19/05/2015 à 16:28
Citation Envoyé par DonQuiche Voir le message
Si ton programme Rust compile (en deux secondes et non pas en deux minutes contrairement au C++), alors tu es sûr que ton modèle de concurrence et ta gestion de la mémoire sont correctes (*).
Je suis surpris pour le modèle de concurrence. Tu as des sources là-dessus ? Il ne me semble pas que Rust te garantisse que tu ne puisse pas deadlocker…
Avatar de DonQuiche
Expert confirmé https://www.developpez.com
Le 19/05/2015 à 16:50
Citation Envoyé par white_tentacle Voir le message
Je suis surpris pour le modèle de concurrence. Tu as des sources là-dessus ? Il ne me semble pas que Rust te garantisse que tu ne puisse pas deadlocker…
Le modèle à mémoire partagée est invérifiable en général (pas toujours).

C'est pourquoi Rust ou Go promeuvent un modèle par isolation : toutes les données sont soit uniques à un thread, soit partagées mais immuables. Concrètement deux threads ne peuvent échanger de données que par un canal (channel - une file d'attente). Or tu ne peux passer de données à un canal que si tu en es l'unique propriétaire (en c++ tu ne pourrais passer qu'un unique_ptr) ou si cette donné est immuable. Il est IMPOSSIBLE de violer accidentellement cette règle - le compilateur générerait une erreur. Et c'est complètement intégré avec le système de types de Rust.

Malheureusement le modèle à mémoire partagée reste parfois nécessaire. Rust l'autorise via des verrous : tu dois empaqueter tes données dans un type garde-fou "access" avant de les partager et il est alors impossible d'accéder à ces données sans d'abord passer au garde-fou une preuve que tu as obtenu un verrou (mutex). Si jamais tu tentes d'y accéder après avoir relâché le verrou, une erreur sera levée. Un deadlock reste possible (encore qu'ils le vérifient sans doute à l'exécution) mais une data race est impossible.

Évidemment le modèle à mémoire partagée à un coût en performances. C'est un compromis. En revanche si ton problème se prête au modèle par isolation (qui est LE modèle de concurrence à privilégier dans tous les langages), Rust t'offre des garanties en béton armé.

Fearless concurrency with Rust.
Avatar de white_tentacle
Membre émérite https://www.developpez.com
Le 19/05/2015 à 17:19
Citation Envoyé par DonQuiche Voir le message
C'est pourquoi Rust ou Go promeuvent un modèle par isolation : toutes les données sont soit uniques à un thread, soit partagées mais immuables. Concrètement deux threads ne peuvent échanger de données que par un canal (channel - une file d'attente). Or tu ne peux passer de données à un canal que si tu en es l'unique propriétaire (en c++ tu ne pourrais passer qu'un unique_ptr) ou si cette donné est immuable. Il est IMPOSSIBLE de violer accidentellement cette règle - le compilateur générerait une erreur. Et c'est complètement intégré avec le système de types de Rust.
Je comprends mais je ne vois pas en quoi ça te protège d’un blocage, disons, par famine par exemple (en fait, soit j’ai loupé un truc, soit je peux te prouver que ce n’est pas le cas). J’ai l’impression qu’on survend un peu la chose. Après, la bonne nouvelle est qu’on pourrait faire quand même plein de vérifications là-dessus (pex: model-checking), mais à ma connaissance rien de tout ça n’est fait en Rust...
Avatar de DonQuiche
Expert confirmé https://www.developpez.com
Le 19/05/2015 à 17:25
Citation Envoyé par white_tentacle Voir le message
Je comprends mais je ne vois pas en quoi ça te protège d’un blocage, disons, par famine par exemple
Un cas de famine se produit lorsqu'un thread est incapable d'accéder à une ressource partagée. Or il n'y a aucune ressource partagée dans le modèle par isolation, ou seulement des ressources immuables toujours accessibles sans demande d'accès.
Avatar de white_tentacle
Membre émérite https://www.developpez.com
Le 19/05/2015 à 17:56
Un cas de famine se produit lorsqu'un thread est incapable d'accéder à une ressource partagée. Or il n'y a aucune ressource partagée dans le modèle par isolation, ou seulement des ressources immuables toujours accessibles sans demande d'accès.
Sauf que si une ressource peut changer de thread, ça casse tout le modèle. Une ressource qui peut changer de thread, c’est par essence pas loin d’une ressource partagée. De plus, il est tout à fait possible, via une erreur de programmation, que toutes tes tâches se retrouvent à attendre un message qui n’arrivera jamais. Je ne vois pas quelle garanties t’offre rust là-dessus (à part que le modèle par isolation est effectivement plus simple à vérifier, mais ça se fera à l’aide d’autres outils de ce que j’en ai vu).
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web