Rust 0.3 disponible : le langage de Mozilla dérivé du C/C++
Gagne en maturité avec 1900 changements

Le 13/07/2012, par Hinault Romaric, Responsable Actualités
Mise à jour du 13/07/2012

Rust le langage de développement de la fondation Mozilla évolue rapidement et atteint sa version 0.3.

Pour rappel, Rust a été développé comme une alternative aux langages C et C++, et reprend une grande partie de la syntaxe de ceux-ci, avec un point d’honneur accordé à la sécurité par rapport à la performance. L'objectif de Mozilla est de "concevoir et implémenter un langage orienté objet statique, typé, sûr, concurrentiel et efficace".

La version 0.3 de Rust apporte 1900 changements par rapport à la version 0.2 qui avait été publiée en avril dernier, dont un nettoyage sémantique du langage, l’amélioration de l’expérience utilisateur lors du codage, de nouvelles caractéristiques linguistiques encore en phase expérimentale et la suppression de certaines fonctions obsolètes.

Le nombre de types supporté par le langage évolue avec des nouvelles fonctions de temps. Rust dispose désormais des extensions de syntaxe pour la création des chaines à partir des expressions, et est même capable d’utiliser le contenu d’un fichier comme une expression Rust.

De nouvelles fonctionnalités expérimentales dont le support de nouveaux types de vecteurs ont été ajoutées. La prise en charge du shebang (#! - Indicateur en entête d’un fichier sous Unix, pour spécifier au système que ce fichier est un script, tout en fournissant le nom de l'interpréteur) permet désormais de définir des scripts Rust.

Rust 0.3 offre également un contrôle plus granulaire sur les avertissements et les erreurs générées par le compilateur.

Rust 0.3 est considéré comme une version Alpha et vise principalement les early adopters. Il est disponible sous une licence open source MIT pour Linux, Windows, Mac OSX et FreeBSD. Rust a été utilisé par Mozilla pour développer le moteur de rendu expérimental pour navigateur Servo.

Télécharger Rust 0.3

Source : Notes de version


 Poster une réponse

Avatar de xetqL xetqL
Membre du Club
le 13/07/2012 18:49
Encore un langage qui vient s'ajouter à la panoplie que l'on possède déjà ...
Je n'ai pas tous lu, mais qu'apporte-t-il de plus ?
Certes j'y vois une synthèse de plusieurs langage (on peut distinguer une philosophie plus Python, une syntaxe C...) mais est-il vraiment plus approprié d'utiliser un langage comme celui ci ? J'en doute..

Wait & see ...
Avatar de Uther Uther
Expert Confirmé Sénior
le 13/07/2012 20:03
Tu auras la réponse a la plupart de tes question là:
- https://github.com/mozilla/rust/wiki/Doc-project-FAQ
- https://github.com/mozilla/rust/wiki/Doc-language-FAQ

C'est difficile de donner un avis définitif sur le langage alors que la syntaxe et les fonctionnalités de base continuent d'évoluer lourdement.
Le langage me semble avoir un réel intérêt. Il me semble clairement plus tourné vers la sécurité que le D ou le Go, et plus vers les performances que l'ADA.
Avatar de abriotde abriotde
Membre habitué
le 13/07/2012 21:27
Il est vrai qu'entre le Google Go et le Rust les différences me semblent mineures. Cependant il est certain que l'on a besoin d'un langage plus puissant et souple que le C/C++ (Plus rapide à compiler et interpréter aussi).

Pour moi le Go est meilleurs parce que Google à son habitude cherche l'hyper-optimisation. Or c'est là-dessus qu'on l'attend. La langage de la souplesse moderne est certainement un Python.
Avatar de codeallergy codeallergy
Invité régulier
le 14/07/2012 20:53

Citation:





Envoyé par Uther
Voir le message

Tu auras la réponse a la plupart de tes question là:
- https://github.com/mozilla/rust/wiki/Doc-project-FAQ
- https://github.com/mozilla/rust/wiki/Doc-language-FAQ

C'est difficile de donner un avis définitif sur le langage alors que la syntaxe et les fonctionnalités de base continuent d'évoluer lourdement.
Le langage me semble avoir un réel intérêt. Il me semble clairement plus tourné vers la sécurité que le D ou le Go, et plus vers les performances que l'ADA.



Ada (et non ADA) a rien a envier au C ou Fortran.
Avatar de gangsoleil gangsoleil
Modérateur
le 16/07/2012 16:18
J'ai l'impression que ce qu'ils veulent faire, c'est du C (ou du C++) pour les nuls

C'est a dire que tu as de la gestion memoire, mais on verifie le truc parce que vraiment les dev ils font n'importe quoi. Et puis pareil avec le reste.

M'est avis que c'est trop bas niveau pour le dev haut-niveau, et pas assez permissif pour le dev bas-niveau. Donc que ca restera un langage de plus dans la mer des langages tres peu utilises.
Avatar de Firwen Firwen
Membre Expert
le 16/07/2012 17:33

Citation:




J'ai l'impression que ce qu'ils veulent faire, c'est du C (ou du C++) pour les nuls

C'est a dire que tu as de la gestion memoire, mais on verifie le truc parce que vraiment les dev ils font n'importe quoi. Et puis pareil avec le reste.

M'est avis que c'est trop bas niveau pour le dev haut-niveau, et pas assez permissif pour le dev bas-niveau. Donc que ca restera un langage de plus dans la mer des langages tres peu utilises.


Pas vraiment, non.
La syntaxe est basé sur OCaml, c'est à dire un des langages les plus concis qui existe et des plus haut niveau qui existe ( le ML pour "meta-langage" n'est pas là pour décorer ).
OCaml comme Rust propose l'heritage structurel, le pattern matching, l'inférence des types et une VRAI généricité qui sont des fonctionnalités de très haut niveau.

