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 se lance à la conquête des développeurs C/C++
Mozilla publie la première version stable de son langage de programmation multiparadigme

Le , par Hinault Romaric

198PARTAGES

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-nous-la !

Avatar de DonQuiche
Expert confirmé https://www.developpez.com
Le 25/05/2015 à 7:48
Citation Envoyé par Ph. Marechal Voir le message
La sécurité : je m'en charge
Tu peux me donner le nom de tes produits, afin que je les évite stp ?

La sécurité devrait être une affaire d'outils et de méthodologie, pas d'égo. L'être humain est faillible.

Quels langages modernes ? On croit rêver en lisant ça - c'est tout juste si les programmeurs C/C++ ne sont pas traités de vieux croutons - tout en leur reconnaissant quand même l'efficacité et le contrôle de bas niveau !
Le C++ va sur ses cinquante ans, ses chaînes littérales sont encodées en ASCII, il supporte des digraphes dangereux pour les jeux de caractères obsolètes qui ne contenaient pas certains symboles, son modèle de compilation est problématique et atrocement long car le modèle est prévu pour des ordinateurs avec trop peu de mémoire pour faire tenir une représentation sémantique du code en mémoire et il a encore recours à des mécanismes dont toute l'industrie a appris à se méfier durant le dernier demi-siècle (types "standards" spécifiques à chaque plateforme par exemple).

Oui, je pense qu'on peut dire que le C++ est un vieux schnoque. Mais encore nécessaire pour l'instant.

Ce qui n'est pas forcément le cas de ses utilisateurs, le C++ étant encore enseigné dans de nombreux endroits. Pourquoi en faire une affaire personnelle ?
6  1 
Avatar de _skip
Expert éminent https://www.developpez.com
Le 25/05/2015 à 9:52
Je ne comprends jamais les réactions négatives dès qu'on parle d'un nouveau langage, surtout quand celui-ci s'attaque à de vrais problèmes. C'est bizarrement très récurrent sur DVP, que ce soit sur des alternatives au javascript (typescript, dart), aux langages pour la jvm (ceylon, kotlin, fantom) ou au C++ et consors (Rust ou Go).

Généralement quand un langage propose plus de sécurité on a droit à un "C'est au développeur de savoir ce qu'il fait". Il serait peut être temps de stopper une fois pour toute avec cet argument de merde parce qu'aucun mécanisme n'est là pour dispenser le développeur de savoir ce qu'il fait, ce sont des aides, des outils. On peut tout ramener à soi et estimer qu'on a pas besoin de ces facilités faites pour les tocards, mais dans la pratique on se retrouve immanquablement dans des équipes composées de différentes personnes de niveaux parfois inégaux et là, il y pas de raison de ne pas être preneur de toutes les vérifications et sécurités qu'on peut nous proposer, surtout quand elles sont gratuites et automatiques.
5  0 
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++.
4  0 
Avatar de white_tentacle
Membre émérite https://www.developpez.com
Le 20/05/2015 à 10:53
Citation Envoyé par DonQuiche Voir le message
C'est énorme ! Et si tes critiques ne sont pas infondées je pense que tu devrais pourtant te demander si cette insistance à saper le bénéfice évident et conséquent que j'ai décrit sur un problème très important et très difficile ne relève pas d'autre chose qu'une simple exploration intellectuelle. J'ai malheureusement constaté que les programmeurs sont extrêmement conservateurs et défendent farouchement leurs langages - bien au-delà du raisonnable.
Oula, désolé si tu as mal pris mon propos. C’est probablement lié à mon historique personnel (j’ai fait du model-checking sur systèmes asynchrones, quand on me parle de systèmes concurrents « sûrs », ma réaction primaire est « j’ai des doutes, de manière générale on ne peut rien garantir sans faire une grosse exploration bourrine de tous les états »). Et je suis assez enthousiaste vis à vis de Rust en fait. Je pense simplement qu’il ne faut pas promettre plus que ce qui est effectivement tenable (en particulier, ton premier message semblait laisser penser que le modèle de concurrence de Rust empêchait tout blocage, d’où mon étonnement).

Si ça peut te rassurer sur le bien que je pense de Rust, il se trouve que quelque soit le langage (en général c’est C++), chaque fois que je dois faire du multithread, je conçois ça comme un ensemble de tâches asynchrones communiquant par envoi de message et transfert de données. Donc typiquement le modèle choisi par Rust .
4  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 25/05/2015 à 11:44
Citation Envoyé par Ph. Marechal Voir le message
Quels langages modernes ? On croit rêver en lisant ça - c'est tout juste si les programmeurs C/C++ ne sont pas traités de vieux croutons - tout en leur reconnaissant quand même l'efficacité et le contrôle de bas niveau !
Même s'ils continuent d'évoluer, C et C++ sont clairement plus ancien, et ont donc un historique qui va avec. Ce n'est pas insulter les utilisateur du langage que de le relever.

Citation Envoyé par Ph. Marechal Voir le message
Pourquoi ne pas faire une bibliothèque, un Framework ou une API en C/C++, pas la peine de créer un dit "nouveau" langage qui serait "moderne".
Une bibliothèque C++ ne résoudra pas tous les problèmes : certains sont inhérents au langage lui même. Rust garantit la sécurité mémoire à la compilation, ce qui est impossible en C++, sans casser sa compatibilité.
Une bibliothèque a souvent un coût à l'exécution et les cas d'erreur sont traités a l’exécution.

