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

Le , par Hinault Romaric, Responsable .NET
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


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de xetqL xetqL - Membre du Club https://www.developpez.com
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 éminent https://www.developpez.com
le 13/07/2012 à 20:03
Tu auras la réponse a la plupart de tes question là:
- https://github.com/mozilla/rust/wiki...oc-project-FAQ
- https://github.com/mozilla/rust/wiki...c-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 éprouvé https://www.developpez.com
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 - Futur Membre du Club https://www.developpez.com
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...oc-project-FAQ
- https://github.com/mozilla/rust/wiki...c-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 https://www.developpez.com
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 expérimenté https://www.developpez.com
le 16/07/2012 à 17:33
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 éminent https://www.developpez.com
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 éminent https://www.developpez.com
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 émérite https://www.developpez.com
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 - Membre émérite https://www.developpez.com
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.

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.


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.
Contacter le responsable de la rubrique Accueil