Je pense au contraire qu'ils essaient de faire du Ocaml avec un typage un peu moins nazi / un peu plus permissif : le support du polymorphisme et la surcharge vont dans ce sens.
Et au passage avec une VRAI gestion de la programmation concurrente ( ce qui est le talon d’Achille d'OCaml ).

Il y a de forte chance qu'il y ait un marché pour ce langage ou un langage du même type, des tas de projets d'envergure ont besoin d'un langage compilé qui fournit une approche pragmatique entre sécurité et performance.
Avatar de Uther Uther
Expert Confirmé Sénior
le 16/07/2012 18:36

Citation:





Envoyé par gangsoleil
Voir le message

J'ai l'impression que ce qu'ils veulent faire, c'est du C (ou du C++) pour les nuls

C'est a dire que tu as de la gestion memoire, mais on verifie le truc parce que vraiment les dev ils font n'importe quoi. Et puis pareil avec le reste.



En effet les développeur C et C++ font n'importe quoi car ces langages font qu'il est très facile de faire des bêtises sans s'en rendre compte.
Et même les meilleurs peuvent se faire avoir.


Citation:





Envoyé par gangsoleil
Voir le message

M'est avis que c'est trop bas niveau pour le dev haut-niveau, et pas assez permissif pour le dev bas-niveau. Donc que ca restera un langage de plus dans la mer des langages tres peu utilises.



J'ai du mal à voir en quoi le langage serait pas assez permissif. A priori, tout est réalisable avec seulement la contrainte de devoir utiliser des blocs "unsafe" si on veut briser les contrôles de sécurité en connaissance de cause.


Citation:





Envoyé par Firwen
Voir le message

Pas vraiment, non.
La syntaxe est basé sur OCaml, c'est à dire un des langages les plus concis qui existe et des plus haut niveau qui existe ( le ML pour "meta-langage" n'est pas là pour décorer ).
OCaml comme Rust propose l'heritage structurel, le pattern matching, l'inférence des types et une VRAI généricité qui sont des fonctionnalités de très haut niveau.



Je dirais que Rust comme C++ est à la fois de haut et bas niveau car il offre clairement les fonctionnalités que tu as cités mais permet un accès direct au ressources du systèmes et reste orienté performances.
Avatar de _skip _skip
Expert Confirmé Sénior
le 16/07/2012 19:18
Laisser le pilote automatique s'occuper des trucs généraux et garder la possibilité de prendre le contrôle manuel lorsque les performances doivent vraiment primer sur le reste.

Je trouve que ça correspond bien à la phrase qui dit que bien souvent, seul un faible pourcentage du code est réellement significatif pour les performances alors que le reste (GUI, configuration) tend à privilégier la sécurité et la lisibilité du code.

