Quelques nouvelles sur Rust à l’occasion de la 0.9

Posté par ariasuni le 21 janvier 2014 à 10:50. Édité par olivierweb, Nÿco, Yves Bourguignon, Benoît Sibaud, palm123, outs, Pierre Jarillon, spider-mario et Bruno Michel. Modéré par ZeroHeure. Licence CC By‑SA.

Étiquettes :

jan.

2014

Mozilla et la communauté Rust ont annoncé la version 0.9 de Rust le 9 janvier.

Cet article présente l'actualité de ce dernier depuis la version 0.8 détaillée en octobre. Rust est un langage orienté sûreté, concurrence, praticité. Concrètement, c’est un langage compilé, orienté système, et multi-paradigme (procédural, fonctionnel, orienté objet). Ce fut une autre sortie mouvementée dans laquelle ont été réalisés d'importants changements, et l’activité autour de Rust n’a jamais été aussi importante !

Résumé

Côté syntaxe, on assiste à une amélioration et surtout, une réduction de la variété des fermetures dans le langage. Cette version commence la dernière série de changements prévus concernant la façon dont les pointeurs sont traités dans Rust. À commencer par la dépréciation des pointeurs partagés et son symbole @, qu’il faudra remplacer par l’utilisation de types de pointeurs intelligents introduits dans la bibliothèque standard.

Le code source du compilateur et de la bibliothèque standard a été nettoyé, optimisé, et de nombreux bogues ont été corrigés. Le travail sur le compilateur a permis d’améliorer la vitesse de compilation et de faire plus d’optimisations. On peut désormais lier statiquement une bibliothèque à la compilation, et le système d’entrées/sorties de la bibliothèque standard a été réécrit.

La documentation a été améliorée et la présentation revue. L'infrastructure de construction a été elle aussi modifiée. Pour rappel, toute modification de code du dépôt Git passe en premier lieu par un robot de construction afin de la valider à l'issue de l'exécution de tous les tests.

Les changements sont détaillés dans la seconde partie de la dépêche.

Note : Comme la précédente version, la version 0.9 doit être considérée comme une version alpha, adaptée pour les curieux, les pionniers et les amateurs du langage. Il y aura encore une 0.10 et probablement une 0.11.

Sommaire

Syntaxe

Macros

La macro fmt! a été remplacée par format!. Cette macro (donc implémentée dans le compilateur) transmet ses invocations au module std::fmt pour formater ses arguments à l'exécution en chaines de caractères et flux. Elle a été présentée dans la dépêche sur Rust 0.8, elle offre une syntaxe beaucoup plus sympathique et puissante que les fonctions de bases du module fmt.

De plus les messages d'erreur de formatage ont été améliorés. Désormais tout Rust profite de format! et des macros info!, debug!, warn!, etc. format! est utilisée en interne par print! et println! depuis la version 0.8. D’ailleurs, print et println (affichage de texte sans formatage) ne sont plus importés par défaut.

format!("Salut")                      // => ~"Salut"
format!("{:s}, j'adore !", "LinuxFr") // => ~"LinuxFr, j'adore !"
format!("Le nombre est {:d}", 1)      // => ~"Le nombre est 1"
format!("{:?}", ~[3, 4])              // => ~"~[3, 4]"
format!("{valeur}", valeur=4)         // => ~"4"
format!("{} {}", 1, 2)                // => ~"1 2"

Type `float`

Dans la dernière dépêche sur Rust, je ne vous ai pas présenté le type float (qui est un f32 en 32 bits et un f64 en 64 bits). C’est normal, il était présent dans la 0.8 mais il avait déjà été supprimé dans la branche maitre, et n’est donc plus disponible à partir de la version 0.9.

Par ailleurs, on ne peut plus écrire les flottants (entre autres nouvelles restrictions) sous forme octale et hexadécimale.

Pointeurs uniques

Désormais,

let x = box "Test";

équivaut à

let x = ~"Test";

Pointeurs partagés

