Rust 1.0, entrée dans la période stable

Posté par  . Édité par bubar🦥, Benoît Sibaud, Anonyme, Stéphane Aulery, samdolt, RyDroid, Bruno Michel, reno, anaseto et Sylvestre Ledru. Modéré par Pierre Jarillon. Licence CC By‑SA.
Étiquettes :
54
16
mai
2015
Rust

Rust est un langage de programmation conçu pour répondre aux problématiques modernes des gros logiciels clients et serveurs utilisant Internet, en particulier la sécurité, la gestion de la mémoire et la parallélisation. Il concurrence donc directement les langages C et C++.

Logo officiel de Rust

Vendredi 15 mai 2015, trois ans et demi après la sortie de la version 0.1, Rust sort en version 1.0 ! Il y a eu beaucoup de changements depuis : le langage a très fortement évolué, une communauté de développeurs/euses s’est formée, de nombreuses bibliothèques et un guide d’apprentissage du langage ont été créés, et la documentation a été améliorée.

L’arrivée d’une version stable est un évènement bienvenu puisqu’elle permet de pouvoir utiliser le langage plus sereinement. Le langage s’ouvre donc un peu à un public plus large que l’enthousiaste et aventureuse équipe de développement de Servo ou autres pionniers/ères dans l’utilisation de Rust. Que ce soit dans des contextes personnels ou professionnels, les changements réguliers dans le langage repoussaient de nombreux/ses utilisateurs/trices potentiel·le·s.

Sommaire

Depuis plusieurs jours, nous apercevions une ombre menaçante. Ça a commencé mercredi, à ce moment-là elle était toute petite. Mais la lune apparaissait de plus en plus grande au peuple rustacé au fur et à mesure du temps qui passait, de plus en plus rapidement; au fil des jours, des heures, des minutes.

Trois jours déjà qu’elle était là. Nous nous perdions dans le regard devenu inévitable par la taille qu’occupait l’objet céleste dans notre champ de vision, semblant condamner à tout jamais le sous-Reddit à l’obscurité. Il semblait évident que quelque chose allait finir par se produire.

La première personne à mettre le sujet sur le tapis se demandait si elle était la seule à la voir. Un modérateur assurait que ça n’était « probablement rien de grave ». « citation nécessaire » répondait un·e utilisateur/trice en quête de vérité. La personne qui manipulait le CSS du site savait. Mais les autres semblait la couvrir.

La lune, menaçante

Chacun vaquait à ses occupations habituelles. Le silence de la communauté dans son ensemble par rapport à cet évènement était révélatrice de la gravité de ce qui se passait. Le silence de l’acceptation d’un destin inéluctable.

Soudain, la collision.

Telle une météorite, la lune fit beaucoup de bruit, souleva beaucoup de poussière, fit beaucoup trembler la terre. La poussière retombant peu à peu, nous commencions à découvrir l’influence de l’impact sur le paysage. Pendant un certain temps, nous peinions à ouvrir nos yeux.

La poussière retombée, nous découvrions un monde nouveau. Le thème par défaut, fade et sans gaité, s’était transformé en un magnifique habillage aux couleurs vives, accordées à celles de Rust, et pour finir un grand et magnifique logo Rust, tel un étendard.

Mais ça n’était pas fini. Nous pouvions percevoir une lumière qui semblait provenir du centre de l’impact. Tous se précipitèrent pour voir le dernier commentaire et une clameur commençait à s’élever du peuple rustacé. Publié par un développeur de Rust, il disait :

« Rust 1.0 est là !

Merci beaucoup à tous les membres de la communauté et les contributeurs/trices. Ce fut long, mais je suis vraiment fier de ce que nous avons fait ensemble.

Je vais finalement pouvoir dormir pour de vrai ce soir, je pense. »

Nouveautés

Stabilité !

L’arrivée de Rust 1.0 est une très bonne nouvelle car la stabilité est garantie. Un code écrit pour Rust 1.0 compilera avec toute version 1.x sans changements majeurs. L’engagement de l’équipe de développement de Rust n’est donc pas de garantir une stabilité absolue, mais de rendre l’effort de mise à jour du code minimal (s’il est nécessaire).

En particulier, l’équipe se réserve le droit de corriger les bogues du compilateur et les failles de sécurité ainsi que de modifier l’inférence de type d’une façon qui peut nécessiter de nouvelles annotations. Rien de bien méchant ! Plus d’informations

La grande majorité de la bibliothèque standard est maintenant stable, et il n’est plus possible d’utiliser des fonctionnalités instables avec un version stable du compilateur et un grand nombre de bibliothèques populaires fonctionnent maintenant avec la version stable.

Des chiffres !

Le dépôt rust sur Github compte plus de 42 000 commits et plus de 1 000 contributeurs/trices. Au niveau des statistiques spécifiques à Github, le projet est suivi par presque 750 personnes et a été marqué d’une étoile par plus de 10 000 personnes.

Il y a plus de 7 000 dépôts sur Github utilisant le langage Rust. Pour comparaison :

  • 1 428 dépôts lors de la sortie de la version 0.10
  • 3 262 dépôts lors de la sortie de la version 0.12
  • 4 892 dépôts lors de la sortie de la version 1.0-alpha

OpenHUB compte 200 projets en Rust, plus de 1 300 contributeurs/trices, près de 60 000 commits et plus de 1 200 000 lignes de code. Pour comparaison :

  • 121 projets lors de la sortie de la version 0.10
  • 165 projets et 1 007 386 lignes de code lors de la sortie de la version 0.12

Gouvernance ouverte

Le projet est un projet libre depuis le début et ces dernières années, ses membres ont continuellement travaillé à rendre la gouvernance du projet plus ouverte et tournée vers la communauté.

Récemment, un nouveau modèle de gouvernance a été adopté. Celui-ci établit un ensemble de sous-équipes, chacune responsable des RFC et donc l’étude et l’implémentation de fonctionnalités dans un domaine particulier.

Vous êtes bien entendu encouragé·e·s à vous impliquer, que ça soit en mettant en ligne vos bibliothèques sur crates.io, commenter les RFC ou écrire du code pour Rust.

Changements techniques

Vous êtes invité·e·s à consulter directement le journal des modifications dont une partie des changements est affichée ci-dessous.

Vous pouvez aussi consulter les entrées hebdomadaires de This week in Rust. Les changement depuis la 1.0-alpha sont répertoriés dans This week in Rust 66 et suivantes (jusqu’à la 81 qui sortira le lundi 18 mai 2015).

Vous y trouverez les listes des changements dans le compilateur et la bibliothèque standard, mais également les nouveaux/elles contributeurs/trices, les RFC approuvées et récemment créées, les nouveaux sites, articles, présentations et vidéos concernant Rust, les nouveaux projets, ainsi que les prochains évènements concernant Rust.

Quelques changements en vrac :

  • Plusieurs restrictions ont été ajoutées sur les traits pour rendre plus facile le changement de trait sans casser la compatibilité
  • L’analyse des chiffres en binaire et octal a été modifiée pour améliorer les messages d’erreurs et le comportement des macros
  • L’occultation (voir Variable shadowing pour l’explication d’un phénomène similaire) d’une durée de vie est maintenant une erreur.
  • L’utilisation de [unsafe_descructor] est maintenant déconseillée en faveur du nouveau dropck, permettant d’écrire du code beaucoup plus sûr.

Documentation, ressources & communauté

Évènements

Des rencontres Rust sont régulièrement organisées via le groupe Meetup, créé en mai 2014. Lors de ces évènements, vous pouvez assister à des conférences éclairs (Lightning talks) sur des projets concernant Rust, programmer avec d’autres enthousiastes ou simplement découvrir le langage. Le groupe compte presque 300 membres et les rencontres mensuelles regroupent généralement une trentaine de personnes.

Une release party a été organisée vendredi 15 mai à Paris pour célébrer la sortie de la première version stable de Rust. Vous pouvez également consulter la liste des release party à travers le monde.

Apprentissage

Nouvelles

Développement

La liste de discussion « rust-dev » a été arrêtée et est remplacée par le forum Rust Internals.

Entraide

Outils

rustdoc a reçu beaucoup d’améliorations, en particulier pour compléter le logiciel et pour la finition.

rustc

Cargo

Cargo est le gestionnaire de projets Rust, lui-même écrit en Rust. Il peut notamment récupérer et compiler les dépendances du projet, ainsi que compiler le projet, lancer les tests et lancer l’exécutable facilement. Le résultat est plutôt intéressant, à la fois simple et puissant.

Exemple de fichier Cargo.toml (au format TOML) :

[package]
name = "hello_world"
version = "0.1.0"
authors = ["Your Name <you@example.com>"]

[dependencies.color]
git = "https://github.com/bjz/color-rs.git"

et d’utilisation de Cargo :