Si on compte qu'utiliser du code C dans un programme .Net, python ou Java a souvent quelques inconvénients, notamment de conversion de type, ne serait-il pas super d'avoir tout en un et même langage?
Avatar de white_tentacle white_tentacle
Membre Expert
le 17/07/2012 15:48
Je suis comme __skip, plutôt très enthousiasmé par ce que je vois du langage, et des choix qui ont été faits (il n’y a guère que la syntaxe dont je ne suis pas fan). Au contraire de go, qui m’avait laissé dubitatif.

Un langage fortement typé, avec peu de mutables ou d’aliasing, c’est le genre de choses qui se prête très bien à de la vérification statique. Et de ce côté là, il y a une vraie valeur ajoutée à créer.
Avatar de Freem Freem
Expert Confirmé
le 23/07/2012 15:26

Citation:





Envoyé par Uther
Voir le message

En effet les développeur C et C++ font n'importe quoi car ces langages font qu'il est très facile de faire des bêtises sans s'en rendre compte.
Et même les meilleurs peuvent se faire avoir.




Citation:




I'm impatient. Can you give a brief summary of the salient features?
Safety oriented:
Memory safe. No null pointers, wild pointers, etc. Automatic storage management.
Mutability control. Immutable by default. No shared mutable state across tasks.
Dynamic execution safety: task failure / unwinding, trapping, logging. RAII / dtors.


Je suis d'accord, C++ utilise un peu trop les pointeurs bruts (je pense qu'il s'agit d'une des pires causes de problèmes, en seconde position, je miserai volontiers sur les Ctor par copie). En fait, C++ ne proposait pas de mécanique correcte pour gérer la mémoire avant le standard 2011, mais je trouve que le std::unique_ptr résout pas trop mal le problème (même si j'aurai apprécié une variante de weak_ptr pour les unique...).
Côté pointeurs et C++, personnellement, je ne m'en sers que pour le polymorphisme et l'interfaçage avec du code qui les utilise (genre une lib C). Dans ce dernier cas, il m'arrive très souvent d'encapsuler ces pointeurs dans une classe spécialisée, histoire de me décharger de cette responsabilité inutile.
Je leur préfère de très loin les références et les conteneurs standards, ce qui en fait correspond à la fonctionnalité de Rust "Memory safe. No null pointers, wild pointers, etc. Automatic storage management."

La seconde de leur fonctionnalité niveau sécurité, "Mutability control. Immutable by default. No shared mutable state across tasks." est, encore, présente en C++. Quoique, peut-être pas le dernier élément, je ne suis pas pointu (jamais vraiment touché à ça pour le moment) en multitâche pour le dire.

Le 3ème argument semble plus pertinent, au moins au niveau des retours: je ne crois pas qu'un système de log soit intégré au C++, bien qu'il soit faisable via les mécanismes d'exception et de surcharge des new&delete.
Quant à la RAII, je crois bien que j'ai un mal fou à m'en passer, ce n'est pas vraiment une nouveauté.

D'ailleurs, tout ces points valables en C++ me semblent aussi présents voire meilleurs dans d'autres langages déjà existants.


Citation:




J'ai du mal à voir en quoi le langage serait pas assez permissif. A priori, tout est réalisable avec seulement la contrainte de devoir utiliser des blocs "unsafe" si on veut briser les contrôles de sécurité en connaissance de cause.

Je dirais que Rust comme C++ est à la fois de haut et bas niveau car il offre clairement les fonctionnalités que tu as cités mais permet un accès direct au ressources du systèmes et reste orienté performances.


Personnellement, j'ai l'impression que Rust vise a pallier les faiblesses de C++ dans le multi-tâche.
C'est en tout cas la seule chose qu'il semble avoir que C++ n'a (n'avais avant 2011?) pas, puisque la sécurité du code, C++ à des mécanismes qui lui permettent d'être stable, il faut simplement arrêter de ne penser qu'a la compatibilité C (bon, ok, j'utilise certaines fonctions du C: printf/scanf, parce que j'abhorre les flux en C++) et utiliser les références, le mot-clé "const" et utiliser les conteneurs plutôt que de vouloir faire de l'allocation dynamique manuelle. Et quand on veut de l'alloc dynamique manuelle, rien n'empêche de faire une classe qui ne fasse que ça, plutôt que de noyer les responsabilités dans 20K LoC.