Citation Envoyé par Ph. Marechal Voir le message
La sécurité : je m'en charge et la commodité : elle vient toute seule avec l'expérience - donc je vais laisser Rust rouiller dans son coin et surtout ne pas m'embarquer là-dedans
Tu m'expliqueras pourquoi dans toutes les applications les plus contrôlées au monde avec des système de revue, on découvre pourtant régulièrement des failles de sécurités. Et ce n'est pas une insulte à tes talents de programmeur, que de dire que je suis certain que tes programmes ne sont certainement pas si sur que tu le penses.

Citation Envoyé par _skip Voir le message
Je ne comprends jamais les réactions négatives dès qu'on parle d'un nouveau langage, surtout quand celui-ci s'attaque à de vrais problèmes. C'est bizarrement très récurrent sur DVP, que ce soit sur des alternatives au javascript (typescript, dart), aux langages pour la jvm (ceylon, kotlin, fantom) ou au C++ et consors (Rust ou Go).
Je pense que c'est surtout que pas mal de gens ont une approche conservatrice : il voient leur langage fétiche comme un aboutissement et n'imaginent pas qu'il y en ai besoin d'autre.
Il voient un autre langage comme une remise en cause de ce qu'ils ont fait avec leur langage habituel ou craignent à tort qu'il rende le leur obsolète et de se retrouver a devoir réapprendre un nouveau langage et perdre le savoir faire qu'il ont capitalisé.
4  0 
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.
2  0 
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).
2  0 
Avatar de DonQuiche
Expert confirmé https://www.developpez.com
Le 19/05/2015 à 19:35
Citation Envoyé par white_tentacle Voir le message
Sauf que si une ressource peut changer de thread, ça casse tout le modèle.
Je vois ce que tu veux dire : un thread pourrait attendre qu'un autre thread lui envoie une donné via un canal, et celle-ci n'arriverait jamais ?

Effectivement Rust n'empêche pas cela, pas plus qu'il n’empêche les boucles infinies, ou n'empêche pas ton processus de s'arrêter lui-même. Des scénarios équivalents à celui que tu décris.

Il se "contente" de prouver l'absence de data races et la conformité séquentielle de ton code ! Bref, il se contente de rendre simple et "sûr" (*) quelque chose qui est aujourd'hui extrêmement périlleux, délicat et pourtant si nécessaire.
(*) aussi sûr que n'importe quoi d'autre en programmation en général

C'est énorme ! Et si tes critiques ne sont pas infondées je pense que tu devrais pourtant te demander si cette insistance à saper le bénéfice évident et conséquent que j'ai décrit sur un problème très important et très difficile ne relève pas d'autre chose qu'une simple exploration intellectuelle. J'ai malheureusement constaté que les programmeurs sont extrêmement conservateurs et défendent farouchement leurs langages - bien au-delà du raisonnable.
4  2 
Avatar de white_tentacle
Membre émérite https://www.developpez.com
Le 20/05/2015 à 12:24
La grosse différence, c’est qu’en monothread, tu es synchrone, alors qu’en concurrent, tu es asynchrone. Et donc, les explosions du nombre d’état arrivent beaucoup plus vite.

De plus, pour le monothread, on sait se limiter à des sous-ensemble d’opérations qui garantissent la terminaison (ça implique de ne pas être turing-complet). En concurrent, là aussi c’est beaucoup plus la merde car tu introduis du non-déterminisme. En très gros (c’est que ça commence à remonter maintenant), il ne suffit pas de prouver individuellement chacun des composants de ton système pour prouver le système lui-même --> l’explosion du nombre d’états est quasi systématique et toute la difficulté consiste à simplifier ça pour réussir à faire fonctionner les outils d’exploration (il y a aussi des trucs pour faire de la preuve formelle sur systèmes concurrents (cf π-calculus par exemple), mais là la page wiki expliquera ça bien mieux que je ne pourrais le faire avec mes maigres souvenirs).
2  0 
Avatar de DonQuiche
Expert confirmé https://www.developpez.com
Le 25/05/2015 à 10:45
Citation Envoyé par _skip Voir le message
On peut tout ramener à soi et estimer qu'on a pas besoin de ces facilités faites pour les tocards, mais dans la pratique on se retrouve immanquablement dans des équipes composées de différentes personnes de niveaux parfois inégaux et là, il y pas de raison de ne pas être preneur de toutes les vérifications et sécurités qu'on peut nous proposer, surtout quand elles sont gratuites et automatiques.
Et, surtout, même le demi-dieu du code fait des erreurs, alors que certains projets exigent zéro erreurs ou problèmes de sécurité.

C# et Java étaient entre autres prévus pour être manipulables par n'importe qui en prenant complètement en charge certains problèmes au détriment des performances. Un de leurs buts était de permettre le recrutement de développeurs peu fiables pour des projets à la complexité simple à modérée.

Ce n'est pas l'optique de Rust qui a été pensé pour la programmation système et autres projets à haut niveau de sécurité. La démarche de Rust est de contraindre le programmeur à prouver via le système de types et à la compilation que son code possède certaines qualités (absence de fuite mémoire, absence de data race, impossibilité de lire en-dehors des bornes, etc). Un mauvais programmeur aurait de toute façon du mal à comprendre ces concepts.

Rust ressemble plutôt à un langage fait pour de bons programmeurs travaillant dans des domaines relativement exigeants en termes de sécurité et de fiabilité.
2  0