La Fondation Mozilla publie Rust 0.1

Envoyé par yahiko

Il suffit d'avoir un minimum de culture en programmation pour savoir qu'il est normal que Rust ait des performances en deçà du langage C (à qualité de code égale évidemment). Que cela se traduise dans les benchmarks, encore heureux. Qu'on tente de dire "non il ne faut pas se fier aux benchmarks", j'ai envie de dire que les benchmarks ont quand même une part de réalité sous-jacente. C'est assez pénible de lire des gens vouloir sans cesse les remettre en cause quand ça ne les arrange pas.
Quelle honte à dire qu'un langage est moins rapide que le C ? Aucune puisqu'à part de l'assembleur spécifique, aucun autre langage n'est plus performant.

Je pense que ce qu'il a voulu dire, c'est que les performances des langages à typage statique et compilés dont Rust fait partie occupent généralement le haut du tableau. L'ordre de différence entre les langages de cette catégorie est souvent bien moindre qu'entre n'importe lequel d'entre eux et les langages managés comme Java, C#.

Donc par rapport à ton interrogation sur le "sens" que fait Rust, la réponse serait clairement d'offrir une expérience développeur comparable aux langages managés (typage fort et statique, compilation rapide, sucres syntaxiques, sécurité, GC) sans trop renoncer aux performances de premier ordre possibles avec les langages non managés à compilation AOT. Dans mon domaine métier par exemple, pour le moment c'est C++ ou Java et ça me plairait énormément d'avoir une solution entre deux.