Pour le multitâche, je ne sais pas si Rust apporte beaucoup. Tout simplement parce que je n'ai jamais essayé d'en faire en C++.

La lenteur de compilation du C++, on en parle souvent, et c'est vrai qu'il y a un certain souci, mais est-ce que le souci ne viens pas aussi en partie de notre habitude de regrouper toutes les implémentations des méthodes d'une classe dans un seul fichier? Certes, c'est plus simple à lire, et c'est aussi ce que je fait, mais ça implique que modifier une fonction déclenche la compilation de l'ensemble du fichier. Si il n'y avait qu'un fichier par implémentation, je me demande comment seraient les temps de compilation? Je pense que la compilation totale serait plus longue, mais la compilation incrémentale accélèrerait, non?

Perso, je pense qu'un des plus gros défaut de C++ est la complexité même du langage pour les compilateurs: certains mots-clefs n'ont pas la même signification selon l'endroit ou ils sont par exemple...

PS: je n'ai parlé que de comparaison avec C++, puisqu'ils semblent vouloir un langage multi-paradigme et compilé, et que C++ est le seul que je connaisse qui aie ces propriétés.
Avatar de Uther Uther
Expert Confirmé Sénior
le 23/07/2012 18:31

Citation:





Envoyé par Freem
Voir le message

Je suis d'accord, C++ utilise un peu trop les pointeurs bruts (je pense qu'il s'agit d'une des pires causes de problèmes, en seconde position, je miserai volontiers sur les Ctor par copie). En fait, C++ ne proposait pas de mécanique correcte pour gérer la mémoire avant le standard 2011, mais je trouve que le std::unique_ptr résout pas trop mal le problème (même si j'aurai apprécié une variante de weak_ptr pour les unique...).



Sauf qu'en Rust ces notions sont intégrés au langage, pas dans les bibliothèque standard. ce qui permet au compilateur de contrôler leur bon usage


Citation:





Envoyé par Freem
Voir le message

La seconde de leur fonctionnalité niveau sécurité, "Mutability control. Immutable by default. No shared mutable state across tasks." est, encore, présente en C++. Quoique, peut-être pas le dernier élément, je ne suis pas pointu (jamais vraiment touché à ça pour le moment) en multitâche pour le dire.



Je suis pas un expert en C++ et je ne connais pas la dernière norme par coeur, mais je ne vois pas comment C++ pourrait avoir des types immuables pas défaut. Ça briserait toute la compatibilité antérieure.


Citation:





Envoyé par Freem
Voir le message

C'est en tout cas la seule chose qu'il semble avoir que C++ n'a (n'avais avant 2011?) pas, puisque la sécurité du code, C++ à des mécanismes qui lui permettent d'être stable, il faut simplement arrêter de ne penser qu'a la compatibilité C (bon, ok, j'utilise certaines fonctions du C: printf/scanf, parce que j'abhorre les flux en C++) et utiliser les références, le mot-clé "const" et utiliser les conteneurs plutôt que de vouloir faire de l'allocation dynamique manuelle. Et quand on veut de l'alloc dynamique manuelle, rien n'empêche de faire une classe qui ne fasse que ça, plutôt que de noyer les responsabilités dans 20K LoC.



Sauf que toute ces chose qu'il faut penser a faire en C++, sont faites par défaut en Rust.


Citation:





Envoyé par Freem
Voir le message

La lenteur de compilation du C++, on en parle souvent, et c'est vrai qu'il y a un certain souci, mais est-ce que le souci ne viens pas aussi en partie de notre habitude de regrouper toutes les implémentations des méthodes d'une classe dans un seul fichier?



Je ne crois pas que l'on ait parlé de lenteur de compilation. en tout cas ce n'est absolument pas un objectif prioritaire de Rust.
Avatar de air-dex air-dex
Membre Expert
le 23/07/2012 23:16

Citation:





Envoyé par Uther
Voir le message

Je ne crois pas que l'on ait parlé de lenteur de compilation. en tout cas ce n'est absolument pas un objectif prioritaire de Rust.



Cela avait été évoqué pour Google Go.
Avatar de razlock razlock
Futur Membre du Club
le 25/07/2012 12:42
J'ai testé le Rust hier avec la dernière version stable du compilateur rustc.

