IdentifiantMot de passe
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 0.2 disponible : la nouvelle version du langage de Mozilla supporte FreeBSD
Et apporte de nouvelles fonctions

Le , par Hinault Romaric
137 commentaires

95PARTAGES

0  0 
Mise à jour du 18/04/2012

Juste quelques mois après la publication de la version 0.1 de Rust et de ses premiers outils de développement, Mozilla fait encore évoluer son langage de programmation.

La communauté en charge du développement de Rust vient d’annoncer la publication de la version 0.2 et de son compilateur qui intègre plus de 1500 changements.

Avec cette version, Mozilla met à la disposition des développeurs un nouveau port des outils de Rust pour les systèmes FreeBSD 64 bits.

Cette mise à jour apporte des améliorations de performances pour le compilateur, la transmission de messages et introduit un ordonnanceur explicite. Les fonctions C-callback, les boucles infinies et les caractéristiques expérimentales comme les classes, les surcharges des opérateurs et les pointeurs ont subi également quelques modifications.

Pour rappel, Rust met beaucoup l’accent sur 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".

Rust 0.2 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.

Télécharger RUST 0.2

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

137 commentaires
Commenter Signaler un problème
DonQuiche
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 
_skip
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 
Uther
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 13/04/2015 à 0:36
Citation Envoyé par BugFactory Voir le message
En revanche, il y a encore du retard niveau performances. Le dernier benchmark que j'ai lu faisait état de performances à 85% du C. Mais ça date, quelqu'un a peut-être des chiffres plus récents?
Rust n'est pas vraiment en retard sur les performance. Il est basé sur LLVM sur lequel il se repose très lourdement pour l'optimisation ce qui lui permet d'avoir de plutôt bon résultats.

Après dire directement que les performance de Rust sont de 85% celle de C ne veux rien dire, il y a plein de situation particulières très différentes qui peuvent favoriser l'un ou l'autre. Et surtout, il faut voir que sur de sur des micro-benchmarks de langages, il est très facile d'avoir de légères différences involontaires qui ont un impact significatif. Ces derniers temps, j'ai vu beaucoup de personnes annoncer qu'un langage est beaucoup plus rapide/lent que ses concurrents avec un micro-benchmark réalisé par leur soin à l'appui, mais dès que les connaisseurs des langages en défaut se penchaient sur les détails du benchmark, on trouvait rapidement l'explication et finissait avec des résultats très proches.

Il s'avère qu'au final, s'ils sont bien écrits et travaillent dans des conditions identiques, les langages a visée système, compilés en binaire, statiquement typés et sans GC (C++, D, Nim, Rust) sont tous très rapides et ont des performance à peu près similaires. Un peu après viennent les langages compilés en binaire et statiquement typés, mais sans visée système et avec un GC comme le GO. Encore après se placent généralement les langages a VM avec GC comme C# / Java. Puis les langages dynamiquement typés comme Javascript / Ruby.
Mais là encore ça n'est que appréciation globale, si on cherche des cas particuliers, on va évidement facilement trouver des cas très particuliers ou un langage va sur-performer et inversement.

Citation Envoyé par yahiko Voir le message
Je n'ai toujours pas compris pourquoi Mozilla s'embarquait dans cette galère alors qu'ils ont à mon humble avis d'autres priorités plus urgentes (comme améliorer les performances de Firefox qui commence à tirer la langue).
Ne t'inquiète pas Mozilla investit encore énormément plus de moyens plus dans l'amélioration de Firefox que dans Rust.
Rust et Servo sont juste des projets de leur partie R&D, que toute entreprise qui envisage d'avoir un avenir ne doit pas négliger.
4  0 
DonQuiche
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 
white_tentacle
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 
Uther
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 
Uther
Avatar de Uther
Expert éminent sénior 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.
3  0 
razlock
Avatar de razlock
Membre à l'essai https://www.developpez.com
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
3  0 
gangsoleil
Avatar de 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.
3  1 
Firwen
Avatar de 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.
2  0 
Commenter Signaler un problème