Les pointeurs partagés (@) sont désactivés par défaut en préparation à leur suppression future (on peut les réactiver avec #[feature(managed_boxes)]). Il faut utiliser les types de la bibliothèque standard Gc (pointeurs gérés par un ramasse-miette) ou Rc (pointeurs gérés par des comptages de référence) à la place.

Les pointeurs @mut ont carrément été supprimés. Il faut utiliser les remplacements possibles qui sont Gc<RefCell<T>> ou de préférence Rc<RefCell<T>>, voire aussi Cell<T> pour les types Pod. La syntaxe devient beaucoup plus verbeuse mais la prochaine version allégera la syntaxe (diverses idées sont en développement/en cours de réflexion).

Fermetures

La syntaxe et l'utilisation des fermetures (ou clôtures ou closures en anglais) ont été modifiées :

~fn s’écrit maintenant proc (args) -> ret { … } et ne peut être appelé qu’une seule fois,
&fn s’écrit maintenant |args| -> ret pour correspondre à la forme littérale,
@fns a été supprimé.

do qui fonctionnait avec &fn ne fonctionne maintenant plus qu’avec proc. Le premier peut être appelé plusieurs fois, ne nécessite pas d’allocation et ne peut pas être envoyé à une autre tâche ; le second ne peut être appelé qu’une seule fois, requiert une allocation sur le tas et peut être envoyé à une tâche différente (implémente le trait Send).

Compilateur et bibliothèque standard

Bibliothèque standard

Toutes les dépendances au C++ ont été supprimées. De nombreuses autres améliorations ont permis de grandement simplifier le débogage.

Rust fournit deux implémentations des tâches et des entrées/sorties, qui ont été séparées du reste de la bibliothèque standard, en deux bibliothèques : libnative et libgreen. Chacune a ses avantages et ses inconvénients, libnative utilise le mécanisme de tâche du système et les appels d’entrées/sorties bloquants de la libc ; libgreen utilise la bibliothèque libuv. On peut ainsi choisir celle qui convient le mieux à notre programme.

Autres changements :

std::rt::io est une réécriture de std::io et vient le remplacer dans cette version ;
réécriture de std::comm (canaux pour communiquer entre différentes tâches) ;
suppression du suffixe _iter des noms des méthodes des itérateurs ;
nouveau type natif mutex std::unstable::mutex.

Compilateur

Le processus de compilation a été fortement amélioré, en particulier par trois pull requests. La compilation est plus rapide, et produit des binaires plus performants et de taille réduite.

Autres changements :

enum variant passé en expérimental ;
amélioration des performances (include_bin!, qui inclut le contenu d'un fichier comme blob binaire : compilation 187x plus rapide) ;
désormais l'utilisation de caractère non ASCII dans le nom des identifiants nécessite l'utilisation de feature ;
suppression de #[fixed_stack_segment] pour l’utilisation de code C dans Rust, le dépassement de pile sera détecté autrement ;
avertissement des codes morts lors de la compilation ;
avertissement des conversions de type (casts) inutiles ;
l'attribut de crate pkgid renommé en crate_id, l'attribut link disparait (et avec lui author), la déclaration d'utilisation de bibliothèque externe (extern mod) est modifiée et le compilateur reçoit des options pour extraire ces métadonnées, ce qui facilite l'écriture de Makefile, cela permet d'écrire des fichiers Makefile plus évolués ainsi que d'utiliser CMake.

Plateformes supportées

Rust fonctionne désormais sous Windows (7, Server 2008 R2) seulement x86, Linux (diverses distributions) ARM, x86 et x86-64, OSX 10.6 ("Snow Leopard") et ultérieurs x86 et x86-64, ainsi que Android.

Les procédures d'installation déjà en place pour la version 0.8 (pour Windows, Ubuntu, Arch Linux et Gentoo) décrites dans la précédente dépêche sont toujours valables et ont été mises à jour pour cette version. Dès l'annonce, les paquets pour Ubuntu ont été générés dans le PPA hansjorg/rust, une compilation pour Arch est disponible dans le dépôt [community] et pour Gentoo, l'overlay rust contient un ebuild pour cette version. Le tutoriel détaille aussi l'installation sur les différentes plateformes.

Outils de développement

rust et rusti

Deux outils ont été supprimés :

rust : mentionné dans le paragraphe Hello, world! de la précédente dépêche,
rusti : car il n’a jamais été très fiable.

Cependant, un projet indépendant d'interpréteur Rust interactif écrit en Ruby est apparu : iRust.

rustpkg

L'outil d'empaquetage et de construction pour Rust rustpkg a été totalement réécrit et amélioré, il est toujours en développement. Il a été modifié pour prendre en compte le nouvel attribut de caisse crate_id, il peut tester les exemples de code dans la documentation, il peut tester les paquets (argument test), il supporte les dépendances d’autres langages telles que les bibliothèques C et détecte des caisses (crates) dans le dossier courant.

Les noms de fichier des bibliothèques (le fichier source contient en entête #[crate_type = "lib"];) sont désormais préfixés avec lib à la compilation.

Autres projets indépendants

Un projet indépendant de l'équipe de développement de Rust a vu le jour : rust-ci. C'est un tableau de bord de l'état de compilation des projets en Rust (voire intégration continue) enregistrés sur Travis CI.

En complément, un projet vise à rassembler la documentation des paquets Rust : http://docs.octayn.net/. Actuellement, seul le projet noise contient une documentation.

Le compteur de lignes de code de Ohloh — Ohcount — a été modifié pour établir les statistiques des projets utilisant Rust. Cette modification vient d'être mise en production, les projets sont mis à jour, le langage Rust est désormais listé dans Ohloh. On peut par exemple suivre le nombre de lignes de code en Rust dans le projet Rust lui-même.

Documentation

rustdoc

Pour rappel, rustdoc est l’outil qui génère la documentation à partir des commentaires dans le code source, selon la syntaxe Markdown (syntaxe d’ailleurs utilisée pour les contenus de Linuxfr).

Le consensus semble être qu’utiliser reStructuredText et Sphinx soit la voie à suivre. Ce sont respectivement le langage de balisage léger utilisé pour la documentation de Python, et l’outil qui permet à partir de cette syntaxe de produire la documentation dans plusieurs formats.

Pour le moment, rien n’est décidé, mais la réécriture en cours de rustdoc permettra de changer facilement de syntaxe par la suite.

Tutoriel

Plusieurs paragraphes du tutoriel ont été remaniés pour le rendre plus concret et refléter les nombreux changements du langage (notamment 14 Ownership escape hatches). De nombreux guides ont été remaniés, renommés ou ajoutés.

Côté tutoriel, on a aussi une initiative visant aussi à créer un nouveau tutoriel: Rust tutorials_NG.

Liens

Sauf indication contraire, les contenus liés sont en anglais. Et il y en a un paquet.

Notes de version

Nouvelles

État d'avancement
Abandon de la pile segmentée
This week in Rust : dernières actualités sur les modifications du langage et nouveaux projets, en anglais :
- État de Rust 0.8
- 12/10/2013,
- 19/10/2013,
- De la sûreté de la pile,
- 28/10/2013,
- Plus sur la sûreté de la pile,
- 9/11/2013,
- 19/11/2013,
- 23/11/2013,
- 30/11/2013,
- 9/12/2013,
- 16/12/2013,
- 22/12/2013,
- 30/12/2013,
- 06/01/2014,
- The state of Rust 0.9.
Tweets en français sur Rust
Discussion sur l'évolution de Rust

Vous pouvez constater, en lisant les “This Week in Rust” que de plus en plus de contributeurs rejoignent le développement de Rust !

Tutoriels

Présentations sur le langage, exemples de code :

exemple de programme parallèle en Rust,
explication sur les boites et pointeurs en Rust,
interfaçage avec le code C en Rust,
présentation sur Rust lors de la ScalaIO,
présentation Nobody knows Rust,
présentation vidéo Rust, Macros, & Hygiene données lors de SoCal PLS,
un exemple d’utilisation d’une fonction C en Rust,
une présentation sympathique de Rust,
Rust for rubyists mis à jour,
types en Rust,
deux fichiers d’exemple qui, respectivement, lisent et écrivent dans un fichier,
un nouveau tutoriel en cours de rédaction,
FAQ et astuces,
article sur les différents modèles de concurrence,
comprendre les pointeurs, l’appartenance, et les durées de vie en Rust,
un compilateur juste-à-temps en Rust.

Projets

Quasar, un petit micro-noyau en Rust,
frontal Rust à GCC,
Ears, bibliothèque de lecture des fichiers audio avec OpenAL and libsndfile,
Servo, les travaux sur ACID2 continuent, le fichier de test a été rajouté, réflexions sur l'utilisation du système de revue de code Critic, utilisé par Opera,
uutils, réécriture des coreutils en Rust et multiplateforme,
RustyKext, équivalent de rust.ko pour Mac OS X.

Autres

Conclusion

Le langage approche à vitesse grand V de la version finale. La version 1.0 est prévue pour la fin de 2014, voir l'état d'avancement de la version 1, mais on en saura plus en cours d'année. Il y aura encore sûrement des changements dans la syntaxe — et dès la parution du la version 0.9, il y en a déjà, voir This week in Rust du 11 janvier — mais le langage est très proche de la complétion et il commence à y avoir suffisamment de ressources en ligne pour apprendre. Il n’y a plus d’excuses pour ne pas se mettre au Rust ! ;)

Futur (0.10)

Introduction des types à taille dynamique (Dynamically Sized Types, DST),
Suppression totale de @ (une bonne nouvelle pour les chieurs qui trouvaient que Rust avaient trop de pointeurs !),
Rajout de sucre syntaxique pour rendre l’utilisation des pointeurs de la bibliothèque standard plus simple,
Un vrai ramasse-miettes.

Aller plus loin

Site web officiel (avec tutoriel et documentation) (300 clics)
FAQ du projet (32 clics)
Notes de version (15 clics)
Notes de version détaillées (20 clics)

# Pointeurs intelligents

Posté par Aluminium95 le 21 janvier 2014 à 16:25. Évalué à 1.

Je trouve très intéressant les problématiques posées par les développeurs de Rust, mais les trois types de pointeurs, et maintenant les pointeurs intelligents … Quelles sont leurs utilisations, spécificités, lacunes ? De plus il semblerait que la gestion des pointeurs puisse encore changer, quelles sont les nouvelles idées ?

Je pense qu'un journal/dépêche dessus permettrait de partager la vision du langage sur le sujet, les changements possibles, et de récupérer pas mal de retours sur un point qui me semble crucial.
- [^] # Re: Pointeurs intelligents
  
  Posté par ariasuni le 21 janvier 2014 à 17:39. Évalué à 3.
  
  les trois types de pointeurs
  
  Bientôt plus que deux intégrés directement dans le langage, vu que le symbole @ va passer à la trappe. En gros ~ c’est quasiment exactement l’unique_ptr de C++, et & c’est pour les références (comme en C++).
  
  et maintenant les pointeurs intelligents
  
  Ce sont tous des pointeurs «intelligents». Seulement il y a eu un peu de travail sur ceux qui existaient dans la bibliothèque standard et il est maintenant recommandé d’en utiliser certains à la place des pointeurs @.
  
  De plus il semblerait que la gestion des pointeurs puisse encore changer, quelles sont les nouvelles idées ?
  
  J’ai pas l’impression, il se peut que de nouveaux pointeurs apparaissent dans la bibliothèque standard. Concernant l’utilisation, je ne sais pas comment on utilise les pointeurs qui sont censés remplacer @ mais pour le moment je sais que c’est un peu chiant à utiliser (beaucoup de boilerplate).
  
  Je pense qu'un journal/dépêche dessus permettrait de partager la vision du langage sur le sujet, les changements possibles, et de récupérer pas mal de retours sur un point qui me semble crucial.
  
  Pourquoi pas?
  
  Écrit en Bépo selon l’orthographe de 1990
# Changements de syntaxe

Posté par rewind (Mastodon) le 21 janvier 2014 à 18:12. Évalué à 9.

Il n'y a que moi qui trouve inquiétant qu'un langage qui est en développement depuis plusieurs années et qui s'approche de la version finale à grand pas soit aussi instable au niveau de sa syntaxe ? (et pas uniquement sur des détails en plus). Moi, quand on vient me dire qu'on peut commencer à tester, je fuis immédiatement, parce que je me dis que ce langage risque d'évoluer suffisamment pour que tout ce que j'apprends et je fais soit obsolète dans deux mois… Enfin, c'est l'impression que ça me donne.
- [^] # Re: Changements de syntaxe
  
  Posté par lolop (site web personnel) le 21 janvier 2014 à 18:33. Évalué à 10.
  
  Vaut peut-être mieux qu'ils nettoient maintenant encore ce qu'ils trouvent inadaptés plutôt que de se trimballer ensuite des boulets pour des raisons historiques — perso j'aurais aimé avoir directement Python3 sans passer par Python2 :-).
  
  Et, malgré les années de développements, il y a quand même précisé dans la dépêche:
  
  Note : Comme la précédente version, la version 0.9 doit être considérée comme une version alpha, adaptée pour les curieux, les pionniers et les amateurs du langage. Il y aura encore une 0.10 et probablement une 0.11.
  
  …laisse aux développeurs de Rust le soin de choisir quand ils considèrent que le projet est suffisamment cohérent et propre pour être stabilisé.
  
  Après, tu peux commencer à tester sur de petits trucs «pour voir», évaluer le ressenti que donne le langage, le côté pratique ou non, mais c'est sûr que tant que ça ne sera pas stable au minimum au niveau de la syntaxe du langage et de l'API de base, les développeurs ne vont pas se précipiter dessus pour des projets conséquents.
  
  Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
  - [^] # Re: Changements de syntaxe
    
    Posté par rewind (Mastodon) le 22 janvier 2014 à 12:27. Évalué à 2.
    
    laisse aux développeurs de Rust le soin de choisir quand ils considèrent que le projet est suffisamment cohérent et propre pour être stabilisé.
    
    On ne peut pas dire que ce n'est pas stabilisé et en même temps qu'il faut l'utiliser. Or, c'est exactement ce qui est dit à la fin :
    
    Il y aura encore sûrement des changements dans la syntaxe — et dès la parution du la version 0.9, il y en a déjà, voir This week in Rust du 11 janvier — mais le langage est très proche de la complétion et il commence à y avoir suffisamment de ressources en ligne pour apprendre. Il n’y a plus d’excuses pour ne pas se mettre au Rust ! ;)
    
    Pour moi, c'est incohérent ! Et je préfèrerais qu'ils disent : «OK, il va y avoir des changements de syntaxe importants, on va attendre d'avoir tout remanié et ensuite, on appellera à des tests et si pendant suffisamment de temps, on n'observe pas de besoin de nouveaux changements de syntaxe, on décrétera que c'est figé.»
    - [^] # Re: Changements de syntaxe
      
      Posté par Dring le 22 janvier 2014 à 14:48. Évalué à 1.
      
      Dans ce que tu cites, il est dit qu'on peut s'y mettre (ie. "commencer à apprendre"), par qu'on peut se lancer dans un projet de 10,000 jours/hommes.
- [^] # Re: Changements de syntaxe
  
  Posté par ariasuni le 21 janvier 2014 à 21:32. Évalué à 4.
  
  Regarde ~fn qui prend la syntaxe d'une fonction classique ou &fn dont da syntaxe est unifiée… Et les changements de la bibliothèque standard sont souvent des changements de nom plus qu'autre chose.
  
  Bref, à part @, les nombreux changements sont plutôt des remplacements que des réécritures. En général, les projets un peu gros utilisent la dernière révision du langage, du coup les changements sont réparties sur un temps plus long.
  
  Par rapport au nombre de changement, il y en a eu beaucoup plus que d'habitude. Maintenant que Rust commence à être un peu mûr, les développeurs réorganisent un peu tout ça — en tout cas c'est l'impression que j'ai.
  
  Une crainte qui revient régulièrement sur la liste de diffusion est que Rust soit «fixé dans la pierre» avec ses défauts. D'où la 0.10 et sans doute une 0.11. De plus, le développement est extrêmement actif, mieux vaut en profiter pour harmoniser et rendre le tout plus cohérent maintenant, quitte à avoir beaucoup de changements rébarbatifs, plutôt que d'apporter de façon incrémentielle des changements qui n'ont pas de sens en eux-mêmes — ou pire, conserver des incohérences ou des défauts.
  
  Écrit en Bépo selon l’orthographe de 1990
- [^] # Re: Changements de syntaxe
  
  Posté par Thierry Thomas (site web personnel, Mastodon) le 22 janvier 2014 à 11:01. Évalué à 1.
  On peut catégoriser les langages selon plein de critères, mais il y en a un simple que j’aime bien, et qui porte sur l’origine des spécifications.
  
  On a donc deux grosses catégories :
  - d'un coté les langages spécifiés par un organisme, un groupe de chercheurs, ou même une entreprise - peu importe - et qui finissent par être normalisés, et pour lesquels des développeurs vont s’atteler à réaliser un compilateur qui respectera autant que possible ces spécifications ;
  - et de l’autre les applications, dans le genre de Visual Basic, dont le but est de permettre la production de programmes.
  Choisis ton camp !
  - [^] # Re: Changements de syntaxe
    
    Posté par rewind (Mastodon) le 22 janvier 2014 à 12:23. Évalué à 2.
    
    Java, C, C++ sont dans la première catégorie. Python est à la limite (parce qu'il y a un processus pour normaliser). Donc, je choisis cette catégorie là. Surtout que donner Visual Basic comme exemple du second, je trouve ça particulièrement croustillant, ça donne vraiment envie !
    
    Bon, si on arrête de rigoler deux secondes, tes catégories n'ont aucune signification, il y a des bons et des mauvais langages dans les deux (sous-entendu, des langages pour faire des choses utiles). Et ce n'est absolument pas la question que je pose. Je m'étonne qu'un langage qui a déjà un historique assez long et qui est plutôt sur la voie de la finalisation soit encore si instable au niveau de sa syntaxe. Si on prend Go par exemple, il a convergé petit à petit et les changements de syntaxe ont été de moins en moins invasifs jusqu'à la version 1. Là, on change un des trucs mis en avant depuis le début !
    - [^] # Re: Changements de syntaxe
      
      Posté par ariasuni le 22 janvier 2014 à 12:27. Évalué à 2.
      
      C'est des changements de syntaxe, pas des changements de sémantique.
      
      Écrit en Bépo selon l’orthographe de 1990
      - [^] # Re: Changements de syntaxe
        
        Posté par rewind (Mastodon) le 22 janvier 2014 à 12:48. Évalué à 2.
        
        ça implique quand même de devoir réécrire tout un tas de trucs… chez Go, pour les changements de nom dans la lib standard, ils avaient développés un outil pour faire les modifications automatiquement, on en est loin là !
        
        [^] # Re: Changements de syntaxe
        
        Posté par ariasuni le 22 janvier 2014 à 14:27. Évalué à 3.
        
        Bah normalement après la 1.0 les modifications ne casseront pas la compatibilité (avant la prochaine version majeure, mais on est loin d’en être là).
        
        Écrit en Bépo selon l’orthographe de 1990
# cs4414 operating system

Posté par Thom (site web personnel) le 21 janvier 2014 à 19:47. Évalué à 4.
Merci pour la dépêche.

http://www.rust-class.org/
J'essaye de suivre ce cours qui grâce à son coup de pub a également été ouvert à des candidats libres. On y apprend vite les bases de rust 0.9 :
- http://aml3.github.io/RustTutorial/html/01.html
- http://aml3.github.io/RustTutorial/html/02.html
Lors du dernier cours, la détection de code non utilisé a été créé puis intégré à cette version 0.9.

Bref, ça n'inaugure que du bon, j'essayerai de faire un retour un peu plus tard dessus.

La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
# idées en plus ?

Posté par Nicolas Boulay (site web personnel) le 22 janvier 2014 à 14:14. Évalué à 3.

De l'expérience Lisaac et Scade, j'avais 2 propositions pour Rust, mais j'imagine que c'est un peu tard. Mais il me semble que des personnes travaillant sur Rust passe par ici.

Il me semble que Rust essaye de fonctionner avec un minimum de mémoire dynamique, un langage comme Scade/Lustre fonctionne à l'inverse des objets : ce sont les fonctions qui portent la mémoire et non l'inverse. C'est un peu comme si, en C, pour chaque appel de fonction, une mémoire était créée pour toute variable déclarée statique. Pour gérer le cas des boucles, c'est assez simple : elles n'existent pas, il y a juste des map ou des fold sur les tableaux de donnés. C'est assez extrême, cela peut augmenter la consommation mémoire, mais cela tient énormément la charge, et pour le temps réel, c'est top.

Le deuxième point, issue des réflexions autour de Lisaac, était lié à l'énorme liste de conteneur possible (binary tree ou red-black tree ?), voir de type de String (ou "buffer" ou rope) en fonction de l'usage. Un humain peut rarement savoir qu'elle est le meilleur objet à utiliser. L'idée est de laisser choisir le compilateur qui peut simplement utiliser des heuristiques (présence de boucle ou non, …), qui lui permet d'utiliser un "buffer" au lieu d'un string, si il détecte beaucoup de concaténation. Le principe technique de base serait d'utiliser une classe mère virtuelle, et le compilo se débrouille pour choisir une classe fille.

Je sais, Noël est déjà passé :)

"La première sécurité est la liberté"
- [^] # Re: idées en plus ?
  
  Posté par Thom (site web personnel) le 22 janvier 2014 à 14:50. Évalué à 2.
  
  Pour moi l’attrait principal en plus d'être dans la mouvance est clairement et simplement le côté safe.
  
  Tu ne peux pas compiler un code où tu essayes d'accéder à une même donnée en même temps par plusieurs chemins.
  
  La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
- [^] # Re: idées en plus ?
  
  Posté par ariasuni le 22 janvier 2014 à 15:06. Évalué à 2.
  
  Il me semble que Rust essaye de fonctionner avec un minimum de mémoire dynamique, un langage comme Scade/Lustre fonctionne à l'inverse des objets : ce sont les fonctions qui portent la mémoire et non l'inverse. C'est un peu comme si, en C, pour chaque appel de fonction, une mémoire était créée pour toute variable déclarée statique. Pour gérer le cas des boucles, c'est assez simple : elles n'existent pas, il y a juste des map ou des fold sur les tableaux de donnés. C'est assez extrême, cela peut augmenter la consommation mémoire, mais cela tient énormément la charge, et pour le temps réel, c'est top.
  
  Bah on peut déclarer plus de trucs sur la pile que Java ou Python, c’est sûr. ^^ Mais map et fold sont des méthodes qui existent déjà pour certains types en Rust.
  
  Le deuxième point, issue des réflexions autour de Lisaac, était lié à l'énorme liste de conteneur possible (binary tree ou red-black tree ?), voir de type de String (ou "buffer" ou rope) en fonction de l'usage. Un humain peut rarement savoir qu'elle est le meilleur objet à utiliser. L'idée est de laisser choisir le compilateur qui peut simplement utiliser des heuristiques (présence de boucle ou non, …), qui lui permet d'utiliser un "buffer" au lieu d'un string, si il détecte beaucoup de concaténation. Le principe technique de base serait d'utiliser une classe mère virtuelle, et le compilo se débrouille pour choisir une classe fille.
  
  À mon avis, c’est pas la philosophie de Rust de «modifier» ce que fais le développeur… Un comme le C++ (mais plus sûr, expressif et moderne). Tu peux toujours ouvrir une entrée sur le système de suivi de bogue de Rust.
  
  Écrit en Bépo selon l’orthographe de 1990
  - [^] # Re: idées en plus ?
    
    Posté par Nicolas Boulay (site web personnel) le 22 janvier 2014 à 15:30. Évalué à 4.
    "Bah on peut déclarer plus de trucs sur la pile que Java ou Python, c’est sûr. ^{^} Mais map et fold sont des méthodes qui existent déjà pour certains types en Rust."
    
    Le principal, c'est la mémoire static qui ne devient pas une variable global mais qui lié à chaque site d'appel de la fonction.
    
    Genre tu écris un
```
pid(e){
  static i, past_error;
  err = e-s;
  i += err;
  d = error - past_error;
  past_error = error;
  return P*e+I*i+D*d;
} //P I D étant des constantes // J'espère que le code est bon :)
```
    Dans le cas habituel, tu as une variable global pour la mémoire "i" et "past_error", si tu appelles 2 fois ce code, cela ne marche plus. Si le static fonctionne pour chaque appel et non globalement, cela marche.
    
    "À mon avis, c’est pas la philosophie de Rust de «modifier» ce que fais le développeur…"
    
    Le compilo ne modifie rien du tout. Si tu utilises un abstractString, tu demandes explicitement au compilo de choisir. Si tu colles une String, tu aura une String.
    
    "La première sécurité est la liberté"
# Ramasse miette

Posté par LupusMic (site web personnel, Mastodon) le 22 janvier 2014 à 16:54. Évalué à 2.

Rc is a reference counted pointer located in std::rc, and Gc is intended to be a garbage collected pointer, located in std::gc. Gc is currently just a wrapper around @, which is reference counted.

Donc en fait, il n'y a pas de garbage collector. Mais pourquoi s'emmerder avec un ramasse-miette alors qu'ils peuvent utiliser des pointeurs élégants ?
- [^] # Re: Ramasse miette
  
  Posté par ariasuni le 22 janvier 2014 à 17:47. Évalué à 2.
  
  Parce que dans certaines situations, c'est infiniment plus pratique (tous les cas on a besoin d'avoir plusieurs pointeurs sur les mêmes données).
  
  Écrit en Bépo selon l’orthographe de 1990
  - [^] # Re: Ramasse miette
    
    Posté par LupusMic (site web personnel, Mastodon) le 22 janvier 2014 à 18:25. Évalué à 1.
    
    Il n'y a pas besoin de ramasse-miette pour gérer ce genre de problèmes. D'ailleurs, ce n'est pas le but d'un ramasse-miette.
    - [^] # Re: Ramasse miette
      
      Posté par ariasuni le 22 janvier 2014 à 19:47. Évalué à 2.
      
      Bah des fois c’est plus performant dans certains cas que le compteur de référence non? Je ne suis pas un expert dans le domaine, mais on m’a rapporté que le pointeur @ était indispensable dans Servo (donc soit ils sont en train de migrer vers un type de pointeur de la bibliothèque standard, soit ils l’ont déjà fait).
      
      Écrit en Bépo selon l’orthographe de 1990
      - [^] # Re: Ramasse miette
        
        Posté par Nicolas Boulay (site web personnel) le 23 janvier 2014 à 09:40. Évalué à 3.
        
        Un compteur quand il y a beaucoup d'allocation/désallocation est très peu performant, car pour chaque accès à la donné le compteur est mis à jour.
        
        "La première sécurité est la liberté"
      - [^] # Re: Ramasse miette
        
        Posté par LupusMic (site web personnel, Mastodon) le 23 janvier 2014 à 11:42. Évalué à 1.
        
        Bah des fois c’est plus performant dans certains cas que le compteur de référence non?
        
        J'ai du mal, beaucoup de mal à imaginer qu'incrémenter/décrémenter un entier est moins performant que de gérer un set (ce qui semble être le type basique de gestion des arbres d'objets par un GC). Du coup, j'aimerais beaucoup un exemple concret qui démontre le bénéfice d'un GC, et surtout le bénéfice là où on en a pas besoin.
        
        Je ne suis pas un expert dans le domaine, mais on m’a rapporté que le pointeur @ était indispensable dans Servo
        
        Qu'il y ait des usages où un GC soit nécessaire, je peux l'admettre. Mon interrogation porte sur la nécessité pour toute variable allouée sur le tas d'être gérée par un coûteux GC.
        
        [^] # Re: Ramasse miette
        
        Posté par ariasuni le 23 janvier 2014 à 12:10. Évalué à 5.
        
        J'ai du mal, beaucoup de mal à imaginer qu'incrémenter/décrémenter un entier est moins performant que de gérer un set (ce qui semble être le type basique de gestion des arbres d'objets par un GC). Du coup, j'aimerais beaucoup un exemple concret qui démontre le bénéfice d'un GC, et surtout le bénéfice là où on en a pas besoin.
        
        Je ne suis pas du tout expert dans ce domaine mais cet article sur le ramasse-miettes dans D est intéressant.
        
        Qu'il y ait des usages où un GC soit nécessaire, je peux l'admettre. Mon interrogation porte sur la nécessité pour toute variable allouée sur le tas d'être gérée par un coûteux GC.
        
        En Rust, le ramasse-miettes est local par tâche (cf. le site officiel). Ça veut dire que si on en a besoin, il ne va pas arrêter complètement le programme mais seulement une partie ce qui est bien moins couteux. De plus, ça n’est pas comme en Java ou en Python, seules les données auxquelles on veut vraiment pouvoir accéder depuis plusieurs pointeurs devront être gérées, pas l’intégralité des données.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Ramasse miette
        
        Posté par barmic le 23 janvier 2014 à 14:47. Évalué à 3.
        
        De plus, ça n’est pas comme en Java ou en Python, seules les données auxquelles on veut vraiment pouvoir accéder depuis plusieurs pointeurs devront être gérées, pas l’intégralité des données.
        
        Ça le rend nettement plus rapide et ça permet d'avoir potentiellement moins de cas complexe (le graphe d'objet est plus simple, le choix des générations est aussi plus simples (si c'est un gc générationnel qui est utilisé)), etc). C'est intéressant, même si je pense qu'il vaut mieux éviter de mélanger trop dans un même programme les différentes manières pour gérer la mémoire, par soucis de simplicité et de cohérence (et de risque d'erreur).
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Ramasse miette
        
        Posté par GuieA_7 (site web personnel) le 23 janvier 2014 à 14:25. Évalué à 3.
        
        Sans parler des cas très pointus où le GC va permettre, en défragmentant le tas, d'améliorer la localité des données et ainsi améliorer les performances (parce qu'il faut quand même que cet avantage surpasse l'inconvénient qu'est l'arrêt de la tâche), un GC pallie le problème des cycles de références, qui vont engendrer des fuites mémoires même avec des pointeurs intelligents. C'est pour ça par exemple qu'avec CPython ou en PHP, il y a un GC qui s'occupe des cas problématiques (les cycles donc), même si le refcounting fait la majorité du boulot.
        
        Sinon sinma a bien répondu juste au dessus je pense, à savoir que le GC est par tâche, et ne s'occupe que des références qui le concernent, ce qui fait qu'on est loin d'un langage entièrement sous GC.
        
        Je rajouterai que:
        
        le runtime est entièrement remplaçable/supprimable : zero.rs est utilisé par les gens qui font des noyaux et enlève le runtime classique et la possibilité d'un GC.
        
        la bibliothèque standard n'utilise pas le GC (ni de refcounting je crois).
        
        Du coup la logique du "tu payes pour ce que tu utilises" est vraiment poussée loin.
# Une conf' à Paris ?

Posté par olivierweb le 24 janvier 2014 à 23:09. Évalué à -1.

Voici un message laissé sur Reddit : http://www.reddit.com/r/rust/comments/1w214e/rust_metupconferencesworkshop_in_paris/

I am a newcomer to Rust, however I really want to contribute to the language. ;)

So I want to make an Event in Paris, maybe in my school (42) or in the Mozspace. Who would like getting involved in this event?