Je suis un adepte du C++ et j'ai trouvé plein de choses super dans de Rust. La grammaire du langage semble bien plus simple que celle du C++ : le meilleur exemple est la distinction dans la déclaration des fonctions ou des variables qui sont forcément précédées de fn ou de let. La compilation via des outils comme llvm doit être bien plus rapide et plus "déterministe" ...

Ensuite le langage apporte un gros plus sur la gestion de la mémoire : la pile, le tas, ou des variables partagées pour le multithreading. Il y a peu de langages qui permettent ça et en C++ c'est pas simple du tout de faire des programmes qui utilises plusieurs coeurs. Il y a bien des trucs comme MPI ou openmp pour avoir testé et pour y être confronté en ce moment même, mais il n'y a absolument aucun moyen de faire quelque chose de simple dès qu'un projet devient complexe et le principal problème c'est justement le partage des variables en mémoire.

Il y a d'autres différences avec le C++, comme par exemple le fait que par défaut toutes les variables sont "constantes" si on utilise pas le mot-clé "mut". L'api par défaut semble plus évoluée, du moins plus simple à l'image d'autres langages comme le C# ou le Java, même si elle est encore incomplète. Le côté généricité à l'air d'être un peu mieux penser mais je ne vais pas trop m'avancer. Pour moi c'est vraiment sur le mlti-tâche que le langage va se distinguer, mais pour ça il faut qu'il soit performant. SI un programme C++ non multi-tâche est plus rapide qu'un programme Rust multi-tâche (comme c'est souvent le cas avec certaines bibliothèques ou d'autres langages), alors l'intérêt du diminue beaucoup.

Finalement j'ai fais tourner un petit code (un test de primalité) en Rust, en C++ et même en D et en Python avec le même niveau d'optimisation (sauf en Python, yen a pas). Il en résulte que Rust est actuellement 2,2 fois plus lent que le C++.

Je possède un core i7 sur un portable récent, et le code tourne sur un seul coeur (rien de spécial donc)

C++ : 4.3s
D: 5.1s
Rust: 9.5s
Python: > 2min

Voilà ma petite contribution pour ceux que ça intéresse, néamoins le langage n'en est qu'à ses débuts et je pense qu'il a les moyens d'être beaucoup plus rapide que ça
Avatar de _skip _skip
Expert Confirmé Sénior
le 25/07/2012 13:30
Et bien merci pour ce retour très intéressant. On sent que le ressenti global est assez positif. D'un point de vue langage je pense aussi que les références mutables devraient être des exceptions plutôt que des règles en ce sens je suis assez d'accord avec l'approche de rust qui est de dire "ça bouge pas sauf si vraiment ça doit".

Pour les performances je pense que tu as juste, la plupart des compilos C++ ont des années d'optimisation derrière eux, il faudra surement attendre que rust soit feature complete avant que vraiment les gens se mettent à se focaliser sur la vitesse d'exécution.
Avatar de Flaburgan Flaburgan
Modérateur
le 26/07/2012 9:35
Le langage à l'air de plus en plus intéressant au fur et à mesure que je lis l'avis des gens

Je vais attendre encore quelques mois, et quand il se sera plus stabilisé, je l'essayerai, et si j'ai le courage, peut être un petit tuto sur dvp.com
Avatar de Uther Uther
Expert Confirmé Sénior
le 26/07/2012 9:53
Je suis un peu la mailing list des développeurs, je ne conseillerais pas de s'y mettre tout de suite, si ce n'est pour participer a l'élaboration du langage(développement, tests, retour d'expérience...). Le langage est encore en train d'évoluer lourdement, sur y compris sur des notions fondamentales qui brisent la compatibilité ascendante.
Pas mal de notions sont supprimées pour être remplacées par d'autres. Par exemple les interfaces vont disparaitre pour être remplacées par des traits, la notation des closures et des pointeurs change, ...
Je pense c'est encore trop tôt pour faire des tutoriels sur developpez.com.

Pour ce qui est de la simplicité de la bibliothèque standard, elle vient surtout de sa pauvreté. Là encore Rust est loin d'être prêt pour une utilisation massive par tous.
Heureusement on peut s'interfacer avec des bibliothèques C/C++.