$ cargo run
   Compiling color v0.1.0 (https://github.com/bjz/color-rs.git#bf739419)
   Compiling hello_world v0.1.0 (file:///path/to/project/hello_world)
     Running `target/hello_world`
[Sortie du programme]

$ cargo test
   Compiling color v0.1.0 (https://github.com/bjz/color-rs.git#bf739419)
   Compiling hello_world v0.1.0 (file:///path/to/project/hello_world)
     Running target/test/hello_world-9c2b65bbb79eabce

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured

Crates.io

Crates.io est le dépôt de conteneurs (crates, l’équivalent des bibliothèques ou paquets dans d’autres langages). Il a passé le cap du million de téléchargements et répertorie plus de 1 700 conteneurs. Le site dispose d’un guide sur l’utilisation de Cargo.

Le terrain de jeu Rust

Rust Playground est un site web qui permet de tester son code Rust en ligne. On entre le code Rust que l’on veut tester, et on obtient sa sortie en bas de l’écran. On peut choisir la version de Rust (release c’est-à-dire la dernière version publiée officiellement ou nightly, dernière version de développement).

Mais il y a d’autres options très intéressantes pour les développeurs/euses plus avancé·e·s : choisir entre le mode de compilation debug ou release, obtenir le code intermédiaire LLVM ou le code assembleur du code Rust correspondant. On peut changer le thème de l’éditeur ainsi que le jeu de raccourcis claviers (par défaut, Emacs ou vim).

L’outil est utilisé sur le canal IRC #rust sur irc.mozilla.org, via le robot playbot qu’on utilise de cette façon : playbot: println!("Hello World!"). Le robot donne alors la sortie du compilateur en cas d’erreur, sinon celle du programme; directement sur IRC ou via un lien si la sortie est trop longue.

Ferris le crabe Ferris le crabe (de la famille des rustacés), mascotte non-officielle de Rust, aime beaucoup le terrain de jeu comme vous pouvez le voir à son sourire !

Futur

RFC Rust

À l’image des PEP (Python Enhancement Proposals, propositions d’amélioration de Python), les RFC ont pour but d’offrir un moyen cohérent et contrôlé de proposer de nouvelles fonctionnalités pour Rust, permettant aux parties prenantes de comprendre et surveiller l’évolution du langage.

Pour avoir une idée des possibles futures fonctionnalités du langage, vous pouvez consulter la liste des RFC en cours de discussion.

Optimisation des appels terminaux

Fin 2013, on apprenait par un membre de l’équipe de Rust que l’optimisation des appels terminaux (tail call optimization), chère aux langages fonctionnels, ne serait pas prise en charge par Rust car trop difficile à implanter.

Pour information, lorsqu’une fonction s’appelle elle-même (appel récursif), chaque appel s’ajoute à la pile d’appel des fonctions. Celle-ci étant limitée, une fonction récursive s’appelant trop de fois provoque un dépassement de pile (stack overflow) qui fait planter le programme. Cette optimisation permet d’utiliser un espace constant dans la pile d’appels, pour peu que l’appel récursif soit terminal (c’est-à-dire la dernière instruction de la fonction). Plus d’informations

Le rapport de bug correspondant a cependant été fermé en 2014 avec l’étiquette postponed (reporté). Maintenant que 1.0 est sortie, les priorités sont différentes et cette optimisation pourrait arriver tôt ou tard dans le compilateur Rust.

Priorités après la 1.0

  • API de la bibliothèque standard :
    • API du système de fichier : le but est de l’intégrer rapidement dans Rust pour que Cargo puisse fonctionner avec une version stable de Rust.
    • API d’allocation mémoire : pouvoir allouer un tas d’octets serait très utile pour nombre de projets. Nous ne l’avons pas fait car il y a des inquiétudes quand à l’interaction avec les ramasse-miettes (voir plus bas).
    • De plus, l’équipe a pour projet de développer des bibliothèques ne faisant pas (nécessairement) partie de la bibliothèque standard mais remplissant un vide important (par exemple, un membre est intéressé par la création d’abstractions pour la programmation parallèle).
  • Meilleure prise en charge de Windows et d’ARM : Windows et ARM sont des marchés importants. Pour le premier, le but premier est de supprimer la dépendances à la chaine de compilation MingGW mais ça demande un certain travail. Pour le deuxième, la prise en charge d’ARM64 est la priorité.
  • Compilation plus rapides : beaucoup d’efforts ont été faits pour ajouter des fonctionnalités mais très peu pour optimiser. Il y a beaucoup de petites optimisations faciles mais aussi de gros gains possibles en ré-architecturant certaines parties du compilateur. Il y a par exemple du progrès à faire du côté de la compilation incrémentale et parallèle, et de l’inférence de type.
  • Rendre plus facile la distribution de bibliothèques et programmes Rust (créer une commande cargo install)
  • Intégration avec des outils externes : Rust a de bonnes informations de débogage mais ça pourrait être amélioré et ça serait bien d’avoir une intégration avec des outils de fuzzing, de couverture de code et de profilage.
  • Dynamic drop : Implantation de cette RFC le plus tôt possible pour éviter que de mauvaises pratiques de programmation se basent sur le comportement actuel
  • Allocateurs/Traçage : offrir plus de possibilités de contrôle de la mémoire (différents types d’allocateurs dans différentes parties du programme, maitrise de l’allocateur global plus simple, équivalent à malloc et free, traçage les valeurs sur la pile afin d’intégrer des ramasse-miettes par exemple lors de la liaison avec d’autres langages, etc)
  • Spécialisation : permet d’avoir plusieurs implantations d’un trait pour un ensemble de types. Il y a de nombreuses situations où la spécialisation aide à contourner les limitations de cohérence ou améliore les performances.
  • Structs virtuelles : pour certains cas d’utilisation, ça serait très pratique. Cette fonctionnalité a déjà été proposée dans le passé et l’expérience a montré que la concevoir correctement est un problème épineux.

Possiblement haute priorité :

  • Amélioration du vérificateur d’emprunt, notamment pour régler quelques problèmes faciles à contourner mais affectant beaucoup de nouveaux/elles utilisateurs/trices de Rust. Cela permettrait d’améliorer la première expérience avec Rust pour les débutant·e·s.
  • Macros et extensions de syntaxes améliorées : principalement améliorer les macros pour étendre leur champ d’application et les rendre plus puissantes. Par exemple, les macros ne peuvent pas interagir avec le système normal d’import/export du langage.

Pour un résumé plus complet, comprenant notamment les priorités à moyen et long terme, vous pouvez consulter la discussion correspondante.

Aller plus loin

  • # Coquille

    Posté par  . Évalué à 3.

    Hello,
    "s’ouvre donc à un peu public plus large" => "s’ouvre donc à un public plus large"  ?

  • # Très bonne nouvelle, je vais m'y adonner je pense

    Posté par  . Évalué à 1.

    Mais qu'en est-il de Servo ? est-il "utilisable"?

    • [^] # Re: Très bonne nouvelle, je vais m'y adonner je pense

      Posté par  . Évalué à 3.

      J'ai discuté avec quelqu'un qui bossait sur Rust chez Mozilla en Novembre dernier. Il m'avait dit que Servo était loin d'être utilisable et qu'il voyait Servo surtout comme un sujet de recherche et non comme un produit qu'il fallait sortir. Comme exemple, il m'avait montré que les dev de Servo n'utilisaient pas Servo eu même.

      Après, ma mémoire peut me faire un tour et Mozilla a peut-être changé sa décision.

      • [^] # Re: Très bonne nouvelle, je vais m'y adonner je pense

        Posté par  . Évalué à 1.

        Vu les evolutions sir firefox, il me semble normal que Servo ne soit pas encore utilisable en production (un navigateur from scratch, dans un langage qui vient d'être stabilisé, forcément, c'est jouer avec le feu :p ), mais je posais la question pour savoir si l'on peut le tester pour s'amuser.

        • [^] # Re: Très bonne nouvelle, je vais m'y adonner je pense

          Posté par  . Évalué à 4. Dernière modification le 17 mai 2015 à 06:23.

          Servo en tant que tel est pour l'instant plus un moteur de rendu web qu'un navigateur. Il n'y a pas d'UI, juste le rendu de la page web.
          D'autres projets peuvent par contre intégrer Servo et construire une interface autour: servo-shell par exemple (https://github.com/glennw/servo-shell).

          Ou, on peut aussi implémenter l'interface elle-même en HTML: browser.html (https://github.com/mozilla/browser.html).

          • [^] # Re: Très bonne nouvelle, je vais m'y adonner je pense

            Posté par  . Évalué à 0.

            Merci de ses infos. =)

            Je ne un libriste dans l'âme, mais je n'ai pas le niveau de veille technologique d'un passionné d'informatique "

          • [^] # Re: Très bonne nouvelle, je vais m'y adonner je pense

            Posté par  . Évalué à 2.

            Néanmoins, il est déjà apparemment prévu de voir certaines toutes petites parties de Gecko arriver en Rust dès cette année (second ou troisième trimestre, je ne sais plus exactement) d'après ce qu'on m'a expliqué.

            Après, refaire tout un moteur de rendu…on ne réécrit pas un truc aussi gros que Gecko en si peu de temps, et en plus sans plus évoluer.Donc voir un changement complet du moteur de rendu, oui, c'est probablement pas pour tout de suite.

      • [^] # Re: Très bonne nouvelle, je vais m'y adonner je pense

        Posté par  . Évalué à 7.

        Au début servo n'était considéré que comme un pur produit de recherche, à l'instar de browser.Html
        Mais ça.. C'était avant !
        L'équipe (d'une taille ridicule par rapport à gecko) à fait des progrès incroyable, je dirais même miraculeux !
        Servo arrive à rendre (avec parfois quelques artefacts) la majorité des sites statiques et quelques sites dynamique/complexe ! Depuis l'arrivée de l'UI (servo shell, en full html5 ça aussi c'est une révolution) je m'en sert occasionelement et franchement ça marche hyper bien ! C'est de la teleportation..
        Pour l'heure mozilla à pour projet d'intégrer peu à peu des morceaux de servo dans Firefox (nightly pour le début), ça va grandement améliorer Firefox et surtout amener beaucoup plus de devs sur servo.
        Servo sera parai il prêt à l'utilisation d'ici milieu 2016 et va écraser webkit et blink… D'ailleurs Samsung a vu la chose venir et en échange de développeurs sur servo s'est octroyé le droit de créer un nouveau navigateur pour Android utilisant servo ! (servo devrai arriver sur Firefox mobile avant pc) et il est embeedable !
        Bref je vois des jours glorieux pour Firefox à l'horizon :) et ce sans compter shumway et paralleljs (C'est le servo du JavaScript mais il est encore bien plus immature), j'espère que Google ne va pas réagir, en tout cas blink n'aura pas eu la révolution escompté et leur nouveau moteur JavaScript (turbofan ?) est actuellement extrêmement lent et bugué.

        • [^] # Re: Très bonne nouvelle, je vais m'y adonner je pense

          Posté par  (site web personnel, Mastodon) . Évalué à 6.

          Je confirme, les avancées sur Servo sont très rapides. Et maintenant que Rust 1.0 est sortie, ça va être un peu plus rapide puisqu'ils auront moins de changement de syntaxe ou autre à faire :-)

          Le blog de Servo est une mine d'information.

          L'intégration dans Firefox a commencé. Les développeurs de Servo font le maximum pour découper le moteur en lib indépendantes. Ainsi le parseur d'URL est en cours d'intégration dans Firefox. C'est une petite lib, peu importante, mais ça va permettre de poser les bases dans le build system de Firefox (builder du code Rust) et d'expérimenter l'intégration d'une lib Rust dans ce grosse base de code C++ qu'est Gecko.

          Et puis maintenant ils peuvent builder Servo pour Gonk, le linux de FirefoxOS. Ça promet !!

          • [^] # Re: Très bonne nouvelle, je vais m'y adonner je pense

            Posté par  . Évalué à -1.

            Avant de mettre du Rust dans Firefox OS, il devraient débugguer la pile réseau, mon geeksphone révolution m'affiche parfois 4 barres et la 3G alors qu'il n'a pas de réseau, j'ai été obligé de repasser sur la rom android de base :/

            • [^] # Re: Très bonne nouvelle, je vais m'y adonner je pense

              Posté par  (site web personnel, Mastodon) . Évalué à 3.

              Avant de mettre du Rust dans Firefox OS, il devraient débugguer la pile réseau, mon geeksphone révolution m'affiche parfois 4 barres et la 3G alors qu'il n'a pas de réseau,

              C'est probablement à Geeksphone qu'il faut aller te plaindre. Ils ne maintiennent pas beaucoup leurs OS, et leurs drivers sont pas tip top. Plus je met à jour mes 2 geeksphone, plus ça plante (ce qui n'est pas le cas avec mon flame par exemple).

              Et puis c'est peut être aussi juste un bug graphique. Par exemple, sur mon flame (en FxOS 2.1), la barre du haut (où est affichée l'état du réseau) n'est pas toujours à jour. Il semble en effet qu'il y ait 2 barres: une pour le desktop, et une autre pour toutes les applications. Celle du desktop est toujours ok, alors que celle affichée quand tu es dans une appli ne l'est pas toujours.

              • [^] # Re: Très bonne nouvelle, je vais m'y adonner je pense

                Posté par  . Évalué à 0.

                J'ai fouillé un peu les forums de geeksphone, et je ne suis pas le seul malheureusement. Mois qui pensait que le partenariat de mozilla avec geeksphone soit un gage de qualité, j'ai l'impression de m'être fait profondément avoir … Sous FFOS le réseau marche mal, sous cyanogenmod si l'on veut installer les gapps on ne peut plus rien installer après (un peu ironique d'ailleurs), et sur la rom "normale", il y a des bugs graphiques et de l'écran tactile qui forcent le reboot. Mozilla devrait arrêter les partenariats avec cette entreprise AMHA. :/

  • # Re: Coquille

    Posté par  . Évalué à 2.

    "L’arrivée d’une version stable est un évènement bienvenu*e*". Quant à "évènement", je ne trollerais pas mais "événement", c'est quand même plus beau (oui je sais réforme orthographique …).

    • [^] # Re: Coquille

      Posté par  (site web personnel) . Évalué à 3.

      Corrigé, merci.

    • [^] # Re: Coquille

      Posté par  . Évalué à 3.

      je ne trollerais pas mais

      Raté.

      Parce que sinon je peux aussi relever tout ce qui n’est pas écrit selon l’orthographe de 1990. Voir ici pour une liste de nouvelles orthographes acceptées, la plupart pleines de bon sens, et la beauté d’un mot c’est tellement subjectif…

      Ou alors on peut laisser couler tant que c’est valide (déjà que c’est pas facile d’innover en terme d’orthographe, si en plus on se dispute sur les écritures considérés comme valides on va pas s’en sortir).

      Écrit en Bépo selon l’orthographe de 1990

  • # «Il concurrence donc directement les langages C et C++.»

    Posté par  (Mastodon) . Évalué à 4.

    Il concurrence donc directement les langages C et C++.

    Ou pas ! Il ne faut pas se leurrer, Rust ne concurrence nullement C/C++. Et même plus, même si Rust a du succès, il ne remplacera pas C/C++ du fait de la quantité de code existant en C/C++ qui augmente de jour en jour (selon Programming Language Popularity Index qui regarde le nombre de lignes modifiées sur GitHub, il y a actuellement un facteur 100 entre C++ et Rust et 90 entre C et Rust).

    Dans un article intitulé «Criticizing the Rust Language, and Why C/C++ Will Never Die», l'auteur donne de très bons arguments. Son principal argument est de dire : si Rust se veut être rapide et sûr, il a perdu parce qu'il n'est pas assez rapide (et c'est selon l'auteur le principal avantage de C/C++), et si Rust n'est que sûr, alors il entre en concurrence avec tous les autres langages sur ce créneau mais pas C/C++. Et pour C/C++, il existe maintenant des analyseurs de toute sorte qui permettent de prévenir beaucoup d'erreurs potentielles.

    Et comme il le dit, d'autres ont essayé avant lui de concurrencer C/C++, comme D par exemple, avec le succès que l'on connaît. Donc, je modérerais franchement l'affirmation comme quoi Rust concurrence C/C++.

    • [^] # Re: «Il concurrence donc directement les langages C et C++.»

      Posté par  . Évalué à 2.

      Je crois qu'il y a un lien entre l'article que tu cites et un vendeur d'outils d'analyse C+, ça n'invalide pas forcément l'article mais bon..

    • [^] # Re: «Il concurrence donc directement les langages C et C++.»

      Posté par  (site web personnel) . Évalué à 6.

      quantité de code existant en C/C++ qui augmente de jour en jour (selon Programming Language Popularity Index qui regarde le nombre de lignes modifiées sur GitHub,

      Je connaissais pas le Programming Language Popularity Index, l'information est intéressante

      Mais… il faudrait peut être pondérer le terme "lignes de code"

      Exemple en python : 

      with open("test.dat") as f:
    data = f.read()
    print data           #ou print(data) comme vous voulez

      Le même exemple : combien de lignes en C++ ?

      il existe la même chose avec le nombre de contributeurs, de projets etc …?

    • [^] # Re: «Il concurrence donc directement les langages C et C++.»

      Posté par  . Évalué à -1.

      Si il concurrence bel et bien le c et le c++ !! Parce qu'il est ultra généraliste, son principe c'est d'utiliser toute les features des langages qui ont faut leurs preuves, c'est pour ça qu'il s'appelle rouille, c'est les vieux trucs qui marchent ! Certe le n'est pas aussi rapide qu'un c/++ mais il en a le potentiel, basé sur llvm le compilateur (rustc) est novateur et ultra paralelisé et sécurisé, leur perf approchent le c mais surtout le compilateur est hyper jeune et immature, ils ont encore une énorme marge d'amélioration de perfs et d'ici quelques années je pense qu'il pourra égaliser le c/++ (sauf si gcc devient modulaire)
      Mais rust ce n'est pas que de la perf, c'est aussi de la sécurité, rust alloue automatiquement et de manière intelligente la mémoire ce qui facilite la vie de développeur car c'est pas toujours facile (lol trop culturé), ça empêche les fuites mémoires et donc des failles en moins et de la perf en plus, la syntaxe est mieux pensée, se veut plus simple, plus facilement parallelisable, et aussi ce n'est pas qu'un langage concurrent comme le c (Je dis peu être une bêtise je m'y connais pas en type de langages) il se veut aussi fonctionnel et d'autres types dont j'ai oublié les noms. De plus, rust évolue bien plus vite que les longues périodes de standardisation du c/++.
      D'ailleurs pourquoi gcc met autant de temps à gérer les nouvelles normes alors que rustc gère en realtime les nouvelles versions du rust ?

      • [^] # Re: «Il concurrence donc directement les langages C et C++.»

        Posté par  (site web personnel) . Évalué à 2.

        c'est pour ça qu'il s'appelle rouille, c'est les vieux trucs qui marchent

        Non, ce n'est pas pour ça : http://www.reddit.com/r/rust/comments/27jvdt/internet_archaeology_the_definitive_endall_source/

        En gros, la rouille un champignon robuste, distribuée et parallèle.

      • [^] # Re: «Il concurrence donc directement les langages C et C++.»

        Posté par  (Mastodon) . Évalué à -3.

        Certe le n'est pas aussi rapide qu'un c/++ mais il en a le potentiel […] leur perf approchent le c mais surtout le compilateur est hyper jeune et immature, ils ont encore une énorme marge d'amélioration de perfs et d'ici quelques années je pense qu'il pourra égaliser le c/++ (sauf si gcc devient modulaire)

        Le potentiel, ce n'est pas une réalité. Pour l'instant, ils ont fait les optimisations faciles, mais il reste clairement le plus difficile à faire (il n'y a qu'à lire les dépêches sur LLVM ou GCC pour se rendre compte que le reste, ça va se chercher à coup de pouième). Et surtout, il pourra s'approcher du C/C++ sans le dépasser parce qu'il utilise la même technologie (LLVM) que Clang.

        rust évolue bien plus vite que les longues périodes de standardisation du c/++. D'ailleurs pourquoi gcc met autant de temps à gérer les nouvelles normes alors que rustc gère en realtime les nouvelles versions du rust ?

        Rust est un langage propriétaire qui vient d'arriver à la 1.0, C++ est standardisé depuis 20 ans bientôt. Heureusement que Rust va plus vite ! Et encore, en ce moment, il y a une version de C++ tous les 3 ans, pas mal pour un vieux ! Et GCC et Clang implémente généralement toute la norme avant qu'elle soit sortie depuis C++14.

        • [^] # Re: «Il concurrence donc directement les langages C et C++.»

          Posté par  . Évalué à 1.

          D'accord merci ! Rustc est certe basé sur la même techno, son code est plus moderne et je pense plus lisible et rearchitecturable et le langage rust est plus sécurisée et parallelisable donc ça peu aussi compenser de ce côté là en matière de perfs ! Il est déjà plus rapide que le go et le java en seulement 2 ans d'existence et ça, je trouve ça incroyable.
          Sinon rust est loin d'être propriétaire ;) il est propulsé par la fondation Mozilla !

        • [^] # Re: «Il concurrence donc directement les langages C et C++.»

          Posté par  (site web personnel) . Évalué à 10.

          Le potentiel c'est quand même important ; Javascript (ou Python/Go/Java/… peu importe) ne pourront jamais être aussi rapides (ou léger en mémoire) que C/C++, car leur sémantique les en empêchera toujours. À côté de ça, les performances de ces différents langages ont largement eu le temps de s'améliorer depuis leur 1.0  ; Go par exemple était en 1.0 il n'y a pas si longtemps, et les performances n'étaient pas terribles.

          Pour l'instant, ils ont fait les optimisations faciles

          Il reste, je crois, encore pas mal d'optimisations assez faciles (le code de rustc n'étant pas forcément génial), le plus important ayant été de stabiliser la sémantique du langage, afin de s'assurer par exemple que les évolutions futures soient réalisables sans tout casser. En effet le concept des références/temps de vie est différent de ce qu'on connaît ailleurs, et nécessite souvent de concevoir son code de manière différente ; il était important que cette nouvelle approche ne soit pas globalement une régression.

          Il n'y a pas si longtemps par exemple un simple 'Hello world' en Rust prenait plusieurs Mo (car il embarquait toute la lib standard, un truc comme ça).

          Évidemment aller chercher le potentiel demandera du temps et des ressources, et rien ne garanti qu'il sera atteint un jour. Les résultats actuels sont déjà très intéressants, on peut donc faire preuve d'un certain optimisme !

          Et surtout, il pourra s'approcher du C/C++ sans le dépasser parce qu'il utilise la même technologie (LLVM) que Clang.

          Pas forcément. Au alentours de la 0.7, je me rappelle que rustc était déjà capable dans certains cas d’émettre des informations d'aliasing pour LLVM (et qui permettent des optimisations), et qui ne pouvaient pas être émises par du code C++ (le langage n'ayant pas la sémantique adéquate).

        • [^] # Re: «Il concurrence donc directement les langages C et C++.»

          Posté par  . Évalué à 5.

          Et surtout, il pourra s'approcher du C/C++ sans le dépasser parce qu'il utilise la même technologie (LLVM) que Clang.

          Hein ?! Déjà considérer de la même façon le C et le C++ n'est pas génial, mais ce n'est pas vrai. Je ne sais pas pour rust en particulier, mais le fait d'avoir des vérifications à la compilation qui ne sont donc plus nécessaires au runtime permet de gagner pas mal de performance (il suffit de voir ce que fait ocaml pour le voir). L'expressivité peut permettre d'implémenter plus facilement des optimisations (des SIMD plus faciles à détecter par exemple).

          Et le surtout, c'est bien d'avoir des du code hyper performant sur un cœur, mais entre un code 10% plus performant sur un cœur et un code qui sait mieux utiliser du parallélisme (avec par exemple l'équivalent d'un OpenMP directement au sein du langage et l'utilisation massive de données immutables). Mon choix est très vite fait.

          La performance ce n'est pas juste avoir une compilation source -> binaire éfficace, c'est aussi avoir des API ou des mécanismes du langage qui permettent le parallélisme.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: «Il concurrence donc directement les langages C et C++.»

      Posté par  . Évalué à 10. Dernière modification le 17 mai 2015 à 13:49.

      Ou pas ! Il ne faut pas se leurrer, Rust ne concurrence nullement C/C++.

      Concurrence: «Fait de se trouver en opposition, le plus souvent d'intérêt dans la poursuite d'un même but, chacun visant à supplanter son rival.»

      À partir du moment ou Rust existe et peut remplacer C/C++ dans plusieurs cas d’usages ils sont en concurrence.

      Et même plus, même si Rust a du succès, il ne remplacera pas C/C++ du fait de la quantité de code existant en C/C++ qui augmente de jour en jour (selon Programming Language Popularity Index qui regarde le nombre de lignes modifiées sur GitHub, il y a actuellement un facteur 100 entre C++ et Rust et 90 entre C et Rust).

      Incroyable, le jour de la sortie de la version 1.0 de Rust il y a énormément moins de code Rust que de code de langages ayant 30 ou 40 ans. ;)

      Dans un article intitulé «Criticizing the Rust Language, and Why C/C++ Will Never Die»

      Lis donc ce qu’on en pense sur /r/rust. Pas que du bien apparemment. En tout c’est intéressant d’avoir un autre point de vue.

      D’autre part, C et C++ ne mourront jamais, et alors? Java n’a pas remplacé C et C++, ça ne l’a pas empêché d’être un succès parce qu’il a des atouts que les précédents n’ont pas. C’est la même chose avec Rust, surtout qu’il reste encore beaucoup à améliorer.

      Et comme il le dit, d'autres ont essayé avant lui de concurrencer C/C++, comme D par exemple, avec le succès que l'on connaît.

      Rust et D sont complètement différents. Les deux langages sont complètement différents. D comporte beaucoup de fonctionnalités et n’est pas spécialement focalisé sur la sureté, et fonctionne.

      Plusieurs gros logiciels en Rust existent: le compilateur rustc, Cargo, Servo. En D, le compilateur officiel est même pas écrit en D. Depuis le début tout le projet Rust est publié sous licence libre alors que ça n’a longtemps pas été le cas pour D (notamment le compilateur officiel), et il y a une division de la communauté entre la bibliothèque standard officielle et celle de la communauté. Mozilla paye des gens pour bosser sur Rust et sur Servo (ce dernier étant également financé par Samsung).

      Écrit en Bépo selon l’orthographe de 1990

      • [^] # Re: «Il concurrence donc directement les langages C et C++.»

        Posté par  (Mastodon) . Évalué à -2.

        À partir du moment ou Rust existe et peut remplacer C/C++ dans plusieurs cas d’usages ils sont en concurrence.

        Si je commence à écrire un système d'exploitation, je suis un concurrent de Linux et Windows ? Non, je ne crois pas. Si je le dis comme ça, tout le monde va bien rigoler.

        Incroyable, le jour de la sortie de la version 1.0 de Rust il y a énormément moins de code Rust que de code de langages ayant 30 ou 40 ans. ;)

        L'âge n'a rien à voir. COBOL a 40 fois moins de lignes modifiées que Rust, c'est justement l'argument : C/C++ sont encore des langages très actifs (et pour une bonne raison) !

        Lis donc ce qu’on en pense sur /r/rust. Pas que du bien apparemment. En tout c’est intéressant d’avoir un autre point de vue.

        Ce n'est pas étonnant qu'ils ne soient pas d'accord. C'est un point de vue aussi partial que celui de l'article.

        D’autre part, C et C++ ne mourront jamais, et alors? Java n’a pas remplacé C et C++, ça ne l’a pas empêché d’être un succès parce qu’il a des atouts que les précédents n’ont pas. C’est la même chose avec Rust, surtout qu’il reste encore beaucoup à améliorer.

        Java n'est pas du tout sur le même segment que C/C++. Il y avait un manque qui a été comblé. Rust comble quel manque en terme de marché ? Aucun.

        Plusieurs gros logiciels en Rust existent: le compilateur rustc, Cargo, Servo.

        Gros, c'est vite dit si on compare aux plus gros mastodontes en C/C++ (comme Firefox par exemple pour rester dans la même maison). C/C++ sont utilisés dans beaucoup de domaines de l'industrie, des plus petits microcontrolleurs jusqu'aux très grosses applis sur mainframe.

        • [^] # Re: «Il concurrence donc directement les langages C et C++.»

          Posté par  . Évalué à 4.

          "Si je commence à écrire un système d'exploitation, je suis un concurrent de Linux et Windows ? Non, je ne crois pas. Si je le dis comme ça, tout le monde va bien rigoler."
          Bah s'il est supérieur techniquement on va pas te rire au nez, (par exemple le futur carbon de hp) c'est juste que c'est impossible, en l'occurrence rust est en beaucoup de points supérieur au C/ ++

          "C/C++ sont encore des langages très actifs (et pour une bonne raison) !"
          Personne ne te dira le contraire :) mais rust étant ultra jeune, je trouve le nombre de projets dessus assez impressionnant (hématite à l'air génial)

          "Java n'est pas du tout sur le même segment que C/C++. Il y avait un manque qui a été comblé. Rust comble quel manque en terme de marché ? Aucun."
          Bah si moderniser le C++, le rendre plus sécurisé, améliorer la syntaxe, lui ajouter de nouveaux types (Je m'y connais pas mais je crois que son principal avantages soit qu'il soit multi-paradigme, il est impératif, objet, fonctionnel et concurrent !)
          C'est aussi le premier langage à se mettre à jour aussi rapidement, on dirait presque une rolling release ^
          Et aussi et surtout c'est un langage ultra ouvert qui commence à générer une énorme communauté et tout le monde peut participer à son développement ! Et l'on a l'appui de mozilla et Samsung.
          Bref ce langage aujourd'hui n'est pas une révolution il est "juste" une alternative crédible au c++ mais il a un potentiel d'amélioration qu'aucun langage à ma connaissance n'a jamais eu !

          • [^] # Re: «Il concurrence donc directement les langages C et C++.»

            Posté par  (Mastodon) . Évalué à 1.

            Bah si moderniser le C++, le rendre plus sécurisé, améliorer la syntaxe, lui ajouter de nouveaux types (Je m'y connais pas mais je crois que son principal avantages soit qu'il soit multi-paradigme, il est impératif, objet, fonctionnel et concurrent !)

            Pour moderniser C++, il y a des gens qui travaillent au prochain standard C++, ils ne travaillent pas sur Rust. Et C++ est multi-paradigme également (c'est même un reproche qu'on lui fait souvent).

            Bref ce langage aujourd'hui n'est pas une révolution il est "juste" une alternative crédible au c++ mais il a un potentiel d'amélioration qu'aucun langage à ma connaissance n'a jamais eu !

            On en reparle dans 10 ans. D'ici là, toute spéculation sur une «alternative crédible» et sur un «potentiel d'amélioration» est prématurée. Je pense que si on remonte en arrière, beaucoup de gens aussi enthousiaste que toi disait ça de D.

        • [^] # Re: «Il concurrence donc directement les langages C et C++.»

          Posté par  . Évalué à 10.

          Rust comble quel manque en terme de marché ? Aucun.

          Celui d'étoffer l'offre des langages modernes, qui ne s'exécutent pas dans une VM (Java, Python, Ruby, Javascript, C#, …) et qui soient pas morts nés (comme le D) sans être soit du C, soit du C++, soit du Go. Déjà ça, c'est pas mal je trouve…

          A part ça, si on a "perdu" son temps à inventer des langages idiots comme Ook ou Brainfuck, je crois que la MoFo a le droit de "perdre" son temps à sortir un langage un minimum sérieux. C'est pas interdit par rewind, j'espère ?

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Re: «Il concurrence donc directement les langages C et C++.»

            Posté par  (Mastodon) . Évalué à 2.

            C'est pas interdit par rewind, j'espère ?

            Où est-ce que tu as vu que j'interdisais quoi que ce soit à quelqu'un ? Ils ont le droit de claquer leur fric comme ils veulent. Je remets simplement en cause le fait qu'à l'heure actuelle, ce serait un concurrent à C/C++ comme il est dit dans la news. C'est pas interdit par xcomcmdr, j'espère ?

            • [^] # Re: «Il concurrence donc directement les langages C et C++.»

              Posté par  . Évalué à 10. Dernière modification le 17 mai 2015 à 19:34.

              Je remets simplement en cause le fait qu'à l'heure actuelle, ce serait un concurrent à C/C++ comme il est dit dans la news. C'est pas interdit par xcomcmdr, j'espère ?

              Ce que tu as du mal à comprendre, c'est que Rust peut être un concurrent au C et à C++ sans être C++ lui-même.

              Rien qu'en étant un langage qui se prête bien au bas-niveau, il opère sur le même segment, et est de fait un concurrent. Mais un concurrent à quelque chose, ce n'est pas forcément la même chose sous un autre nom !

              Bref, si pour toi un concurrent doit avoir en tout point la même popularité, et les mêmes fonctionnalités / propriétés , on n'a pas la même notion de concurrent…

              Tu crois que le C++ s'est fait en un jour ?

              Imagine ta réaction le jour où C++ sortait, tu disais la même chose en défendant le C ?

              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

        • [^] # Re: «Il concurrence donc directement les langages C et C++.»

          Posté par  (site web personnel) . Évalué à 3.

          L'âge n'a rien à voir. COBOL a 40 fois moins de lignes modifiées que Rust, c'est justement l'argument : C/C++ sont encore des langages très actifs (et pour une bonne raison) !

          En lisant tes commentaires, on peut facilement inférer que tu serais près à déduire la qualité d'un langage par sa popularité. Si c'est le cas, je te conseille de lire L’Art d’avoir toujours raison de A. Schopenhauer, stratagème XXX pour bien que tu comprennes que ton argument d'autorité qui est la citation du Programming Language Popularity Index reste une vision bien trop simpliste pour juger de la qualité d'un langage comme le souligne d'ailleurs Christophe B.. Et il est certains que le C et le C++ ne sont LES langages d'hier, d'aujourd'hui et de demain car le monde serait non seulement bien triste et dangereux avec tous ces segfault mais qu'il existe (heureusement) beaucoup d'autres solutions qui ont, eux aussi, des qualités et des défauts. Bref, Rust a autant sa place dans le panel des langages informatiques utilisable comme l'a le C, le COBOL, le Python et l'ATS.

          Java n'est pas du tout sur le même segment que C/C++. Il y avait un manque qui a été comblé. Rust comble quel manque en terme de marché ? Aucun.

          C'est malheureusement là où je ne serais pas tout aussi catégorique que tu ne l'es et nous avons déjà partagé un tel débat ensemble. Je vais pas faire le perroquet ici mais Rust détient une part du marché. Après, est ce que les moyens observés sur Rust conviennent à l'importance du secteur ? Est ce qu'il ne fallait pas plutôt travailler sur l'existant ? Est ce que le bruit est à la hauteur de l'impact hypothétique qu'aura Rust dans l'industrie ? C'est là qu'il y a un débat, et c'est ici que nous ne sommes pas d'accord. Mais Rust convient à des problématiques pour lesquelles le C ou le C++ ne conviennent pas, il appartient donc à un marché (d'une importance relative) qui ne semble pas être sous le joug d'un langage semblable.

          Par contre, et là je te rejoins, il est vrai que Rust ne supplantera pas le C ou le C++ et c'est, je pense, ce qu'a voulu dire sinma d'une manière un peu implicite. C'est une erreur courante qui peut, certes, embêter (comme quand on m'embête en me disant qu'OCaml, c'est naze à cause du (+.)) mais qui n'enlève rien - si on s'y intéresse - au fond de ce que peut être Rust.

          • [^] # Re: «Il concurrence donc directement les langages C et C++.»

            Posté par  (Mastodon) . Évalué à -2.

            En lisant tes commentaires, on peut facilement inférer que tu serais près à déduire la qualité d'un langage par sa popularité.

            Non, je ne mesure pas la qualité mais l'activité.

            Et il est certains que le C et le C++ ne sont LES langages d'hier, d'aujourd'hui et de demain car le monde serait non seulement bien triste et dangereux avec tous ces segfault mais qu'il existe (heureusement) beaucoup d'autres solutions qui ont, eux aussi, des qualités et des défauts. Bref, Rust a autant sa place dans le panel des langages informatiques utilisable comme l'a le C, le COBOL, le Python et l'ATS.

            Où est-ce que j'ai dit une telle chose ? J'ai simplement dit que Rust ne sera pas un C/C++ killer, point. Il a le droit d'exister, il fera peut-être une belle carrière, mais il ne supplantera jamais C/C++. Il y a des raisons assez objectives dont on peut discuter mais apparemment, ça n'intéresse personne dans ce thread. Par exemple, le fait que Rust soit plus sûr que C/C++ est un fait, mais ce n'est vraiment pas ça qui fera que Rust remplacera C++ dans plein d'utilisations aujourd'hui.

            Mais Rust convient à des problématiques pour lesquelles le C ou le C++ ne conviennent pas, il appartient donc à un marché (d'une importance relative) qui ne semble pas être sous le joug d'un langage semblable.

            Nous sommes d'accord. Donc pourquoi vouloir sans cesse comparer Rust à C/C++ ? Ce n'est pas moi hein, c'est le premier paragraphe de la news ! S'ils ne sont pas sur la même cible, alors ça ne sert à rien de les comparer.

            • [^] # Re: «Il concurrence donc directement les langages C et C++.»

              Posté par  . Évalué à 2. Dernière modification le 17 mai 2015 à 19:47.

              Où est-ce que j'ai dit une telle chose ? J'ai simplement dit que Rust ne sera pas un C/C++ killer, point. Il a le droit d'exister, il fera peut-être une belle carrière, mais il ne supplantera jamais C/C++. Il y a des raisons assez objectives dont on peut discuter mais apparemment, ça n'intéresse personne dans ce thread

              Tu connais l'avenir ?

              Et où est il écrit que concurrent = supplanter ?!

              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

              • [^] # Re: «Il concurrence donc directement les langages C et C++.»

                Posté par  (Mastodon) . Évalué à -5.

                Même sans parler de supplanter, l'envergure de Rust pour l'instant n'est pas très grande, et c'est un euphémisme. Quand on aura un noyau, un jeu AAA, une suite office, un serveur graphique, un environnement de bureau en Rust, là oui on pourra commencer à considérer que Rust a fait ses preuves et rivalise avec C/C++.

        • [^] # Re: «Il concurrence donc directement les langages C et C++.»

          Posté par  . Évalué à 5.

          Java n'est pas du tout sur le même segment que C/C++. Il y avait un manque qui a été comblé. Rust comble quel manque en terme de marché ? Aucun.

          Faux, on a clairement un trou dans le segment de marché correspondant à un langage de programmation avec des garanties de sureté (permettant de garantir l’absence de faille de sécurité type buffer-overflow et autre), orienté système (compilation native, runtime petit et pas de garbage-collector) et permettant de faire des abstractions "zero-cost" (voir la définition de Bjarne Stroustrup).

          En client de ce segment de marché on peut facilement trouver pas mal de monde, qui d'ailleurs utilisent majoritairement et actuellement C++. Par exemple, l'écriture de moteur de jeux video, les appli grand publique genre navigateur web, tout ceux qui font de l'embarqué (d'autant plus avec des contraintes temps réel).

          Et il n'y a aucun langage existant (à ma connaissance) qui permette de garantir la sureté de l'utilisation mémoire en présence d'allocation sur le tas (sans garbage collector, évidement). Par exemple, ni C++, ni Ada, ni D, ni Go ne le permettent (dans le cas de figure général évidement).

          L'autre propriété innovante de Rust, c'est de garantir l’absence de data-race dans la programmation multi-threadé. Les seuls autres langages permettant de faire (à ma connaissance) sont dans le genre de Erlang ou Haskell et pour le coup ce sont des langages avec un gros runtime (voir une machine virtuelle) et laissant très peu de contrôle sur le programme compilé.

          • [^] # Re: «Il concurrence donc directement les langages C et C++.»

            Posté par  (Mastodon) . Évalué à 2.

            Par exemple, l'écriture de moteur de jeux video

            Raté ! Les moteurs de jeux vidéos ont besoin de pouvoir aller jusque dans les entrailles du système, en particulier sur le point sensible de l'allocation mémoire. Quasiment tous les jeux modernes utilisent plusieurs allocateurs mémoire maison pour optimiser l'utilisation de la mémoire. Juste ce point fait que Rust n'est pas un candidat pour un jeu vidéo d'envergure. Je te renvoie par exemple à la présentation Parallelizing the Naughty Dog Engine Using Fibers où l'orateur montre les modifications qui ont été faite pour la version Remastered de The Last of Us, en particulier sur la mémoire (dans la deuxième partie de la présentation). Je doute très fortement que tout ça soit possible à faire avec Rust.

          • [^] # Re: «Il concurrence donc directement les langages C et C++.»

            Posté par  . Évalué à 5.

            Et il n'y a aucun langage existant (à ma connaissance) qui permette de garantir la sureté de l'utilisation mémoire en présence d'allocation sur le tas (sans garbage collector, évidement). Par exemple, ni C++, ni Ada, ni D, ni Go ne le permettent (dans le cas de figure général évidement).

            Ada apporte quand même pas mal de garantie à ce niveau-là (grâce aux vérifications d'accessibilités). Bon c’est peut-être pas aussi poussé que Rust (car pas basé sur le même mécanisme) mais ça élimine déjà une grosse majorité des problèmes.

          • [^] # Re: «Il concurrence donc directement les langages C et C++.»

            Posté par  . Évalué à 4.

            Faux, on a clairement un trou dans le segment de marché correspondant à un langage de programmation avec des garanties de sureté (permettant de garantir l’absence de faille de sécurité type buffer-overflow et autre), orienté système (compilation native, runtime petit et pas de garbage-collector) et permettant de faire des abstractions "zero-cost" (voir la définition de Bjarne Stroustrup).

            En fait il y en a pas mal, par exemple ATS ou feu BitC. Le premier est développé et permet de faire pas mal de choses, avec notamment des formes de types dépendants et preuve formelle (qui n’existent pas en Rust), mais il évolue lentement et a quelques lourdeurs (notamment en duplication de code).

            • [^] # Re: «Il concurrence donc directement les langages C et C++.»

              Posté par  . Évalué à 2.

              Oui clairement il y a des langages plus sûrs que Rust, car un des mots d'ordre de Rust est la praticité.

              Écrit en Bépo selon l’orthographe de 1990

            • [^] # Re: «Il concurrence donc directement les langages C et C++.»

              Posté par  . Évalué à 5.

              Oui alors je me restreignais aux langages avec un minimum de diffusion :)

              Quitte à en citer un, je citerai Cyclone qui est apparemment celui qui a servi de modèle à Rust pour la partie "borrowing system" (sachant qu'on appelle ça aussi de la "region analysis" ou des affine type). Et sachant aussi qu'ils ont enrichi ce qu'il se faisait.

              Après le langage avec des types dépendants, c'est très bien mais ce n'est pas décidable. Donc c'est un "type" dans l'acceptation des système de démonstration formel comme Coq. En programmation on considère plutôt qu'un type doit être pris en charge complètement par le typecheck du compilateur. Donc j'aurai tendance à dire que ce ne sont pas de langage de programmation mais de preuve. Après moi je suis pour qu'on fasse des preuves de programmes :) mais si on pouvait déjà juste dégager les buffer overflow et autres failles de nos programmes en utilisant des langages comme Rust, ça serait déjà pas mal !

          • [^] # Re: «Il concurrence donc directement les langages C et C++.»

            Posté par  . Évalué à -2.

            Je tiens juste à préciser que Rust à un garbage collector, mais ce qu'il a d'innovant c'est qu'il est optionnel.

            • [^] # Re: «Il concurrence donc directement les langages C et C++.»

              Posté par  . Évalué à 4.

              Je crois me souvenir qu'il a été retiré il y a quelques versions et que ce n'est que du comptage de référence qui est dispo actuellement, mais que ça voulait le réintroduire plus tard (surtout qu'une des priorité maintenant est de bosser sur le traçage des allocations etc).

              Écrit en Bépo selon l’orthographe de 1990

      • [^] # Re: «Il concurrence donc directement les langages C et C++.»

        Posté par  . Évalué à 5.

        Concurrence: «Fait de se trouver en opposition, le plus souvent d'intérêt dans la poursuite d'un même but, chacun visant à supplanter son rival.»

        Ce qui est dommage dans cette définition et qui peut pousser certains à se sentir comme menacés, à défendre leur langage, c'est le « visant à supplanter son rival ». Je ne vois pas pourquoi il faut se focaliser sur ce point, c'est plutôt malsain comme objectif. L'idée c'est plutôt « offrir une autre expérience ». S'ils poursuivent un même but mais de façon différente, c'est que du coup on a un choix intéressant à faire ; et c'est ça qui est bien, pas que l'un remplace l'autre : à chacun de choisir ce qu'il utilise, ce qui compte c'est que chacun trouve son bonheur. Après, certains n'aiment tout simplement pas qu'il y ait du choix, mais c'est une autre histoire.

        • [^] # Re: «Il concurrence donc directement les langages C et C++.»

          Posté par  . Évalué à 4.

          J'interprétais ça de la façon suivante: pour un certain nombre de projets, Rust peut supplanter C++ comme choix de langage, et pas d'une manière globale.

          Ça reste un terme difficile à définir dont la définition que j'ai donnée est imparfaite.

          Écrit en Bépo selon l’orthographe de 1990

    • [^] # Re: «Il concurrence donc directement les langages C et C++.»

      Posté par  . Évalué à 3.

      Depuis le début de la discussion, tu ne semble pas apprécier Rust, serais-tu un développeur C++ inquiet ?
      sinma t'as très bien répondu selon moi.

      Si je commence à écrire un système d'exploitation, je suis un concurrent de Linux et Windows ? Non, je ne crois pas. Si je le dis comme ça, tout le monde va bien rigoler.

      Il y a une différence entre commencer un projet et proposer une version stable de ce projet. Tu te place dans le premier cas, alors que Rust est dans le deuxième. Bien qu'il soit jeune, il n'empêche pas d'être un concurrent à C++, alors même qu'il n'est pas (encore ?) très utilisé. Si on dit "Rust sera [à terme/bientôt/à l'avenir] un concurrent à C++", cela te convient mieux ? Considères-tu l'environnement (bibliothèque, documentation, communauté) du langage comme en faisant partie ? Si oui, est-ce ce point qui te fais dire que Rust n'est pas un concurrent de C++ ? Cela serait légitime, mais probablement pas dans les mois/années à venir.

      L'âge n'a rien à voir. COBOL a 40 fois moins de lignes modifiées que Rust, c'est justement l'argument : C/C++ sont encore des langages très actifs (et pour une bonne raison) !

      Deux langages concurrents très actifs sur la même période, c'est impossible selon toi ?

      Gros, c'est vite dit si on compare aux plus gros mastodontes en C/C++ (comme Firefox par exemple pour rester dans la même maison). C/C++ sont utilisés dans beaucoup de domaines de l'industrie, des plus petits microcontrolleurs jusqu'aux très grosses applis sur mainframe.

      sinma t'indiqué que Rust est déjà utilisé par d'autres logiciels et qu'il n'est pas seulement qu'un projet de recherche seul avec lui-même.

      Et dans un de tes précédents commentaire :

      si Rust se veut être rapide et sûr, il a perdu parce [quelqu'un le pense], et si Rust n'est que sûr,

      Sinon, en admettant qu'un projet ne possède pas les avantages qu'il met en avant et en pratique, c'est facile de descendre n'importe quel projet.

      • [^] # Re: «Il concurrence donc directement les langages C et C++.»

        Posté par  (Mastodon) . Évalué à -2.

        Depuis le début de la discussion, tu ne semble pas apprécier Rust, serais-tu un développeur C++ inquiet ?

        C'est pas que je n'apprécie pas Rust, au mieux ça m'indiffère pour l'instant, je regarde ça de loin. Ce qui m'énerve, c'est qu'on n'arrête pas de comparer Rust à C/C++ alors que ça n'a à peu près rien à voir. Qu'on compare Rust à Go, par exemple, me semble bien plus pertinent. Mais bizarrement, ça n'est jamais fait. Au moins, les développeurs de Go, ils sont conscients, ils ont une vraie vision du marché et ils s'aperçoivent bien que le gros des développeurs Go, ce ne sont pas des développeurs C/C++, mais des développeurs Python/Ruby. Qu'est-ce qui fait dire à Mozilla que Rust va attirer les développeurs C/C++ ? Vu comment les développeurs C/C++ sont traités chaque fois qu'ils critiquent Rust, j'ai envie de dire que c'est mal barré.

        Deux langages concurrents très actifs sur la même période, c'est impossible selon toi ?

        On ne vit pas dans un monde romantique où chaque langage viendrait présenter ses avantages et où on choisirait le meilleur. L'industrie ne peut pas se permettre deux concurrents, et souvent, l'un des deux meurt. Ou alors trouve sa niche mais dans ces cas là, ils ne sont plus concurrents, chacun vit sa vie de son côté.

        • [^] # Re: «Il concurrence donc directement les langages C et C++.»

          Posté par  . Évalué à 5.

          Il y a pourtant pas de quoi s'énerver.

        • [^] # Re: «Il concurrence donc directement les langages C et C++.»

          Posté par  (site web personnel) . Évalué à 4.

          Qu'on compare Rust à Go, par exemple, me semble bien plus pertinent. Mais bizarrement, ça n'est jamais fait.

          Dans mon journal sur la version 0.7 je comparais déjà Rust à Go (et j'expliquais en quoi ces langages sont très différents sur bien des plans).

          À côté de ça Rust a vraiment une philosophie proche de C++ ("What you don’t use, you don’t pay for") ; par exemple voir ici une explication très intéressante sur les traits.

          Et sur le reddit de Rust, les clashes avec Go et C++ sont tous les deux très courants.

          Au moins, les développeurs de Go, ils sont conscients, ils ont une vraie vision du marché et ils s'aperçoivent bien que le gros des développeurs Go, ce ne sont pas des développeurs C/C++, mais des développeurs Python/Ruby.

          Mouais ils ont écrit Go pour leur propre usage (comme Mozilla), et au bout d'un certain temps à essayer de le 'vendre' aux développeurs C++ se sont aperçus que c'est plutôt les dev Python/Ruby que ça intéressait ; ce n'est pas une critique en soit, mais de là en faire des génies du marketing… Bien des réussites de l'industrie étaient complètement inattendues, et aujourd'hui mis à part les géants que sont Microsoft (avec C#) ou Apple (avec Objective-C et Swift), aucune entreprise n'est capable d'imposer un langage ; les autres ben ils essaient de faire de leur mieux et parfois c'est un succès. Mais bon on peut aussi dire que C++ c'est le mieux que pourra faire l'humanité et donc on arrête de chercher tout de suite.

          L'industrie ne peut pas se permettre deux concurrents, et souvent, l'un des deux meurt. Ou alors trouve sa niche mais dans ces cas là, ils ne sont plus concurrents, chacun vit sa vie de son côté.

          C'est vrai, quelques langages se taillent la part du lion, et les autres se retrouvent bien souvent à vivoter (au mieux). D'un autre côté on a aussi les couples C#/Java et Python/Ruby, dans lesquelles des langages quand même très proches évoluent en parallèle (restant concurrents) et ont tous des communautés suffisamment dynamiques pour trouver un peu tout ce qu'on veut en terme de bibliothèques.

          • [^] # Re: «Il concurrence donc directement les langages C et C++.»

            Posté par  (Mastodon) . Évalué à 1.

            Mais bon on peut aussi dire que C++ c'est le mieux que pourra faire l'humanité et donc on arrête de chercher tout de suite.

            C++ évolue encore (et pas qu'un peu), il n'est pas figé dans le marbre jusqu'à la nuit des temps.

            • [^] # Re: «Il concurrence donc directement les langages C et C++.»

              Posté par  (site web personnel) . Évalué à 8.

              Je n'ai jamais prétendu le contraire ; C++ évolue sans casser la compatibilité et c'est très bien au vue du nombre de logiciels écrits en C++. Mais du coup C++ se traînera toujours certains boulets, malgré toutes ses évolutions.

              Rust apporte une solution à bon nombre de ces boulets ; ça ne veut pas dire qu'il est parfait. On peut même être sûr que s'il est toujours utilisé dans 30 ans (ce qui n'est pas gagné encore une fois), on aura largement eu le temps de lui déceler des tas de boulet à lui aussi.

              Après tu as tout à fait le droit de douter de l'intérêt de Rust. Mais les arguments à base de "C++ c'est utilisé depuis 30 ans dans des millions de logiciels nananère" ne sont pas franchement très intéressants. Oui c'est vrai la popularité de C++ est un avantage sur tous pleins d'aspects ; mais bon ici on est sur linuxfr, on en connaît plein des logiciels géniaux qui ne sont pas hyper connus, mais qui arrivent à vivre depuis longtemps (tout le monde ici connaît Blender , pourtant c'est loin d'être le cas de tous les graphistes).

              Je n'ai vu personne sur le thread dire qu'il fallait réécrire tous les logiciels C++ en Rust ; et pour une bonne raison c'est que ça serait stupide. En revanche pour un nouveau logiciel (et des logiciels libres qui manquent ben y en a des tas), cela peut être un choix intéressant.

              En fait depuis le début j'ai l'impression que quand les gens écrivent "Rust est peut-être le C++ du futur", tu lis "le C++ c'est de la merde, et les devs C++ sont des idiots" : ce n'est absolument pas le cas ! Les créateurs de Rust ont beaucoup pratiqué le C++, l'aiment et suivent de près ses évolutions ; ils sont confrontés aux mêmes problèmes, et les solutions du C++ sont très réfléchies.

              • [^] # Re: «Il concurrence donc directement les langages C et C++.»

                Posté par  (site web personnel) . Évalué à 5.

                C++ évolue sans casser la compatibilité

                Il est tout a fait possible d'enlever des anciennes fonctionnalités à des langages. Cela se fait via des annonces d'obsolescence dans une norme avant de l'enlever effectivement dans la norme suivante (si aucun biais n'a été trouvé entre temps). C'est ainsi que fait par exemple Fortran qui est toujours là malgré son grand âge…

              • [^] # Re: «Il concurrence donc directement les langages C et C++.»

                Posté par  (Mastodon) . Évalué à -1.

                En fait depuis le début j'ai l'impression que quand les gens écrivent "Rust est peut-être le C++ du futur", tu lis "le C++ c'est de la merde, et les devs C++ sont des idiots" : ce n'est absolument pas le cas !

                J'aimerais juste qu'on me décrive Rust sans utiliser le mot C++, qu'on me dise ce que Rust peut faire, qu'on me donne ses fonctionnalités sans forcément devoir comparer à un autre langage dès le premier paragraphe alors que ça n'a pas de sens de le faire.

                • [^] # Re: «Il concurrence donc directement les langages C et C++.»

                  Posté par  . Évalué à 9. Dernière modification le 18 mai 2015 à 13:07.

                  Je ne vois pas en quoi ça n'a pas de sens.

                  D'abord, Rust est écrit par des dévs C++.

                  Ensuite, Rust est un langage influencé par le C++.

                  Et Rust a pour but de pouvoir remplacer C++, au moins pour une partie des projets de la MoFo dans un premier temps. A commencer au sein de Firefox - via Servo -, qui utilise C++ massivement.

                  Enfin, il opère sur le même créneau (pas de VM, utilisable pour les programmes "bas-niveau", multi-paradigme, …).

                  Sachant tout cela, ce ne sont pas vraiment les dévs Python/Ruby que Rust va cibler mais plutôt les dévs C et C++. Donc une comparaison est tout autant de mise.

                  Quant à donner les fonctionnalités et ce qu'il peut faire, ce n'est pas le but d'une dépêche sur la sortie de la V1.0 de Rust. Pour ça, il y a la documentation et les tutoriels.

                  "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

        • [^] # Re: «Il concurrence donc directement les langages C et C++.»

          Posté par  . Évalué à 4.

          Qu'est-ce qui fait dire à Mozilla que Rust va attirer les développeurs C/C++ ? Vu comment les développeurs C/C++ sont traités chaque fois qu'ils critiquent Rust, j'ai envie de dire que c'est mal barré.

          Le fait que pas mal de développeurs Rust soient des gens qui connaissent très bien le C++, et qu’ils lui préfèrent Rust pour leur raison propres ? Et que donc, ils pensent sincèrement que les autres développeurs C++ devraient préférer Rust pour ces mêmes raisons. Ça n’est pas une bonne raison selon toi ?

          L'industrie ne peut pas se permettre deux concurrents, et souvent, l'un des deux meurt.

          L’industrie vit très bien avec des concurrents, à condition qu’ils soient interopérables. En informatique, ça veut dire : être capable de fournir une interface binaire « C » et d’appeler des fonctions binaires « C ». Rust est capable du second, pour le premier, je ne sais pas où ça en est.

          Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

        • [^] # Re: «Il concurrence donc directement les langages C et C++.»

          Posté par  . Évalué à 5.

          Ce qui m'énerve, c'est qu'on n'arrête pas de comparer Rust à C/C++ alors que ça n'a à peu près rien à voir. Qu'on compare Rust à Go, par exemple, me semble bien plus pertinent.

          C'est là qu'on voit que tu n'a pas du beaucoup te renseigner sur la question.

          La plupart des idiomes de programmation (moderne) de C++ (RAII par exemple) se retrouvent tel quel dans les idiomes de Rust avec un plus un support du compilateur.

    • [^] # Re: «Il concurrence donc directement les langages C et C++.»

      Posté par  (site web personnel) . Évalué à 6.

      Il ne faut pas se leurrer, Rust ne concurrence nullement C/C++.

      Je ne connais le Rust qu'au travers des conversations que j'ai eu avec des enthousiastes et ce que je comprends est que Rust essaie d'être un langage portable assez bas niveau et proche de la machine, autrement dit, un C pour les machines d'aujourd'hui.

  • # Rust over GCC

    Posté par  (site web personnel) . Évalué à 3.

    On voit que GCC évolue lui aussi et que la dernière version, 5.1, permet par exemple le JIT. Bref, il est désormais possible d'envisager une machine virtuelle dans GCC comme cela se fait sous LVVM.

    L'équipe de Rust envisage t-elle un portable sur GCC ?

    • [^] # Re: Rust over GCC

      Posté par  . Évalué à 3.

      Le problème c'est que l'équipe de GCC fait tout ce qu'elle peut pour empêcher la réutilisation du backend. Cela fait partie de la posture philosophique de RMS pour empêcher que des entreprises réutilise le code de GCC pour en faire un compilateur non-libre (comme l'a fait Apple avec Swift et LLVM).

      Là ou l'idée fondatrice de LLVM est une séparation du backend et du frontend de compilation en passant par un langage intermédiaire bien défini. C'est pour cela qu'il a beaucoup de langage expérimentaux qui se basent sur LLVM. Cela pose d'ailleurs un problème sur Windows car LLVM n'est pas très mature sur cette plateforme.

      Ceci dit, je crois me souvenir qu'il y a eu des ouvertures récente sur ce sujet de l'équipe de GCC.

      • [^] # Re: Rust over GCC

        Posté par  (site web personnel) . Évalué à 7.

        Il me semble que ce que tu décris est du passé, non sur la partie non libre ou il est clair que la FSF ne pousse pas au non libre (et ils n'ont pas tord) mais l'architecture de GCC a été fortement ouverte ces derniers temps et j'ai vu des greffons arriver sur cette plate-forme qu'on ne voyait que sur LLVM.

    • [^] # Re: Rust over GCC

      Posté par  . Évalué à 3.

      Je pense que ça n’est largement pas une priorité, surtout qu’il y a encore beaucoup de boulot en perspective pour le compilateur actuel.

      Écrit en Bépo selon l’orthographe de 1990

  • # Premières impressions

    Posté par  (site web personnel) . Évalué à 7.

    L'annonce de la sortie imminente de la version 1.0 de ce langage m'avait motivée à m'y pencher un peu plus (j'avais regardé un peu suite aux différentes dépêches, mais vu les évolutions d'une version à l'autre j'avais préféré attendre que ça se stabilise).

    Bilan : je trouve les fonctionnalités un peu "annexes" (le pattern matching, l'inférence de type) plutôt sympathiques, certes c'est pas "nouveau" mais quand même plutôt bien foutu.

    Par contre la façon de gérer la mémoire… ouah, c'est quand même vraiment particulier, et autant le reste j'ai l'impression d'avoir déjà vu des éléments dans un langage ou un autre, autant là, il y a un coup de main à prendre. Je pense notamment à la notion de "lifetime", qu'il faut parfois déclarer en plus du type des variables pour indiquer que la référence que renvoie une fonction ne sera plus valable une fois que tel argument sera détruit. Une fois le truc un peu compris, ça paraît une bonne idée, mais ça m'a demandé de réfléchir un peu plus que la plupart des autres langages à la syntaxe "à la C". (Ce qui me rend dubitative sur l'attrait de Rust pour les fans de langages dynamiques : pour le coup le on a un compilateur que je trouve quand même fort psychorigide, ce qui est une qualité dans une logique de sécurité du code mais me paraît demander quand même une autre approche qu'un langage dynamique.)

    Globalement je trouve l'approche du langage intéressante, même s'il y a des choses qui me convainquent moyennement pour l'instant (notamment le fait que quand tu fais un appel à ma_fonction (x) ça peut être soit une copie, soit un move qui va transférer la «propriété» de la variable x à la fonction ma_fonction, ce qui empêche d'utiliser à nouveau la variable par la suite dans la fonction appelante). Peut-être que c'est une question d'habitude à l'usage, cela dit.

    • [^] # Re: Premières impressions

      Posté par  . Évalué à 5.

      notamment le fait que quand tu fais un appel à ma_fonction (x) ça peut être soit une copie, soit un move qui va transférer la «propriété» de la variable x à la fonction ma_fonction, ce qui empêche d'utiliser à nouveau la variable par la suite dans la fonction appelante

      Si tu ne veux ni transférer la propriété de l'objet à la fonction, ni le copier, tu peux le passer soit en référence (&o), soit en référence mutable (&mut o) ; ce qui correspond à peu près à respectivement const t& et t& en C++. Au final, les mécanismes de passage de paramètres sont grosso modo semblables à ceux de C++, à part le passage avec transfert de propriété (celui qui interdit de réutiliser l'objet après l'appel).

      • [^] # Re: Premières impressions

        Posté par  . Évalué à 3.

        Au final, les mécanismes de passage de paramètres sont grosso modo semblables à ceux de C++, à part le passage avec transfert de propriété (celui qui interdit de réutiliser l'objet après l'appel).

        Ça existe aussi en C++, depuis C++03 avec auto_ptr (mais qui était une catastrophe), et correctement depuis C++11 avec la sémantique de mouvement / unique_ptr.

        Donc pour un programmeur C++, ce n’est pas ce point qui devrait poser problème lors d’un passage à Rust. Ça fait longtemps que je n’ai pas regardé en détail, mais de mémoire, il n’y a rien de véritablement « nouveau » dans Rust, il y a plutôt un sous-ensemble sûr de fonctionnalités offertes par différents langages, majoritairement C++ mais il y a quelques emprunts ailleurs.

        Les principaux reproches que j’avais à faire à l’époque (et je crois que ça n’a pas changé) :
        - pas de duck-typing sur les traits
        - pas de support de la programmation par contrats

        J’avoue que même à l’époque (il y a deux ans environ) je n’avais pas assez joué avec pour voir jusqu’où on pouvait aller en terme de métaprogrammation. Je crois que c’est aussi un manque, mais les choses ont peut-être évolué de ce côté là.

        Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

        • [^] # Re: Premières impressions

          Posté par  . Évalué à 1.

          pas de duck-typing sur les traits

          Quel intérêt?

          J’avoue que même à l’époque (il y a deux ans environ) je n’avais pas assez joué avec pour voir jusqu’où on pouvait aller en terme de métaprogrammation.

          Les macros ont été améliorées mais comme tu peux le voir dans les priorités après la 1.0, il y a des travaux de prévu pour étendre leurs possibilités.

          Écrit en Bépo selon l’orthographe de 1990

          • [^] # Re: Premières impressions

            Posté par  . Évalué à 3.

            pas de duck-typing sur les traits

            Quel intérêt?

            L’intérêt, c’est de ne pas avoir à déclarer explicitement l’implémentation (le terme est mauvais, je ne sais plus quel est le bon) d’un trait. Ce qui permet, notamment, si moi je définis un nouveau trait, et qu’il se trouve qu’un type de la lib standard/xyz respecte l’ensemble des propriétés de ce trait (et donc, est substituable au sens du LSP), que je l’utilise partout où j’ai déclaré que j’utilisais un type implémentant mon trait, même s’il ne déclare pas l’implémenter explicitement (je ne peux pas modifier la lib standard ou la lib xyz pour y rajouter mon trait).

            Pour pratiquer cela couramment en C++, c’est utile. Mon impression est qu’avec un système de traits explicites, tu te restreins arbitrairement. Ça me fait un peu penser à de la généricité contrainte par classe de base, même si ce n’est pas tout à fait la même chose.

            Après, il y des arguments pour ne pas l’avoir fait :
            - ça simplifie beaucoup le boulot du compilateur
            - l’existence et la signature d’une méthode (la seule chose que sait vérifier à ce niveau le compilo rust) ne suffisent pas à ce que sa sémantique soit identique / compatibles -> avec des traits explicites, on fait reposer cette responsabilité sur le développeur.

            Note que le deuxième point pourrait grandement être corrigé par… la programmation par contrat :).

            Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

            • [^] # Re: Premières impressions

              Posté par  . Évalué à 2.

              C'est vrai que tu restreins (c'est le but en fait), après est-ce que c'est "arbitraire" ? Comme tu le dis toi même dans ton message la simple compatibilité syntaxique ne suffit à savoir si on peut réellement substituer le type. On peut imaginer par exemple un type de liste et un type ensemble qui possèdent la même interface, seulement l'opération ajout n'est pas substituable car si l’élément existe déjà dans le conteneur on l'ajoute quand même dans le cas de la liste mais on ne l'ajoute pas dans le cas de l'ensemble.

              La programmation par contrat ne résout pas ce problème (en tout cas dans son acceptation classique) car comparer des contrats (des prédicats mathématiques en fait) n'est pas décidable. De plus les contrats sont en général optionnels et ce n'est pas si simple que cela de formaliser le comportement des fonctions.

              De plus tu peux imaginer des trait (des interfaces quoi) qui servent seulement à restreindre sans apporter des méthodes. Par exemple les std::marker dans la lib standard te permettent de specifier ce qu'il est possible de faire avec un type. Par exemple si std::marker::Copy est implémenté cela signifie qu'il est légal de se contenter de faire une copie du type pour obtenir un copie (pas de dépendance à copier en plus), pour autant Copy n'a aucune méthode attachée. On voit bien dans ce cas là que le trait sert à exprimer les intentions des développeur et les informations dénoté ne peuvent pas être reconstruite par ailleurs.

              Enfin, c'est principalement l’absence d'un tel mécanisme qui rend les erreurs des templates C++ aussi verbeux. Car le compilateur n'a aucun moyen de faire des vérifications autrement qu'en essayant d'instancier réellement le template et de voir si ça marche. D'ailleurs ils veulent le rajouter dans la prochaine version de C++ sous le nom de "concepts" (j'imagine que c'est dans une version différente de ce qui avait été proposé et refusé pour C++11).

              • [^] # Re: Premières impressions

                Posté par  . Évalué à 2.

                La programmation par contrat ne résout pas ce problème (en tout cas dans son acceptation classique) car comparer des contrats (des prédicats mathématiques en fait) n'est pas décidable. De plus les contrats sont en général optionnels et ce n'est pas si simple que cela de formaliser le comportement des fonctions.

                Tu as raison mais c’est un argument de mathématicien / formaliste. Que ça ne résolve pas tous les problèmes ne veut pas dire que ça n’en résout pas une bonne partie. L’analyse statique de code n’est pas de la preuve formelle, la vérification statique de contrats rentre dans cette catégorie : trouver un maximum (≠ toutes) d’erreurs à la compilation.

                Par exemple si std::marker::Copy est implémenté cela signifie qu'il est légal de se contenter de faire une copie du type pour obtenir un copie (pas de dépendance à copier en plus), pour autant Copy n'a aucune méthode attachée.

                Je ne connaissais pas cet usage. En quoi est-ce différent de simplement définir l’opérateur d’affectation ? (en considérant que les types sont par défaut non-copiables – j’avais compris que c’était le cas en rust).

                Enfin, c'est principalement l’absence d'un tel mécanisme qui rend les erreurs des templates C++ aussi verbeux. Car le compilateur n'a aucun moyen de faire des vérifications autrement qu'en essayant d'instancier réellement le template et de voir si ça marche. D'ailleurs ils veulent le rajouter dans la prochaine version de C++ sous le nom de "concepts" (j'imagine que c'est dans une version différente de ce qui avait été proposé et refusé pour C++11).

                Oui et non. L’idée des concepts est de formaliser les dépendances que peuvent avoir des classes / algorithmes génériques, en partie pour produire de meilleures messages d’erreur, en partie parce que rajouter de la sémantique est généralement une bonne idée. D’ailleurs, la doc de la STL fait depuis très longtemps (au moins depuis C++03) référence à ces concepts, même s’ils n’existent pas dans le langage. Mais les concepts, tels que je les ai toujours vu présentés, ne se substituent pas au « duck-typing ». C’est à dire que le fait qu’un type soit compatible avec un concept sera déterminé automatiquement par le compilateur. C’est d’ailleurs une partie très problématique qui provoque le report des concepts d’année en année, sachant que le bénéfice final n’est pas si évident (meilleurs messages d’erreur, mais c’est à peu près tout).

                Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

            • [^] # Re: Premières impressions

              Posté par  (site web personnel) . Évalué à 5.

              Ce qui permet, notamment, si moi je définis un nouveau trait, et qu’il se trouve qu’un type de la lib standard/xyz respecte l’ensemble des propriétés de ce trait (et donc, est substituable au sens du LSP), que je l’utilise partout où j’ai déclaré que j’utilisais un type implémentant mon trait, même s’il ne déclare pas l’implémenter explicitement (je ne peux pas modifier la lib standard ou la lib xyz pour y rajouter mon trait).

              À moins que je n'ai pas compris ce que tu voulais dire, tu te trompes. Dans ce très bon lien sur les traits (que j'avais déjà donné plus haut) on peut lire :

              Unlike interfaces in languages like Java, C# or Scala, new traits can be implemented for existing types (as with Hash above). That means abstractions can be created after-the-fact, and applied to existing libraries.

              Il faut certes déclarer explicitement que le type existant implémente bien ton propre Trait, mais il n y a pas besoin de modifier la bibliothèque standard pour ça, tu le fais dans ton propre code.

              • [^] # Re: Premières impressions

                Posté par  . Évalué à 1. Dernière modification le 20 mai 2015 à 07:28.

                Effectivement, j’ignorais cela, je ne l’avais pas vu passer dans les évolutions depuis mes derniers essais (qui datent un peu, je dois dire).

                Va falloir que je m’y remette :).

                Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

                • [^] # Re: Premières impressions

                  Posté par  . Évalué à 2.

                  À vrai dire je crois que ça existe depuis vraiment longtemps, mais ça n’est pas vraiment la fonctionnalité pour laquelle on fait le plus de pub.

                  Écrit en Bépo selon l’orthographe de 1990

              • [^] # Re: Premières impressions

                Posté par  . Évalué à 2. Dernière modification le 20 mai 2015 à 08:12.

                Unlike interfaces in languages like Java, C# or Scala, new traits can be implemented for existing types (as with Hash above). That means abstractions can be created after-the-fact, and applied to existing libraries.

                Ca me rappelle les méthodes d'extension en C#

                "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                • [^] # Re: Premières impressions

                  Posté par  (site web personnel) . Évalué à 4.

                  Oui tout à fait, mais les traits vont quand même un cran plus loin.

                  Les méthodes d'extensions comme les traits permettent de dire : à partir de maintenant, les String ont la méthode wordCount() ; sans cela tu devrais, dans ton code, appeler une méthode statique prenant une String en paramètre (d'ailleurs comme l'explique ton lien il s'agit principalement de sucre syntaxique qui fait cet appel statique à ta place).

                  En revanche, les traits permettent aussi de faire la chose suivante :
                  si un code tiers définit le trait WordCount (ayant une méthode wordCount()), ainsi que des fonctions manipulant des objets implémentant ce trait, je peux dans mon propre code dire que les String (définies dans la bibliothèque standard que je ne peux/veux pas modifier) implémentent ce trait, et donc appeler les fonctions de ce code en lui passant directement des String. Ce n'est pas possible en C# de dire que maintenant String implémente l'interface IWordCount.

                  En C#, tu devrais soit :

                  • dériver de String dans une classe WordCountableString (bon en l'occurrence les String ne sont pas dérivables en C#, mais avec une autre classe ça aurait pu être une possibilité).
                  • créé une classe proxy WordCountableString qui wrappe un objet String.

                  Mais du coup si du code tiers te génère des objets String, tu devras construire un objet WordCountableString correspondant pour pouvoir les passer aux méthodes attendant des IWordCount ; ce qui alourdit à la fois le code et l'exécution (à cause d'objets supplémentaires 'inutiles').

                  • [^] # Re: Premières impressions

                    Posté par  . Évalué à 4.

                    En revanche, les traits permettent aussi de faire la chose suivante :
                    si un code tiers définit le trait WordCount (ayant une méthode wordCount()), ainsi que des fonctions manipulant des objets implémentant ce trait, je peux dans mon propre code dire que les String (définies dans la bibliothèque standard que je ne peux/veux pas modifier) implémentent ce trait, et donc appeler les fonctions de ce code en lui passant directement des String. Ce n'est pas possible en C# de dire que maintenant String implémente l'interface IWordCount.

                    Il me semble que seules la crate définissant WordCount et la crate définissant String pouvaient implémenter le trait pour String, tout autre crate n'en a pas le droit. Par contre tu peux bien implémenter WordCount pour un type défini dans ton propre code.

                    • [^] # Re: Premières impressions

                      Posté par  (site web personnel) . Évalué à 2.

                      Il me semble que seules la crate définissant WordCount et la crate définissant String pouvaient implémenter le trait pour String, tout autre crate n'en a pas le droit.

                      Si c'est le cas, alors je me suis un peu emporté ! À vérifier donc.

                      Par contre tu peux bien implémenter WordCount pour un type défini dans ton propre code.

                      Ah ben oui forcément, sinon ça va être difficile de faire des API ! Parce que définir dans ton code une classe avec une interface d'un autre package c'est un peu le truc de base.

                      La subtilité étant de pouvoir étendre des types définis ailleurs (comme bool), vu qu'étendre ses propres types ça tombe sous le sens.
                      En revanche oui, à vérifier si on peut étendre dans C un type défini dans A avec un trait défini dans B, j'ai peut être dit des bêtises pour ce cas ; le lien que j'ai donné au dessus (sur http://blog.rust-lang.org) ne parle pas d'une telle restriction, mais ce n'est pas une documentation exhaustive non plus…

                      • [^] # Re: Premières impressions

                        Posté par  . Évalué à 6.

                        C'est dans le rust-book mais ça a été ajouté récemment il me semble:

                        There’s one more restriction on implementing traits. Either the trait or the type you’re writing the impl for must be defined by you. So, we could implement the HasArea type for i32, because HasArea is in our code. But if we tried to implement Float, a trait provided by Rust, for i32, we could not, because neither the trait nor the type are in our code.

                        Une RFC récente qui traite du sujet: https://github.com/rust-lang/rfcs/blob/master/text/1023-rebalancing-coherence.md
                        (mais je ne l'ai pas lue en détail donc je suis pas sûr que ce soit elle qui ajoute ces règles).

                      • [^] # Re: Premières impressions

                        Posté par  (site web personnel) . Évalué à 4.

                        C'est effectivement pas possible, si on essaie par exemple le code suivant (pour étendre le trait Iterator au type u32) :

                        impl Iterator for u32 {
    type Item = u32;
    fn next (&mut self) -> Option<u32> {
        *self = *self + 1;

        Some(*self)
    }
}

                        le compilateur renvoie le message d'erreur suivant :
                        test.rs:1:1: 8:2 error: the impl does not reference any types defined in this crate; only traits defined in the current crate can be implemented for arbitrary types [E0117]

                        • [^] # Re: Premières impressions

                          Posté par  (site web personnel) . Évalué à 3.

                          Merci à vous 2 pour vos réponses de qualitay.

                          Allez zou distribution de +1

                          • [^] # Re: Premières impressions

                            Posté par  . Évalué à 8.

                            En fait c'est lié à la règle "Orphan rules".

                            Le problème c'est que si deux endroits dans le code déclarent tout les deux une implémentation sur le même type du même trait, alors on ne peut plus compiler car on ne sait pas quelle implem choisir.

                            Le souci c'est que cela peut être deux personnes complètement différentes, par exemple dans deux bibliothèques sans aucun rapport et ensuite une troisième personne veut utiliser ces deux lib et là paf le chien. C'est un problème bien connu en Haskell (langage d'où provient l'inspiration pour le mécanismes des traits, qui s'appellent "classe de type" là bas), d'où la restriction supplémentaire en Rust pour éviter de ce retrouver dans cette situation (pas très probable mais très emmerdante quand ça arrive).

                            • [^] # Re: Premières impressions

                              Posté par  (site web personnel) . Évalué à 2.

                              Ça explique tout merci.
                              Dans l'esprit ça ressemble au problème des héritages en diamant de C++ par exemple.

                              • [^] # Re: Premières impressions

                                Posté par  . Évalué à 2.

                                Dans l'esprit ça ressemble au problème des héritages en diamant de C++ par exemple.

                                Je ne crois pas. Je vois ça plus dans l’esprit :

                                • Je développe une fonction int add(int, int), je compile dans une bibliothèque A qui publie le symbole.
                                • Tu développes une fonction int add(int, int), que tu compile dans une bibliothèque B qui publie le symbole.

                                Un projet quelconque va vouloir utiliser nos deux bibliothèques, s’il utilise la fonction ci-dessus, le linkeur dynamique va en choisir un. Mais pire, la bibliothèque A peut appeler la fonction de la bibliothèque B…

                                Pour rust c’est ajouter des interfaces a un type, mais la problématique est bien : quelle méthode sera appelé en cas de double définition…

                                • [^] # Re: Premières impressions

                                  Posté par  (site web personnel) . Évalué à 1.

                                  mais la problématique est bien : quelle méthode sera appelé en cas de double définition

                                  C'est en ça que je trouvais que sémantiquement ça se ressemble. Mais mon commentaire était vague c'est vrai.
                                  Je crois qu'on est d'accord en fait.

                              • [^] # Re: Premières impressions

                                Posté par  . Évalué à 2.

                                L'heritage en diamant n'est pas propre a C++… N'importe quel langage qui autorise l'heritage multiple aura ce probleme… Certains le gerent plus ou moins bien, mais ca reste problematique, et il y n'y pas de solution generale qui soit elegante.

                                • [^] # Re: Premières impressions

                                  Posté par  (site web personnel) . Évalué à 1.

                                  Oui évidemment, je citais C++ pour l'exemple.

                                  La "solution" adoptée par un certain nombre de langages (ex: Java, C#) va être d'interdire tout simplement l'héritage multiple ; ça évite de tomber sur le problème, mais du coup ça prive aussi d'un outil qui peut s'avérer puissant. Je n'ai pas vraiment d'avis sur le fait que cela soit une bonne ou une mauvaise solution.

                                  De la la même manière la "solution" de Rust au problème est de mettre une restriction, en s'appuyant visiblement sur des écueils rencontrés avec Haskell. Il s'agit la aussi d'un compromis (un peu comme toujours en technique certes).

                                  • [^] # Re: Premières impressions

                                    Posté par  (site web personnel) . Évalué à 3.

                                    Une très bonne solution est dans le langage Sather https://fr.wikipedia.org/wiki/Sather

                                    Sather sépare la notion d'héritage et d'inclusion de code. Dans l'arbre des classes, on ne peux hériter que de classes virtuelles. Toutes les classes ayant du code sont forcément des feuilles d'extrémités. Pour ne pas tout ré-écrire, tu peux inclure du code qui est aussi une forme d'héritage… C'est très propre, clean et sans aucun risque.

                                    Bonus, le langage est contravariant et permet le surtypage et là, c'est très rare. En gros, tu te rends compte que A et B implémente tous les deux C, tu peux rajouter la liaison que A hérite de C et idem pour B, et cela marche ! C'est absolument génial car quelque soit l'arbre des classes, le ou les concepteurs ont toujours oublié un cas, surtout si tu mélanges plusieurs bibliothèques…

        • [^] # Re: Premières impressions

          Posté par  . Évalué à 9.

          Ça existe aussi en C++, depuis C++03 avec auto_ptr (mais qui était une catastrophe), et correctement depuis C++11 avec la sémantique de mouvement / unique_ptr.

          Ça existe, oui et non…
          La différence entre ça

          #include <iostream>
#include <memory>

static void foo(std::unique_ptr<int> ptr)
{
    std::cout << *ptr << '\n';
}

int main()
{
    std::unique_ptr<int> ptr(new int(42));
    foo(std::move(ptr));
    // OUPS!!!
    foo(std::move(ptr));
}

          et ça

          fn foo(n: Box<i32>) {
    println!("{}", n);
}

fn main() {
    let n =  Box::new(42);
    foo(n);
    // OUPS!!!
    foo(n);
}

          C’est ça

          42
zsh: segmentation fault (core dumped)  ./oups

          contre ça :

          oups2.rs:8:10: 8:11 error: use of moved value: `n`
oups2.rs:8     take(n);
                    ^
oups2.rs:7:10: 7:11 note: `n` moved here because it has type `Box<i32>`, which is non-copyable
oups2.rs:7     take(n);
                    ^
error: aborting due to previous error

          Dans un cas ça pète à la compilation (donc catastrophe évitée) dans l’autre ça pète à l’exécution (segmentation fault, youhou…).
          Donc oui y’a des trucs qui ressemble à ça en C++ mais c’est pas équivalent.

          • [^] # Re: Premières impressions

            Posté par  . Évalué à 6.

            Ce que tu montres, c’est que le compilo Rust est plus malin que le compilo C++.

            Mais mon propos, c’était que la sémantique est la même. Et que donc, pour un programmeur C++, la sémantique en général de Rust ne doit pas poser de problème de compréhension.

            Quand je lis ton code C++, je vois qu’il va merder (parce que l’exemple est simple). Idem quand je vois ton code Rust. Et le fait que l’un compile mais pas l’autre est un très bon argument en faveur de Rust, parce que dans la vraie vie l’erreur ne saute pas toujours aux yeux à la lecture du code :).

            Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

        • [^] # Re: Premières impressions

          Posté par  . Évalué à 1. Dernière modification le 20 mai 2015 à 09:21.

          Ça existe aussi en C++, depuis C++03 avec auto_ptr (mais qui était une catastrophe), et correctement depuis C++11 avec la sémantique de mouvement / unique_ptr.

          La différence c'est qu'en Rust c'est géré à la compilation. Alors qu'en C ça provoque une erreur à l'exécution.

          • pas de support de la programmation par contrats

          C'est dans les cartons. Lors de la conférence de présentation de la 1.0.0, ils ont justement discuté des idées qu'ils avaient à ce propos.

          • [^] # Re: Premières impressions

            Posté par  . Évalué à 2.

            pas de support de la programmation par contrats

            C'est dans les cartons. Lors de la conférence de présentation de la 1.0.0, ils ont justement discuté des idées qu'ils avaient à ce propos.

            Ça m’intéresse si tu as plus d’informations.

            Écrit en Bépo selon l’orthographe de 1990

      • [^] # Re: Premières impressions

        Posté par  (site web personnel) . Évalué à 2.

        Oui, en fait ce que je trouvais "bizarre" c'est que décider si c'est une copie ou un move soit «implicite» (en fonction de si le type implémente copy ou pas) alors que le reste (dire que c'est une référence, dire que c'est muable) est explicite.

        • [^] # Re: Premières impressions

          Posté par  . Évalué à 2. Dernière modification le 20 mai 2015 à 09:25.

          En fait au début c'était explicite, mais ça c'était révélé trop lourd à l'usage. Ils ont donc opté pour ce système qui est, il est vrai, déroutant au début, mais auquel on finit par s'habituer.

          • [^] # Re: Premières impressions

            Posté par  (site web personnel) . Évalué à 2.

            En fait je crois que ce que j'avais pas très bien compris (j'espère que là je dis pas des conneries :) ) c'est qu'au départ je pensais que si le terme implémentait le trait Copy ça appelait la méthode "copy" correspondante. Sauf qu'en fait le trait Copy ne contient aucune méthode, il s'agit juste d'un marqueur pour dire que le compilateur peut copier la mémoire (avec un memcpy quoi en gros), il n'est pas possible de redéfinir une implémentation. Ça c'est possible de le faire avec le trait Clone, mais dans ce cas il faut appeler la méthode x.clone () explicitement.

            • [^] # Re: Premières impressions

              Posté par  . Évalué à 1. Dernière modification le 24 mai 2015 à 10:22.

              C'est tout a fait ça. Copy sert juste a dire au compilateur que le type peut être copié de manière brute via un memcpy. Ceci dit si l'optimiseur détecte il n'a pas besoin de copier, il ne le fera pas.

    • [^] # Re: Premières impressions

      Posté par  . Évalué à 3.

      Par contre la façon de gérer la mémoire… ouah, c'est quand même vraiment particulier, et autant le reste j'ai l'impression d'avoir déjà vu des éléments dans un langage ou un autre, autant là, il y a un coup de main à prendre. Je pense notamment à la notion de "lifetime", qu'il faut parfois déclarer en plus du type des variables pour indiquer que la référence que renvoie une fonction ne sera plus valable une fois que tel argument sera détruit. Une fois le truc un peu compris, ça paraît une bonne idée, mais ça m'a demandé de réfléchir un peu plus que la plupart des autres langages à la syntaxe "à la C". (Ce qui me rend dubitative sur l'attrait de Rust pour les fans de langages dynamiques : pour le coup le on a un compilateur que je trouve quand même fort psychorigide, ce qui est une qualité dans une logique de sécurité du code mais me paraît demander quand même une autre approche qu'un langage dynamique.)

      Ton analyse est juste, mais Rust ne vise pas vraiment les développeurs Python à vrai dire. :) Là où Go attire certains développeurs Python ou Ruby par exemple.

      Écrit en Bépo selon l’orthographe de 1990

  • # Les traits

    Posté par  . Évalué à 5.

    Je trouve le principe des traits très intéressant. Et ça me ramène à Haskell. En lisant apprendre haskell vous fera le plus grand bien, on trouve l’équivalent de la création d’un trait rust avec la définition de la classe Eq(a)

    class Eq a where
    (==) :: a -> a -> Bool
    (/=) :: a -> a -> Bool
    x == y = not (x /= y)
    x /= y = not (x == y)

    Ce qui est bien dans cette déclaration c’est qu’on déclare les deux fonctions relatives l’une par rapport à l’autre, ce qui permet lorsque l’on veut instancier un type en classe Eq, il suffit de définir une des deux fonctions.

    Est-ce possible en rust ?

    • [^] # Re: Les traits

      Posté par  . Évalué à 4.

      Amusant ça la définition circulaire des fonctions qui te laisse le choix d'instancier celle que tu veux, pas sûr que ça soit un réel plus en pratique par rapport au classique 'tu dois définir cette fonction et les autres se basent dessus' mais bon..

      • [^] # Re: Les traits

        Posté par  . Évalué à 5.

        pas sûr que ça soit un réel plus en pratique par rapport au classique 'tu dois définir cette fonction et les autres se basent dessus' mais bon..

        C'est un réel plus pour des questions de performances. Par exemple, dans la class Ord, on peut définir soit la fonction <= soit la fonction compare qui retourne soit LT, soit EQ, soit GT. Sachant que si on décide l'implémenter seulement <=, utiliser compare a b va nécessiter de calculer à la fois a <= b et b <= a. Et réciproquement, probablement que la seule implémentation de compare fournit une implémentation sous optimale de <=, parce que compare calcule plus de choses que <=

        Et parfois, il y a une des fonctions du cycle qui est plus naturelle à définir.

        Please do not feed the trolls

    • [^] # Re: Les traits

      Posté par  (site web personnel) . Évalué à 5.

      "Est-ce possible en rust ?"

      Oui tu peux avoir la même chose avec l'implémentation par défaut de traits.

      trait Plop {
    fn even (&self) -> bool {!self.odd ()}
    fn odd (&self) -> bool {!self.even ()}
}

  • # Rythme de mise à jour oO

    Posté par  . Évalué à 1.

    Je viens d'apprendre que Rust aura un rythme de mise à jour de 6 SEMAINES… Soit le même rythme que Firefox, c'est le premier langage que je vois de ma vie à évoluer aussi vite.. Avec autant de mises à jours, il aura largement le temps de rattraper ses lacunes sur le futur C++ 2017!

    • [^] # Re: Rythme de mise à jour oO

      Posté par  . Évalué à 10.

      Rewind va te gueuler dessus.

    • [^] # Re: Rythme de mise à jour oO

      Posté par  (site web personnel) . Évalué à 5.

      c'est le premier langage que je vois de ma vie à évoluer aussi vite..

      Tiens, en voila un qui sors une version tous les mois ;-)

      http://rakudo.org/how-to-get-rakudo/

    • [^] # Re: Rythme de mise à jour oO

      Posté par  . Évalué à 5.

      Je pense que l’idée est (comme pour Firefox) d’éviter d’avoir des grosses mises à jour et de pouvoir itérer rapidement dessus, dans l’esprit «release early, release often». Ainsi je pense qu’on verra arriver les fonctionnalités manquantes (et rétro-compatibles) dans Rust petit à petit plutôt que lors d’une grosse version qui se fait attendre.

      Écrit en Bépo selon l’orthographe de 1990

  • # type sum ?

    Posté par  (site web personnel) . Évalué à 0.

    Je rêve ou Rust n'a pas de type somme et de filtrage ? Comme dans les langages fonctionnels ?

    "La première sécurité est la liberté"

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.