Là dessus tu pourrais me répondre, pourquoi pas D? En effet, je me contenterai de D si j'avais l'impression que ça bougeait mais il semble que ses auteurs ne savent tout bonnement pas y faire (je m'excuse auprès des fans de D).

Envoyé par yahiko

Pour ce qui est de fournir une "expérience" pour le développeur, je n'ai rien contre. Mais on ne me fera pas croire que Rust est l'outil qui permettra à Mozilla de booster les performances de Firefox, par exemple.

Personne n'a dit ça en ces termes-là il me semble.
Je pense justement que ce projet de moteur de browser est aussi là pour prouver au plus grand nombre la viabilité de ce nouveau langage. Sinon je pense pas que quelqu'un se ferait chier à développer un langage de programmation juste pour ça. Pour que l'effet soit présent, il fallait que ce soit quelque chose d'assez critique question performance et d'une envergure suffisamment conséquente, ce qui explique ce choix. Parce que si tu te mets à avancer comme arguments les performances et la maintenance, il faut un showcase assez sérieux pour appuyer tes propos.

Envoyé par yahiko

Il n'en reste pas moins que Rust est fondamentalement moins rapide que le C à cause de certains de ses contrôles systématiques, et qu'il est normal que cela se traduise dans les benchmarks. Je pense que cela va mieux en le disant.

Le seul contrôle systématique que fait le langage Rust à l'exécution par rapport au C est, comme je l'ai cité plus haut, le contrôle du dépassement de tableau quand on y fait un accès direct. Et encore il y a moyen de l’éviter dans les cas où ça serait critique pour les performances en utilisant un bloc unsafe. Les autres contrôles sont effectuées au moment de la compilation et n'ont donc pas d'impact sur les performances.
Et ne t'en déplaise sur certains benchmarks Rust est légèrement meilleur que GCC même s'il est battu sur d'autres.

Envoyé par yahiko

Pour ce qui est de fournir une "expérience" pour le développeur, je n'ai rien contre. Mais on ne me fera pas croire que Rust est l'outil qui permettra à Mozilla de booster les performances de Firefox, par exemple.

Personne n'a jamais dit cela. Le but de Rust est d'avoir un langage avec des performances comparables au C++ mais un bien meilleure sécurité au niveau de la mémoire et du parallélisme.
Le parallélisme étant tout de même une clé pour l’amélioration des performances à l'avenir

Envoyé par yahiko

S'il n'y a qu'un seul contrôle systématique (donc une "expérience" développeur somme toute limitée du coup) c'est inquiétant alors... Autant revenir au langage C et récupérer les 15% de perfs perdues par Rust.

Pourtant j'ai bien précisé à l'exécution. Bien sur que Rust permet de faire bien plus que du contrôle de buffer overflow, sinon il n'aurait en effet aucun intérêt.
Mais la garantie de la sécurité mémoire se fait principalement grâce à des règles plus avancées sur la durée de vie des ressources qui sont vérifiées à la compilation et n'ont pas d'impact sur les performances.

Envoyé par yahiko

Oui, il faut bien des cas cliniques où un langage est meilleur qu'un autre. Même JavaScript est meilleur que le C++ sous certaines utilisations tu sais.

On est bien d'accord et c'est pour cela que dire qu'un langage est globalement x% plus lent qu'un autre n'a aucun sens si on ne précise pas ce qu'on a mesuré.

Envoyé par yahiko

A moins que je ne sache pas lire, ça y ressemble fortement tout de même...

Le but c'est que Rust aide à la réécriture d'un moteur Web qui tire pleinement parti du parallélisme. Sur ce point la Rust aide notamment parce que son modèle de sécurité mémoire permet d'éliminer complètement les "Data race".

Envoyé par yahiko

Attention à ne pas confondre une mesure à un benchmark... Un benchmark est un ensemble de mesures qui permet justement de juger de la qualité d'un système, ici un langage, en tenant compte de multiples situations. Sur quelques mesures, que Rust puisse être plus rapide que C, pourquoi pas, même JavaScript peut être plus rapide que le C++ sur certaines mesures. Mais sur la globalité d'un benchmark, quand il est suffisamment bien pensé, est en général révélateur des différences.
Donc on est bien d'accord que tu nies la pertinence du benchmark, alors que je pense qu'il est tout à fait révélateur du retard de Rust sur le langage C en terme de performance.

Au contraire, sur ce point on est tout à fait d'accord.
Le soucis, c'est que j'ai beau suivre l'actualité qui concerne Rust, je n'ai vu pour le moment aucun benchmark complet sérieux qui corresponde à ta définition. Je n'ai vu que quelques micro-benchmarks, souvent biaisés dans un sens ou dans l'autre. Et une fois corrigés, les performances devenaient comparables.

D'où le fait que je dise que le chiffre de 85% tiré de nulle part ne veut rien dire.

Envoyé par yahiko

Bien. Cela fait 5 ans qu'ils en parle de cette réécriture censée révolutionner les performances. Attendons donc vu qu'on n'est plus à une année près...

en effet, ne soit pas trop impatient car tu risques de devoir attendre encore quelques années. Servo n'est toujours qu'un projet de R&D même s'il commence à afficher certains sites à peu près convenablement, il est encore très très loin d'être fini.
Il faut voir que ce n'est pas pour rien que Apple et Google malgré leur moyens colossaux ont choisi de forker un moteur existant plutôt que de créer le leur. De nos jours, un moteur Web fait partie des applications les plus complexe. Là Mozilla en recrée un a partir de zéro, et en plus rajoute un niveau de complexité supplémentaire avec le parallélisme.

Envoyé par yahiko

Toujours est-il qu'on est donc bien d'accord que tu penses donc que Rust va contribuer à améliorer les performances de Firefox. Qu'on ne me dise pas que cela n'a pas été évoqué.

Disons que ce n'est pas les performance brutes de Rust qui vont améliorer Firefox dans un avenir proche. Il va juste être un outils pour faciliter le développement de Servo.

Pour ceux que ça intéresse je parlais de ce benchmark :
https://togototo.wordpress.com/2013/...la-and-nimrod/
- Comme tous les benchmarks, il est critiquable. Mais il a un mérite important : son auteur a remplacé le code qu'il avait écrit lui-même par des sources proposées par des experts de chaque langage.
- J'avais été impressionné par les performances du D, qui dépasse même le C++. Je me demandais si il y avait des changements du cité de Rust, le benchmark datant d'il y a près de deux ans.
- De nouveaux benchmarks publiés sur le même site donne une vitesse d'environ 90% du C. Un détail intéressant est que Rust s'en tire beaucoup mieux sur les architectures ARM que Java ou C# dont les performances plongent par rapport à ce qu'elles sont sur x86.

Je me suis intéressé à ces langages car je travaille principalement en Java. Pour des raisons qui sont hors sujet, j'en suis satisfait pour la création de clients légers mais pas pour le développement de clients lourds. Mais après avoir été pourri gâté par le Java, le C++ a l'air pénible. Je surveille donc les langages émergents en me demandant sur lequel investir. Je me retrouve donc devant ma boule de cristal, a essayer de prédire celui qui sera le plus adopté, et donc celui qui aura les meilleures garanties de pérennité.

A en croire l'article paru ici-même à
http://jeux.developpez.com/videos/Cp...jeux-triple-A/
le C++ est choisi en raison de ses performances. Tant pis si il est difficile : c'est le résultat qui compte. Rust, avec des performances en deça du C++, ne touchera pas ce public. Certes, toutes les applications n'ont pas besoin de performances extraordinaires. Les 10% de moins de Rust seraient imperceptibles sur les applications de gestion sur lesquelles je travaille habituellement. Mais qui peut le plus peut le moins, et un langage avec une vitesse comparable au C++ recevra beaucoup d'attention. Et donc plus de librairies, etc. D'où l'intérêt particulier que je prête à ce critère.

Je ne vois pas ce que rust ou go peuvent apporter de plus.

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

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.

Envoyé par pierreact

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.

Envoyé par pierreact

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 ?!

Envoyé par FlyersWeb

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++.

Envoyé par white_tentacle

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.