Pour le moment les deux seul gros projets qui utilisent le langage Rust, c'est le compilateur Rust lui même et Servo, le moteur de rendu encore très expérimental de Mozilla qui remplacera peut-être Gecko un jour.
Avatar de Uther Uther
Expert Confirmé Sénior
le 16/10/2012 11:40
Pour info Rust 0.4 est disponible: https://github.com/mozilla/rust/wiki/Doc-releases

C'est toujours destiné a ceux qui veulent participer a l'élaboration du langage(codage, test, documentation, création d'outils, ...) C'est encore incomplet, buggé, et les API sont toujours minimales et partiellement documentées.
Ils ont essayé de placer le plus possible des changements de syntaxe prévus dans cette version pour la stabiliser par la suite. Mais il en reste encore quelques a venir.

J'aime bien la façon dont il évolue, c'est un langage qui n'est clairement pas évident a prendre en main. Il exige de bien comprendre comment il gère la mémoire. Mais le bon point c'est qu'il encadre plutôt bien de manière à empêcher les mauvais usages.
Avatar de Hinault Romaric Hinault Romaric
Responsable Actualités
le 04/04/2013 17:34
Rust 0.6 disponible avec plus de 2 100 changements
Le « C/C++ killer » de Mozilla obtient l’appui de Samsung et vante ses performances avec Servo

Dans la foulée de la présentation de Servo, Mozilla a sorti une nouvelle version de Rust, le langage de développement qui a été utilisé pour le nouveau moteur de rendu Web (Servo).

Rust 0.6 marque une étape très importante dans la stabilisation du langage, qui atteindra bientôt une version finale 1.0, mettant fin aux modifications de syntaxe.

Pour rappel, Rust a été développé comme un « C/C++ killer » et reprend une grande partie de la syntaxe de ceux-ci, avec un point d’honneur accordé à la sécurité, la performance et la concurrence. L'objectif de Mozilla est de "concevoir et implémenter un langage orienté objet statique, typé, sûr, concurrentiel et efficace".

Pour mettre en avant l’aspect sécurité de Rust, Mozilla note, par exemple, le hack de tous les navigateurs au concours Pwn2Own. L’organisme explique que plusieurs vulnérabilités seraient dues à l’utilisation du C++ et que Rust mettrait fin à cela.

La nouvelle version de Rust et de son compilateur apportent plus de 2100 changements, de nombreuses corrections de bugs et des améliorations de la stabilité. Ces modifications touchent la syntaxe, la sémantique et les bibliothèques.

Il faut noter par ailleurs que Rust bénéficie du soutien de Samsung qui aurait fait participer près d’une vingtaine de développeurs aux projets Rust et Servo.

À l’état actuel, Rust semble être sur le bon chemin pour son adoption par les développeurs. La sortie de Servo permettra d’avoir un premier aperçu de ses performances.

Rust 0.6 est disponible sous une licence open source MIT pour Linux, Windows, Mac OSX et FreeBSD. Elle est principalement à destination des early adopters.

Télécharger Rust sur GitHub

Source : Mozilla

Et vous ?

Avez-vous testé Rust ? Que pensez-vous du langage ?

Allez-vous l'adopter ?

Le support de Samsung pourrait-il stimuler l'adoption du langage ?
Avatar de camus3 camus3
Membre émérite
le 06/04/2013 22:28

Citation:




Pour rappel, Rust a été développé comme un « C/C++ killer »


Chez Mozilla peut être , Rust n'a pas "killé" beaucoup de projets en C ou C++ jusqu'à présent.
Avatar de Uther Uther
Expert Confirmé Sénior
le 07/04/2013 12:01
La fondation Mozilla voit certes, Rust comme alternative au C++ dans ses projets futurs, mais elle n'a jamais prétendu que Rust devait être un C++ killer, c'est une extrapolation de l'auteur de l'article. Il est toujours tentant quand on on présente une nouvelle technologie de l'annoncer en tant que killer d'une autre.

D'ailleurs Rust aurait du mal a remplacer le C++ dès à présent. Le langage n'a pas encore une syntaxe totalement stabilisée, même s'il s'en rapproche très fortement.
Et pour ce qui est des bibliothèques standard une grosse partie reste a faire, et une autre grosse partie est à refaire.
 
 
 
 
Partenaires

Hébergement Web