Rust 0.12 : non, pas le jeu vidéo, le langage !

35
3
nov.
2014
Technologie

Le langage de programmation Rust continue son bonhomme de chemin et se prépare à une version bêta 1.0 avant la fin de l'année.

En attendant, Rust 0.12 est sorti le 9 octobre 2014 ! Pour rappel, Rust est un langage de programmation système qui vise la performance et la sûreté. Il est développé par Mozilla, en parallèle d'un nouveau moteur expérimental de rendu de pages web écrit en Rust : Servo.

Rust

Rust est open source au sens de l'OSI et libre. Son développement est fait de façon ouverte sur GitHub et le code source est publié sous double licence Apache 2.0 et licence MIT.

Pour une meilleure compréhension des détails techniques de cette dépêche et des évolutions de Rust, il est conseillé de se référer à la dépêche sur Rust 0.8 (ainsi qu’aux suivantes que vous trouverez via les tags rust et langage_rust).

Sommaire

rouille

Évolutions

Depuis sa première sortie en 2012 (voir la dépêche sur la version 0.1), le langage a connu un développement rapide en intégrant des fonctionnalités qui incluent les types de données algébriques, les fermetures, l'inférence de type, la sécurité de la mémoire garantie et un environnement d'exécution minimal.

Depuis la version 0.11, les spécifications du langage ont peu changé.

Principaux changements

Voici une liste laconique des apports majeurs :

  • les annotations de durées de vie ne sont plus obligatoires dans plusieurs cas communs ;
  • clauses where ;
  • notation pour les tranches. C’est un opérateur surchargeable ;
  • travail sur les types à taille dynamique ;
  • plein d’autres RFC implantées, par exemple :

Prochains changements avant la version 1.0

Il y a un an, la version 1.0 était prévue pour la fin 2014. La feuille de route se remplit petit à petit. Cependant, il reste quelques points (attention, c’est un peu technique) :

  • types de taille dynamique : cette extension du système de type permet de gérer des types à taille fixe mais non connue à la compilation ;
  • fermetures unboxed ;
  • types associés ;
  • clauses where ;
  • traits Multidispatch ;
  • destructeurs ;
  • threads verts (green thread).

On trouve également des discussions sur les RFC pour implanter de l’héritage dans Rust.

Plateformes prises en charge

Rust fonctionne sous Windows (7, 8, Server 2008 R2) seulement x86, Linux (diverses distributions) ARM, x86 et x86-64, OSX 10.7 ("Lion") et ultérieurs x86 et x86-64, ainsi qu'Android. Nouveauté toute fraîche, un portage pour Dragonfly BSD a été réalisé avec succès.

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

Des chiffres !

Projets utilisant Rust

OpenHub (anciennement Ohloh) tient des statistiques sur l'utilisation de Rust dans les projets qu'il recense, comme pour tout autre langage. On peut ainsi voir que le nombre de personnes qui modifient du code Rust est relativement faible, mais augmente (de 121 projets pour la version 0.10 à 165 dans les projets recensés et 1 007 386 lignes de code). Par ailleurs, le nombre de projets recensés sur GitHub passe de 1428, lors de la sortie de la 0.10, à 3262.

Computer Language Benchmark Game

Tout d’abord, quelques rappels sur le Computer Language Benchmark Game. C’est un test de performance entre différents langages sur différents tests. Le code source destiné au test pour chaque langage doit utiliser le même algorithme.

Lors de son entrée dans ce fameux test, mentionnée dans la dépêche sur 0.10, Rust montrait des performances inégales en fonction des tests, bons pour fasta (génération et écriture de séquences ADN aléatoires dans le format FASTA) (aussi bon que C++) mais mauvais pour pidgits (calcul de décimales de pi).

Avec la dernière version, le test sur pidgits place le langage à égalité en première place avec le C, avec tout de même une plus grande consommation mémoire. Le langage est même plus performant que C++ pour la moitié des tests.

Pour plus de détails sur les différents tests (algorithme, codes source pour les différents langages), vous pouvez consulter la page qui liste tous les tests.

Outils

Gestionnaire cargo

Cargo s'occupe de télécharger les dépendances nécessaires au projet, teste le projet, démarre la compilation (et le binaire).

Par exemple, on peut commencer un nouveau projet avec cargo new bonjour_monde --bin. L'exécution est immédiatement possible avec cargo run.

Tests

Rust est livré avec un système de tests natif. Il prend la forme de directives directement intégrées dans le code source pour les tests unitaires, alors que les tests d'intégration nécessitent la création d'un fichier dédié.

L'exécution des tests fait appel à cargo via un simple cargo test.

Documentation rustdoc

Un autre utilitaire est livré gratuitement avec Rust : rustdoc permet de générer une jolie documentation écrite en Markdown. La syntaxe ne sera déroutante ni pour les moules, ni pour les utilisateurs de GitHub et StackExchange :

/// `bonjour` est une fonction qui souhaite le bonjour à la personne spécifiée en paramètre
///
/// # Arguments
///
/// * `nom` - Le nom de la personne que vous souhaitez accueillir.
///
/// # Exemple
///
/// ```rust
/// let nom = "Roger";
/// bonjour(nom); // Affiche "Bonjour, Roger!"
/// ```
fn bonjour(nom: &str) {
    println!("Bonjour, {}!", nom);
}

Formatage

À la manière de gofmt, rustfmt permet de standardiser la manière d'écrire du rust. C'est encore en développement, mais il est possible de le voir en action quand on utilise play.rust-lang.org et qu'on appuie sur le bouton format.

Des frameworks web

De nombreuses bibliothèques sont disponibles, seulement elles ne sont pas encore stabilisées. On compte par exemple, les cadriciels Iron et nickel.rs.

Il existe cependant quelques essais de développements, notamment TodoMVC, qui utilisent nickel.rs.

Liens

Notes de version

  • Le Wiki dispose de notes de versions détaillées ;
  • le fichier RELEASES.txt contient aussi des informations sur cette version.

Conclusion

Depuis le début, le design de Rust a beaucoup été simplifié. Les différents symboles indiquant un type de pointeur, à part & et &mut, ont disparu, les clôtures prennent en charge moins d’options, etc. Ceci ne s’est pas fait au détriment de la praticité : on peut en faire autant qu’avant, voire plus.

Tout ces changements sont articulés autour des concepts centraux de propriété et d’emprunt. Introduit pour partager efficacement des données entre tâches, il s’est révélé que cela a permis de déplacer beaucoup de choses dans des bibliothèques.

Rust est donc maintenant beaucoup plus proche du métal qu’il n’était possible de l’imaginer avant. Toutes les constructions du langage se traduisent directement en opérations machines et le runtime est optionnel, permettant d’écrire (par exemple) des noyaux de système d’exploitation.

Note : le runtime est nécessaire pour la gestion des tâches, les pointeurs gérés par un ramasse-miettes, etc. — tout ce qui n’est pas géré par le programme ou les bibliothèques et nécessite un peu de gestion de l’extérieur.

  • # Une petite question

    Posté par . Évalué à 3.

    code source est publié sous double licence Apache 2.0 et licence MIT.

    Tiens? Je croyais que ces licences étaient équivalentes, quelqu'un sait il pourquoi il y a ces 2 licences?

    Bon ça n'a pas une grande importance..

    En tout cas merci pour la dépêche.

    • [^] # Re: Une petite question

      Posté par . Évalué à 2.

      Si je me souviens bien, à la base la licence était uniquement MIT mais ils ont ajouté la APL 2.0 parce qu'elle a une clause pour prendre en compte les brevets.

    • [^] # Re: Une petite question

      Posté par (page perso) . Évalué à 3.

      Tiens? Je croyais que ces licences étaient équivalentes

      Non. Tu peux voir les descriptions des licences Apache 2.0 (tl;drLegal, GNU.org) et MIT (tl;drLegal et GNU.org).

      TL;DR: bien que les deux soient des licences copyleft, la MIT tiens en quelques lignes et n’impose quasiment rien contrairement à la licence Apache qui impose quelques trucs en plus et surtout couvre plus de cas (notamment brevets logiciels).

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

  • # magnifique

    Posté par . Évalué à 10.

    Magnifique dépeche :)

    Le guide a été récrit et est maintenant beaucoup plus didactique et compréhensible, introduit les concepts petit à petit et donc beaucoup plus digeste: http://doc.rust-lang.org/nightly/guide.html

    On n'a plus de '&' à rajouter dans tous les sens pour que le compilateur soit moins grognon, et je trouve que le projet va dans la bonne direction: cargo reprend le meilleur de pip/npm et laisse le moins bon, le systeme de "box" est maintenant très clair, on n'a plus besoin de garbage collector dans la std(youhou!!!)

    • [^] # Re: magnifique

      Posté par (page perso) . Évalué à 2.

      C'est vrai, je viens de lire en vitesse la doc est juste géniale ca donne envie de s'y mettre.

      Merci à ceux qu'ils l'ont écrite…

  • # Conférence et atelier RUST à Toulouse la semaine prochaine !

    Posté par . Évalué à 5.

    Pour les gens intéressés par RUST une conférence et un atelier auront lieu lors du capitole du libre à Toulouse la semaine prochaine :

    http://2014.capitoledulibre.org/programme/presentation/12/

    http://2014.capitoledulibre.org/programme/presentation/88/

  • # Rust vs Go

    Posté par (page perso) . Évalué à 3.

    OpenHub (anciennement Ohloh) tient des statistiques sur l'utilisation de Rust dans les projets qu'il recense, comme pour tout autre langage.

    Puisque Rust est apparemment en concurrence avec Go en tant que "language compilé généraliste qui va remplacer C++" j'ai regardé les stats OpenHub de Go.

    Nombre de projets Rust = 175
    Nombre de projets Go = 1 917

    Nombre de contributeurs Rust = 992
    Nombre de contributeurs Go = 5 007

    Nombre de commits Rust = 49 516
    Nombre de commits Go = 242 279

    Nombre de lignes de code en Rust = 1 013 026
    Nombre de lignes de code en Go = 15 289 395

    Donc en résumé Go écrabouille Rust sur les stats OpenHub. C'est sans doute lié au fait que Go est apparu 3 ans avant Rust et qu'il a déjà passé la barre fatidique de la version 1.0.
    Mais bon ça indique peut-être également que Rust va devoir cravacher pour rattraper son retard (si les deux langages sont vraiment en concurrence).

    • [^] # Re: Rust vs Go

      Posté par (page perso) . Évalué à 10.

      Je suis pas sûr qu'ils soient sur le même créneau. Go n'est pas assez performant àmha pour concurencer C ou C++, ce qui est l'objectif de Rust. Go est plus sur le créneau des applications Web, avec: le parallélisme, les binaires statiques, le garbage collector, etc.

    • [^] # Re: Rust vs Go

      Posté par . Évalué à 4. Dernière modification le 03/11/14 à 12:56.

      C'est sans doute lié au fait que Go est apparu 3 ans avant Rust et qu'il a déjà passé la barre fatidique de la version 1.0.

      Et peut-être aussi que Rust évolue un peu plus lentement à cause de la structure des contributeurs. Go a 88 contributeurs payés par google alors que Rust n'a que 25 contributeurs payés par Mozilla. Rust a un peu plus de contributeurs au total (+22 %) mais peut-être que ce sont des contributeurs plus occasionnels dont le travail n'arrive pas à compenser les dizaines d'employés supplémentaires que Google peut allouer au projet.

      Données :

      • [^] # Re: Rust vs Go

        Posté par . Évalué à 4. Dernière modification le 03/11/14 à 13:05.

        Et encore, sur les personnes avec des adresses en "@mozilla.com", une bonne partie sont des gens qui travaillent principalement sur Servo et Firefox et ne contribuent qu’occasionnellement à Rust. Le nombre de global de plein temps sur Rust ne doit pas dépasser la dizaine.

      • [^] # Re: Rust vs Go

        Posté par . Évalué à 3.

        Ce n'est pas une bonne métrique car tu as ton nom dans le fichier pour une contribution ponctuelle. Dans les faits, je ne vois pas 88 dev Google committer chaque mois (et encore moins 671 dev).

        Go a très peu de dev venant de Google (bien moins que Dart par exemple). L'augmentation récente de contributeurs Google vient (je pense) de l'utilisation de plus en plus importante de Go en interne.

      • [^] # Re: Rust vs Go

        Posté par . Évalué à 1.

        Il y a moins d'une dizaine de personnes qui font partie de la « Go team » à Google, et même parmi celle-ci, ils ne travaillent pas tous à temps plein sur Go.

        Si tu regardes, par exemple, les 30 plus importants contributeurs de Go, tu peux constater que seulement la moitié travaille effectivement chez Google.

        Par contre, il y a de nombreuses personnes qui écrivent des bibliothèques et programmes en Go chez Google, et c'est pour ça que certaines d'entre-elles remontent des patchs occasionnellement ou régulièrement.

        • [^] # Re: Rust vs Go

          Posté par . Évalué à 2.

          Je sais bien que cette métrique n'est pas idéale, mais c'est la seule pour laquelle je puisse avoir des données chiffrées, sourcées et disponibles pour les deux entités. L'idéal serait d'avoir la distribution des heures pour chaque contributeur, mais on n'a pas ça, tout ce qu'on a c'est le nombre de personnes et le domaine d'où ils contribuent, seule donnée quantitative sur laquelle on puisse travailler.

          Comme on n'a pas assez d'informations, il faut faire des hypothèses. Sachant que l'on parle ce sont deux entreprises travaillant sur des produits similaires et ayant leur siège au même endroit, je fais l'hypothèse que la structure de la distribution des temps parmi les contributeurs rémunérés est similaire (càd le pourcentage de personnes à plein temps parmi les contributeurs totaux devrait être proche). Dans ce cas, on peut regarder le nombre total de contributeurs comme un facteur d'échelle et les comparer pour estimer l'effort total.

          L'hypothèse pourrait être inexacte, et tu es le bienvenu à fournir des éléments chiffrés qui donne une estimation plus fiable.

    • [^] # Re: Rust vs Go

      Posté par . Évalué à 7.

      Puisque Rust est apparemment en concurrence avec Go en tant que "language compilé généraliste qui va remplacer C++" j'ai regardé les stats OpenHub de Go.

      Je pense que les deux langages n'ont pas les même objectifs mais qu'ils sont en concurrence. Rust intègre une foule de fonctionnalité et go cherche à rendre les chose simple. C'est très différents. Mais ils sont en concurrence parce que dans les fait sur un nouveau projet qui a un peu besoin de performance (pas de gros runtime à la python/ruby/perl), ils vont être comparés l'un à l'autre.

      Donc en résumé Go écrabouille Rust sur les stats OpenHub. C'est sans doute lié au fait que Go est apparu 3 ans avant Rust et qu'il a déjà passé la barre fatidique de la version 1.0.

      Il a 3 ans d'avance, il est plus facile d'accès, il bénéficie de l'appuie de google.

      Mais bon ça indique peut-être également que Rust va devoir cravacher pour rattraper son retard (si les deux langages sont vraiment en concurrence).

      Clairement, mais AMHA au final leur différences d'objectif va filtrer les utilisateurs. Rust me semble un langage vraiment plus poilu que go. Pour moi go est à rust ce que le C est au C++ (sans la paternité).

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

      • [^] # Re: Rust vs Go

        Posté par . Évalué à 6.

        Pour moi go est à rust ce que le C est au C++ (sans la paternité).

        Pas pour moi. Pour moi, le principal langage auquel comparer Rust, c’est Ada. Dans ses objectifs, Rust ressemble beaucoup à Ada, mais il a l’avantage d’être né 25 plus tard, à une époque où les concepts sous-jacents sont nettement mieux maîtrisés. Note que ça filtre aussi les utilisateurs.

        Go est beaucoup plus proche de C# qu’il ne l’est de Rust, dans la philosophie. Globalement, Rust apporte beaucoup : il prend le meilleur de C++ (le RAII, la gestion fine des ressources, le move semantic) et essaie de le transcrire dans un langage qui n’a pas les défauts de C++ (trop grande complexité, historique, absence de sécurité), en ajoutant un maximum de vérifications à la compilation. Go, en revanche, n’apporte fondamentalement pas grand chose (c’est un bon concurrent à C# qui n’a pas le badge microsoft, mais rien de révolutionnaire. Vala est sur le même créneau, mais comme il ne sort pas de google on en fait moins tout un foin).

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

        • [^] # Re: Rust vs Go

          Posté par . Évalué à 7.

          Go est beaucoup plus proche de C# qu’il ne l’est de Rust, dans la philosophie.

          Clairement pas. C# c'est du bon gros objet avec un typage en objet par classe. Une grosse partie de bibliothèque asynchrone, un gros runtime avec du JIT. Je vois vraiment pas le rapport avec du Go (éventuellement un peu l'asynchrone).

          il prend le meilleur de C++ (le RAII, la gestion fine des ressources, le move semantic) et essaie de le transcrire dans un langage qui n’a pas les défauts de C++ (trop grande complexité, historique, absence de sécurité), en ajoutant un maximum de vérifications à la compilation.

          Bref c'est un C++++ ! AMHA il est plus simple du fait qu'il n'a pas de compatibilité à gérer mais il garde la complexité liée au fait d'ajouter beaucoup de fonctionnalités.

          Go, en revanche, n’apporte fondamentalement pas grand chose

          En est d'accord, comme le C, il est simple.

          c’est un bon concurrent à C#

          Sincèrement le C# en fait bien plus. Le C# c'est vraiment du Java++ avec entre autre beaucoup d'asynchrone, linq, tout le runtime .Net, etc. Je doute qu'il y ai beaucoup de monde qui se pose la question C# ou go pour son projet, parce qu'ils n'ont vraiment pas grand chose en commun.

          Vala est sur le même créneau, mais comme il ne sort pas de google on en fait moins tout un foin).

          Il n'a même pas réussi à convaincre dans sa propre communauté.

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

          • [^] # Re: Rust vs Go

            Posté par (page perso) . Évalué à 4.

            Bref c'est un C++++ ! AMHA il est plus simple du fait qu'il n'a pas de compatibilité à gérer mais il garde la complexité liée au fait d'ajouter beaucoup de fonctionnalités.

            Bof, le système de gestion de la mémoire est un peu complexe au premier abord mais je ne crois pas que la complexité de Rust tienne dans le nombre de fonctionnalités qu’il possède.

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

          • [^] # Re: Rust vs Go

            Posté par (page perso) . Évalué à 6.

            # Juste pour l'anecdote, C++++, ça s'écrit aussi
              __
             /    ++
             \__  ++

            Ce qui fait bien un C#, CQFD

            (Désolé pour l'ascii art mauvais, DLFP est pas fait pour ça :)

            • [^] # figlet, ascii art en console

              Posté par . Évalué à 1. Dernière modification le 04/11/14 à 09:17.

              Pour mémoire, l'ascii-art de texte en console se fait avec figlet :

              figlet C++ C#

                ____               ____  _  _   
               / ___| _     _     / ___|| || |_ 
              | |   _| |_ _| |_  | |  |_  ..  _|
              | |__|_   _|_   _| | |__|_      _|
               \____||_|   |_|    \____||_||_|  
              
            • [^] # Re: Rust vs Go

              Posté par (page perso) . Évalué à 1.

              C'est d'ailleurs pour ça que C# a un comportement indéfini B-)

        • [^] # Re: Rust vs Go

          Posté par (page perso) . Évalué à 5.

          Pour moi, le principal langage auquel comparer Rust, c’est Ada

          Je vois souvent une comparaison à Ada. C'est vrai ça ?

          Genre le système de typage de Rust permet de faire ce qu'on fait en Ada ? Par exemple deux types avec des valeurs entières ne sont pas mélangeable ?
          On peut avoir des types très strictement défini, des types avec modulo, des types où on s'amuse à décrire très précisément la structure de donnée qui va être stockée - pour de l'embarqué -, etc ?

          • [^] # Re: Rust vs Go

            Posté par . Évalué à 1.

            Les choses ont pas mal évoluées depuis les dernières fois où j’avais regardé, mais :

            • pour les typedef vers les valeurs entières, je crois que ce n’est pas possible et que l’idée est de passer par un struct qui contiendra ta valeur uniquement (la question restante est alors de savoir si le compilo génèrera un code optimal, rust est plutôt pas mauvais à ça).
            • pour les types avec modulo, même remarque
            • les types très strictement définis, je ne sais pas ce que c’est (mon ada date un peu)
            • pour la définition précise de la structure de données, il y a des choses, principalement pour la compatibilité avec l’ABI C, mais rien d’aussi riche que ce qu’Ada propose.

            De toute façon, il y a avant tout l’aspect Ada est certifié, approuvé, Rust non.

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

            • [^] # Re: Rust vs Go

              Posté par (page perso) . Évalué à 4.

              les types très strictement définis, je ne sais pas ce que c’est

              C'est vague mais c'est par exemple pouvoir dire que mon type c'est un entier entre -2 et +15 uniquement, et qu'on ne peut pas avoir une autre valeur.

              Bon au final Rust n'a donc rien à voir avec du Ada, sans même parler de certif.

              • [^] # Re: Rust vs Go

                Posté par . Évalué à 4.

                Plutôt d'accord avec toi, note quand même que tu liste que des choses que Rust ne sait pas faire par rapport à Ada, mais il y a l'inverse aussi: Ada n'a pas le typage incluant la durée de vie comme Rust (enfin je crois).

                • [^] # Re: Rust vs Go

                  Posté par (page perso) . Évalué à 2.

                  Ada n'a pas le typage incluant la durée de vie comme Rust (enfin je crois).

                  Peut-être parce qu'au final, on utilise assez peu les pointeurs et que même dans ce cas, de toutes façons, c'est très contrôlé (cf. à partir de la page 36 dans ce document).
                  Après, pour une variable "standard", on applique les règles standard de portée (cf. page 11 du même document).

                  Ceci dit, je n'ai certainement pas bien compris le concept de durée de vie dans Rust :D

                • [^] # Re: Rust vs Go

                  Posté par (page perso) . Évalué à 5.

                  note quand même que tu liste que des choses que Rust ne sait pas faire par rapport à Ada

                  Ben oui, puisque certains disent que Rust marche sur le même segment que Ada je regardais si Rust permettait ce que Ada permet. Savoir ce que Rust peut faire de plus c'est encore autre chose.

                  Et la conclusion c'est que Rust n'est pas sur le même segment que Ada.

      • [^] # Re: Rust vs Go

        Posté par (page perso) . Évalué à 10.

        Pour moi go est à rust ce que le C est au C++

        A mon avis, c'est plutôt "Rust est a Go ce que C++ est a Java".

        Rust se veut être un langage oriente performances, qui donne un maximum de contrôle au développeur pour qu'il sache exactement ce qui se passe sur la machine, tout en le contraignant a ne pas faire des choses dangereuses. Si on veut écrire un programme embarque, ou temps-réel (au vrai sens du terme), c'est a mon avis l'outil qu'il faut utiliser.

        Go, a l'inverse, est plus un langage dont le but est "Simple et efficace". Rien d'extraordinaire au niveaux des fonctionnalités, le plus innovant c'est les goroutines et tout ce qui tourne autour, qui ne sont pas une idée nouvelle mais juste implémentée de manière a ce que ça soit simple a utiliser. Ce que Go propose et qui est beaucoup plus intéressant, ce sont les a-cotes: les outils pour le programmeur, un déploiement simplifié, une compilation rapide… Bref, un langage qui répond plus que bien a 80-90% des besoins, et qui peut facilement être pris en cours de route par n'importe qui ayant bidouillé quelques lignes dans un langage C-like. Pour le reste, il y a possibilité de linker avec un bout de code en C.

        Go a été créé entre autres comme langage a utiliser par défaut chez Google, non pas pour ses fonctionnalités, mais pour son rapport performance/facilite d'utilisation a échelle Google (que ni Java, ni C++, ni Python, les langages de prédilection, n'atteignent)

        Du coup les deux langages sont beaucoup plus complémentaires qu'autre chose, ils n'ont pas du tout le même but. A mon avis ils sont mis en opposition sur des projets pour lesquels ni l'un ni l'autre n'apporte d'avantage énorme, du coup c'est pas simple de savoir lequel est le meilleur dans ce cas la. Mais si tu dois écrire un service qui coordonnent des requêtes de client pour des actions potentiellement longues, ou un moteur de rendu pour jeu video, le choix devrait être assez simple dans chacun des cas.

        • [^] # Re: Rust vs Go

          Posté par . Évalué à 5.

          A mon avis, c'est plutôt "Rust est a Go ce que C++ est a Java".

          La phrase m'a choquée au début, mais finalement je suis plutôt d'accord.

          A mon avis ils sont mis en opposition sur des projets pour lesquels ni l'un ni l'autre n'apporte d'avantage énorme, du coup c'est pas simple de savoir lequel est le meilleur dans ce cas la.

          AMHA à quand tu as peu de contraintes va au plus simple. C'est pour ça que go marche bien (et a de bonnes chances de bien marché), c'est un langage qui est choisi plus facilement par défaut de part sa simplicité.

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

    • [^] # Re: Rust vs Go

      Posté par . Évalué à 7.

      Je dirais plutôt que, à la lumière des résultats de Go, les stats de Rust sont plutôt bonnes. Comme tu le signales, Rust n'est même pas encore en version 1.0. Il n'est pas vraiment utilisable pour le moment en production (à part pour quelque masos qui n'ont pas peur de devoir réparer en permanence leur code) et il a pourtant déjà une forte communauté derrière lui.

      De plus il faut voir que Rust et Go ne sont que partiellement en concurrence. Il peuvent être tous les deux utilisable dans pas mal de domaines communs. Mais Go, notamment grâce avec son GC intégré est plus simple a prendre en main, au prix de performance brutes moindres.
      Rust de son coté met bien plus l'accent sur la sécurité et est un langage vraiment capable de faire de la programmation système (OS, drivers, …). En fait Rust concurrence plus le C/C++ que le Go.

    • [^] # Re: Rust vs Go

      Posté par (page perso) . Évalué à 4.

      C'est sans doute lié au fait que Go est apparu 3 ans avant Rust

      En fait, non: Rust a commencé à être développé un an avant Go (2006 pour Rust et 2007 pour Go) et a été annoncé officiellement un peu plus de 6 mois après (novembre 2009 pour Go et juillet 2010 pour Rust).

      Sources Wikipedia Go et Rust (plus Mozilla pour le mois de 2010 durant lequel s'est tenue la conférence où Rust a été annoncé).

      • [^] # Re: Rust vs Go

        Posté par (page perso) . Évalué à 3.

        novembre 2009 pour Go et juillet 2010 pour Rust

        Pourquoi est-ce que l'article Wikipédia de Rust indique "Appeared in : 2012" ?

        • [^] # Re: Rust vs Go

          Posté par (page perso) . Évalué à 1.

          Pourquoi est-ce que l'article Wikipédia de Rust indique "Appeared in : 2012" ?

          Probablement à cause de la première version alpha numérotée du compilateur actuel (basé sur llvm et écrit en Rust alors que le précédent était écrit en OCaml). Cette version a été publiée en janvier 2012, soit 3 mois avant la première version numérotée de go (avril 2012 d'après l'archive des anciennes versions).

    • [^] # Re: Rust vs Go

      Posté par . Évalué à 6.

      Puisque Rust est apparemment en concurrence avec Go en tant que "language compilé généraliste qui va remplacer C++" j'ai regardé les stats OpenHub de Go.

      • Go se focalise sur l'accessibilité, la maintenance du code et la concurrence en abaissant drastiquement les concepts à maîtriser. C'est un langage épuré, qui se veut utile dans 80% des cas en laissant volontairement tomber les 20% restant (chiffres pif-O-métrique). Il remplace NodeJS, Python, Ruby, Lua. L'atout de ce langage vient de la bonne imbrication de peu de concepts le rendant accessible et maintenable dans bien des cas (notamment quand tu as des dizaines de dev qui passent sur ton code de 200k SLOC sur 10 ans comme chez Google). Autre atout, sa simplicité sémantique permet le développement d'outils d'analyse de code (cf Vet, Lint, Oracle, Types en train d'être développés).

      • Rust se focalise sur la robustesse de code et la vitesse. Il intègre donc des concepts avancés le rendant bien moins accessible que Go, mais aussi plus intéressant dans des cas particuliers (bas niveau, embarqué, moteur de jeux, etc). Il remplace C/C++, Scala, Haskell, OCaml. Qui peut le plus peut le moins, un codeur Rust pourra donc utiliser son langage partout ou Go est possible.

      L'objectif de Rust est donc bien plus ambitieux mais aussi bien plus difficile à atteindre. J'attends beaucoup de Rust pour cette raison : peut on en 2014 faire un langage «accessible» qui produit du code robuste (ce que ni Haskell, ni Scala, ni OCaml n'ont réussi à faire par exemple) ? Je reste curieux de leur réussite (que j’espère) mais sans trop croire à un résultat exceptionnel.

      Le point intéressant est que peut potentiellement, on aura dans 10 ans 2 langages de programmation majeurs à la place de 10 :).

      Note : J'utilise le mot remplacer dans le sens "peut s'utiliser à la place de" (hors bien sur des questions de librairies).

      • [^] # Re: Rust vs Go

        Posté par . Évalué à 6. Dernière modification le 03/11/14 à 21:03.

        J'ai pourtant un peu plus de mal à lire du Go plutôt que du Ruby.

        Et pourtant Ruby après quelques mois sans en faire certains constructions font bizarre pendant quelques minutes (bref, plus ça va plus j'aime pas trop le Ruby "intelligent" plein de &, de do |k| => {} et autres biduleries).

        Bref, plus ça va plus je préfère un :

        var toto = new Chien(); //C#

        qu'un

        toto = Chien.new #Ruby

        voire un

        toto := Chien //Go approximatif

        Plus c'est "compact" moins c'est lisible (ou plus les habitudes de lecture feront voir un = au lieu de := et une ancienne variable qu'on instancie à nouveau qu'une nouvelle variable), à mon avis.

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

        • [^] # Re: Rust vs Go

          Posté par . Évalué à 5. Dernière modification le 04/11/14 à 05:48.

          Heu non, le code équivalent en Go à ton code C#/Ruby ce serait plutôt au choix :

          chien := new(Chien);
          chien := &Chien{};
        • [^] # Re: Rust vs Go

          Posté par . Évalué à 5.

          Plus c'est "compact" moins c'est lisible

          Je ne suis pas d'accord. La concision peut au contraire améliorer la lisibilité en étant moins fouillis et en faisant ressortir uniquement les choses importantes.

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

          • [^] # Re: Rust vs Go

            Posté par . Évalué à 2.

            Tu aurais un exemple ?

            Parce que la seule concision que je trouve utile, c'est celle qui permet d'éviter de se répéter (comme utiliser "var variable = new Type(); en C# au lieu de Type variable = new Type();)

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

            • [^] # Re: Rust vs Go

              Posté par . Évalué à 7.

              Tu aurais un exemple ?

              J'ai pas vraiment d'exemple, mais les constructions de plus haut niveau permettent de gagner en concision et en lisibilité. Par exemple une méthode qui renvoie vrai si l'un des éléments d'un ensemble (ou d'une liste ou ce que tu veux) respect une condition. Si tu l'écris de manière basique tu aura 3 ou 4 versions différentes en fonction du programmeur (qui utilisera au choix un while, un for ou un foreach avec au choix un break/return ou une condition après la boucle). Une comme exist en scala (ou dans pleins d'autres langages) qui prend une condition et s'applique à une liste est à la fois plus concise et plus lisible.

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

            • [^] # Re: Rust vs Go

              Posté par (page perso) . Évalué à 7.

              var myHash = {  };
              var keys = Object.keys(myHash);
              var key;
              for(var i = 0; i < keys.length; i++) {
                key = keys[i];
                // do what you want with key
              }

              vs

              for(var key in myHash) {
                // do what you want with key
              }

              Ok, en js justement on n'écrirait pas le premier, mais c'est pour illustrer.
              La concision vient entre autre du fait de structures de plus haut niveau.

              Autre exemple en ruby :

              myArray = []
              mySelection = []
              myArray.each do |value|
                if value % 2 == 0
                  mySelection << value
                end
              end

              ou alors

              myArray = []
              mySelection = myArray.select { |value| value.even? }

              On a, à mon avis, plus compact et plus lisible.

              • [^] # Re: Rust vs Go

                Posté par . Évalué à 2.

                La concision du code, je ne suis pas évidemment contre.

                Ce qui m'emmerde, c'est le Perl Golf (et Ruby s'inspire beaucoup de Perl). Sur le moment c'est clair parcequ'on est habitué. 6 mois après, c'est illisible.

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

                • [^] # Re: Rust vs Go

                  Posté par (page perso) . Évalué à 4.

                  La concision du code, je ne suis pas évidemment contre.

                  Ben j'en sais rien, c'est toi qui écrit « Plus c'est "compact" moins c'est lisible ».

                  L'histoire de Perl Golf ça n'a rien à voir, et d'ailleurs on trouve ce genre de chose dans tous les langages (par exemple http://js1k.com/ pour javascript).
                  Perl Golf ce n'est pas fait pour être relu 6 mois plus tard et on s'en fiche.
                  Je vois pas trop ce que ça vient faire là.

                  De mon point de vue, un code concis permet surtout de réduire ce qui ne sert à rien et donc d'augmenter la lisibilité par un meilleur rapport signal/bruit.

                  Evidemment ça demande à voir des termes lisibles et compréhensibles. C'est certains que si on remplace select par s dans le code ruby, 6 mois après c'est plus compliqué.

                  Pour le coup de := et =, c'est la même chose qu'avec = et ==, c'est juste que le choix est différent. Et avec une police à chasse fixe c'est déjà mieux. Et on peut très bien avoir une coloration différente pour les deux.

              • [^] # Re: Rust vs Go

                Posté par . Évalué à 3.

                En fait on ne parle pas forcément de la même chose.

                Je suis parfaitement d’accord que des constructions plus simple, comme :

                for(auto v : maListe) {
                  ...
                }
                

                sont nettement plus lisibles que :

                for(std::list<int>::const_iterator it = maListe.begin(); it != maListe.end(); ++it) {
                  ...
                }
                

                Qui sont inutilement trop lourdes. Néanmoins, je n’ai jamais été convaincu par les raccourcis « artificiels », comme memcpy, substr, ou l’utilisation d’opérateurs dans tous les sens pour gagner 3 caractères.

                Pour reprendre ton exemple :

                myArray = […]
                mySelection = myArray.select { |value| value.even? }
                

                Est peut-être clair pour toi qui connaît bien ruby, est indiscutablement plus concise, mais pour moi c’est incompréhensible au premier abord. J’ai besoin de réfléchir pour comprendre ce que ça fait, alors que la première forme que tu donnes est directement compréhensible.

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

                • [^] # Re: Rust vs Go

                  Posté par . Évalué à 0.

                  Merci, c'est exactement mon point de vue.

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

                • [^] # Re: Rust vs Go

                  Posté par . Évalué à 9.

                  Est peut-être clair pour toi qui connaît bien ruby, est indiscutablement plus concise, mais pour moi c’est incompréhensible au premier abord

                  Malheureusement on a pas encore inventé de langage compréhensible par quelqu’un qui le connaît pas. La vie est mal faite.

                • [^] # Re: Rust vs Go

                  Posté par . Évalué à 5.

                  Est peut-être clair pour toi qui connaît bien ruby

                  La lisibilité dépend évidement de celui qui lis. AMHA un code est généralement écris pour quelqu'un qui sait lire le langage en question.

                  Quand tu écris français cherche-tu a limiter ton vocabulaire et à utiliser des phrases courtes et simples pour faciliter la vie des non-francophones ?

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

                  • [^] # Re: Rust vs Go

                    Posté par . Évalué à 0.

                    Non.

                    Mais de la même manière, si je sais lire un opérateur ternaire, je lui préfère 9 fois sur 10 la lisibilité d'un if/else.

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

                    • [^] # Re: Rust vs Go

                      Posté par (page perso) . Évalué à 3.

                      C'est comme tout, il y a les bonnes et les mauvaises utilisations.

                      Mais genre :

                      var rowColor = rowIndex.even ? blue : red

                      C'est un bon cas ou pas d'après toi ? (c'est juste pour bien comprendre où est la limite dans ce que tu dis)

                      • [^] # Re: Rust vs Go

                        Posté par . Évalué à 2.

                        Je crois que le problème vient plus de l’usage détourné de certaines spécificités :

                        c = (toto % 2 ? add: mult)(a,b);
                        
                        (f) && f(param1);
                        
                        (p) && delete (p) || (p = new(int));

                        C’est évidemment lisible, mais rarement au premier coup d’œil. Après, j’ai connu l’excès inverse sur certains projets, où pour simplifier on interdit plein de construction du langage, et tu te retrouves à recoder ou contourner les limitations imposées…

                        • [^] # Re: Rust vs Go

                          Posté par . Évalué à 3.

                          Sauf la première (que j'écrirais sur 2 lignes) ce n'est pas de l'opérateur ternaire.

                          C'est une forme qu'on retrouve souvent en perl et en shell. Je trouve personnellement le foo(bar) or die; plutôt joli, mais je comprends ton point de vu.

                          j’ai connu l’excès inverse

                          Pour moi interdire { |toto| ... } c'est déjà verser dans l'excès (de la même manière qu'interdire les compréhension de liste en python).

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

                    • [^] # Re: Rust vs Go

                      Posté par . Évalué à 7.

                      J'ai jamais compris ce qu'il y avais de compliqué dans cet opérateur (dispo dans à peu près tous les langages), comme dans le ou exclusif ou l'opération de pre/postincrément. J'ai l'impression que ce n'est vraiment pas rationnel, c'est plus de la peur qu'autre chose.

                      Pour l'opérateur ternaire, je m'en sert allègrement :

                      • quand tout est court ou que je peux avoir une forme propre (c'est à dire quand la seconde valeur peut aller sur une nouvelle ligne en alignant le : avec le ?)
                      • qu'il me permet d'avoir une valeur const/final sans avoir à créer une méthode pour ça
                      • quand il permet de se rapproche de valeur par défaut

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

                      • [^] # Re: Rust vs Go

                        Posté par (page perso) . Évalué à 3.

                        qu'il me permet d'avoir une valeur const/final sans avoir à créer une méthode pour ça

                        Ça c'est aussi que certains langages ne permettent pas des trucs cool.

                        En ruby on peut très bien avoir :

                        rowColor = if rowIndex.even?
                                     blue
                                   else
                                     red
                                   end
                        • [^] # Re: Rust vs Go

                          Posté par . Évalué à 2.

                          Pour le coup, je préfère encore l’opérateur ternaire :). perl permet aussi ce genre de truc, et j’ai toujours trouvé ça affreux.

                          Après, il est clair que le langage qu’on a appris en premier (C dans mon cas) influe sur sa perception des choses.

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

                          • [^] # Re: Rust vs Go

                            Posté par (page perso) . Évalué à 4.

                            Après, il est clair que le langage qu’on a appris en premier (C dans mon cas) influe sur sa perception des choses.

                            Bien sûr. Pour ma part, ayant appris le Caml en second langage (après le Pascal, je ne compte pas le Basic de calculatrice), je trouve bien plus naturel que le if renvoie un résultat. Et ça évite d'ajouter d'autres constructions compliquant le langage comme l'opérateur ternaire.

                            Cela dit, faisant en pratique plus de Java que d'Ocaml, j'aime bien l'opérateur ternaire, que j'utilise pour initialiser des variables.

                      • [^] # Re: Rust vs Go

                        Posté par . Évalué à 5.

                        Certains/beaucoup en abusent avec des trucs du genre
                        var foo = une condition plutot longue avec des && ? Un appel de fonction : une autre condition ? Qq chose : autre chose;

                        Tant que les 3 parties de l'operateurs sont triviales et tiennent sur une ligne, ya effectivement pas de raisons de pas l'utiliser.

                        Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                  • [^] # Re: Rust vs Go

                    Posté par . Évalué à 2.

                    Quand tu écris français cherche-tu a limiter ton vocabulaire et à utiliser des phrases courtes et simples pour faciliter la vie des non-francophones ?

                    Disons que j’évite l’emploi de formes trop littéraires (par analogie, trop spécifiques au langage) si je suis en train de rédiger une doc technique. Au final, je trouve ta comparaison très pertinente, même si on n’y voit pas la même chose :).

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

                    • [^] # Re: Rust vs Go

                      Posté par . Évalué à 4.

                      Disons que j’évite l’emploi de formes trop littéraires

                      Oui mais là on parle d'une construction de base du langage. Pas d'une forme trop littéraire. A comparer c'est plus proche du participe passé que d'une allitération.

                      En fait je trouve qu'éviter cette construction en ruby c'est même plus dangereux qu'autre chose, parce que c'est très utilisé. Trop pour faire l'impasse dessus. Elle n'a vraiment rien de bien compliquée ce n'est que de la syntaxe.

                      Au final, je trouve ta comparaison très pertinente, même si on n’y voit pas la même chose :).

                      Donc tu écris ton code pour quelqu'un qui ne connaît pas le langage. C'est ton choix, mais c'est très risqué de s'imaginer que "n'importe qui" (=> quelqu'un qui ne comprend pas le langage) va aller bidouiller le code (sans forcément y comprendre quelque chose).

                      Ça peut paraître élitiste, mais tu place la barre tellement bas… Comme si tu interdisais les boucles while de peur quelqu'un inverse la condition.

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

                      • [^] # Re: Rust vs Go

                        Posté par . Évalué à 0.

                        Oui mais là on parle d'une construction de base du langage. Pas d'une forme trop littéraire. A comparer c'est plus proche du participe passé que d'une allitération.

                        Il y a plein de constructions de base en haskell que je trouve complètement illisibles. Les développeurs haskell les trouvent parfaitement lisibles, et très concises, moi pas. Après, les goûts et les couleurs…

                        Donc tu écris ton code pour quelqu'un qui ne connaît pas le langage.

                        Tu tires des conclusions un peu trop rapides et va largement au-delà de ce que j’ai dit. Je dis qu’une construction, fut-elle « de base » dans le langage, plus concise mais dont la lecture n’est pas intuitive, ne fait pas forcément gagner en lisibilité au programme. L’exemple déjà donné de l’opérateur ternaire est assez pertinent, aussi.

                        Comme toujours sur un sujet subjectif comme la « lisibilité », je crois que c’est surtout vouloir établir une règle unique ou d’être trop rigide sur des principes qui pose problème. Beaucoup relève au final du contexte.

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

                        • [^] # Re: Rust vs Go

                          Posté par (page perso) . Évalué à 2.

                          mais dont la lecture n’est pas intuitive

                          Oui mais c'est quoi intuitive ?

                        • [^] # Re: Rust vs Go

                          Posté par . Évalué à 6.

                          Il y a plein de constructions de base en haskell que je trouve complètement illisibles. Les développeurs haskell les trouvent parfaitement lisibles, et très concises, moi pas.

                          Je comprends pas un mot de russe, pourtant les russes le parlent depuis leur plus tendre enfance.

                          Après, les goûts et les couleurs…

                          Non ce que tu décris me semble vraiment plus proche de la compétence. La maitrise d'un langage passe par la maitrises de ses constructions de bases (pour notre exemple c'est une structure de contrôle). C'est comme si tu disais que les langages qui ne mettent pas de $ devant les identifiants de variables sont illisibles. C'est pas une question de goût c'est la maitrise du langage donné.

                          Tu tires des conclusions un peu trop rapides et va largement au-delà de ce que j’ai dit.

                          Pourtant tu interdit certaines boucles et certaines autres constructions pour des raisons de lisibilité. On est loin, très loin, de parties du C++ comme la programmation par template.

                          plus concise mais dont la lecture n’est pas intuitive

                          selectedIds = ids.select { |id| id.even? }

                          "Les identifiants sélectionnés sont, parmis les identifiants, ceux qui sont paires". Je ne vois pas ce qui perturbe. Le { | | ... } quand tu viens d'un autre langage ça surprend si tu découvre et après 2h c'est assimilé, soit tu ne découvre pas.

                          Comme toujours sur un sujet subjectif comme la « lisibilité »

                          C'est ce que je dis, il faut savoir pour qui on écris le code. Mais je doute que se limiter autant dans l'usage d'un langage soit pertinent ailleurs que dans l'éducation.

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

                          • [^] # Re: Rust vs Go

                            Posté par . Évalué à 2.

                            Je comprends pas un mot de russe, pourtant les russes le parlent depuis leur plus tendre enfance.

                            S’ils le parlent aussi mal que les Français parlent leur propre langue, ça va plutôt dans mon sens : une trop grande complexité ne sert à rien. Combien de Français aujourd’hui comprennent les implications d’un imparfait du subjonctif ? Bon ben ils ne s’en servent pas, c’est tout.

                            "Les identifiants sélectionnés sont, parmis les identifiants, ceux qui sont paires". Je ne vois pas ce qui perturbe. Le { | | … } quand tu viens d'un autre langage ça surprend si tu découvre et après 2h c'est assimilé, soit tu ne découvre pas.

                            J’ai trop vu cet argument appliqué à perl pour y accorder la moindre crédibilité. Le problème est que oui, une structure, ça s’assimile assez vite, mais souvent elle n’est pas seule. Et qu’à force, on se retrouve avec des choses qui sont peut-être lisibles pour un spécialiste, mais :
                            - je ne suis pas convaincu que ce soit plus lisible qu’une forme moins concise, même pour le spécialiste en question
                            - c’est clairement moins lisible pour un non-spécialiste

                            Pourtant tu interdit certaines boucles et certaines autres constructions pour des raisons de lisibilité. On est loin, très loin, de parties du C++ comme la programmation par template.

                            Encore une fois, tu vas largement au-delà de ce que j’ai dit. Je dis qu’une construction qui n’apporte que de la concision (on est donc à des années lumières de ce qu’apportent les templates en C++ ou la métaprogrammation) n’apporte pas forcément de la lisibilité. Que

                            for(auto item : maliste) // super
                            

                            réussit à être à la fois plus lisible et plus concis en toute circonstance, mais que

                            int a = mafonction(b,c)?4:mafonction2(b+c);
                            

                            est en général inférieur en lisibilité à

                            int a;
                            if(mafonction(b,c)) {
                                a = 4;
                            }
                            else {
                                a = mafonction2(b + c);
                            }
                            

                            En clair, je dis qu’utiliser des fonctions du langage super cool là où ça ne sert à rien relève du pédantisme plus que d’autre chose (là encore, cf perl pour voir à quoi ça mène). Après, chacun est libre de s’exprimer comme il veut, et chaque langage fait les choix qu’il veut. Et encore une fois, il faut faire preuve de mesure : l’excès, dans un sens ou dans un autre, n’est jamais bon.

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

                            • [^] # Re: Rust vs Go

                              Posté par . Évalué à 3.

                              Je déteste cette forme !

                              int a;
                              if(mafonction(b, c)) {
                                  a = 4;
                              }
                              else {
                                  a = mafonction2(b + c);
                              }

                              Elle n'est vraiment pas lisible car beaucoup trop longue !
                              C'est peut être bien parce qu'elle est constitué d'instruction triviale, mais la forme déconstruite fait perdre tout son sens au code (en fait il ne le perd pas c'est juste caché dans un océan d'instructions).

                              Si vraiment cette forme ne te convient pas (tu vois je ne relève même pas la mauvaise fois de ta forme sans espace et avec des noms de méthodes qui n'ont pas de sens) :

                              int a = !mafonction(b,c) ? mafonction2(b + c)
                                                       : 4;

                              Je préfèrerais toujours écrire :

                              int aValue(int b, int c) {
                                  int a;
                                  if(mafonction(b, c)) {
                                      a = 4;
                                  }
                                  else {
                                      a = mafonction2(b + c);
                                  }
                                  return a;
                              }
                              
                              // ce qui donne à la lecture quelque chose de bien plus concis
                              int a = aValue(b, c);

                              Bien sûr le aValue doit avoir un sens métier. L'énorme avantage c'est :

                              • a est initialisé dès sa création donc on peut le déclarer const
                              • on voit que tout ce code sert à initialiser a, on voit immédiatement que sa valeur dépend de b et de c
                              • en principe je me permet d'utiliser la forme ternaire dans une méthode pour qu'elle n'est qu'une seule ligne parce que la méthode est courte et que le nom de la méthode plus la documentation de celle-ci vont enlever tout ambiguïté

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

                              • [^] # Re: Rust vs Go

                                Posté par . Évalué à 2.

                                Je préfèrerais toujours écrire :

                                // ce qui donne à la lecture quelque chose de bien plus concis
                                int a = aValue(b, c);
                                

                                Comme quoi, sur ce point au moins on est parfaitement d’accord.

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

                              • [^] # Re: Rust vs Go

                                Posté par . Évalué à 2.

                                Je préfère nettement ceci:

                                int aValue(int b, int c) {
                                    if (mafonction(b, c)) {
                                        return 4;
                                    }
                                    return mafonction2(b + c);
                                }

                                Voire même:

                                int aValue(int b, int c) {
                                    if (!mafonction(b, c)) {
                                        return mafonction2(b + c);
                                    }
                                    return 4;
                                }
                                • [^] # Re: Rust vs Go

                                  Posté par . Évalué à 5.

                                  Je suis partisan d'un seul return surtout dans les cas si simples.

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

                                  • [^] # Re: Rust vs Go

                                    Posté par . Évalué à 4.

                                    Et bien alors moi pas du tout!

                                    Ici, tu te cognes entre 7 et 10 lignes de code (selon le coding style) contre juste entre 4 et 5 lignes de code pour lire la même chose.
                                    Sans compter que dans un cas tu dois faire très attention au flot de contrôle alors que dans l'autre cas il apparaît immédiatement.

                                    Et ça c'est sur un case simple, sur des cas plus compliques comme j'en vois au boulot, le code se simplifie très bien grâce a la technique du early exit.
                                    Dans ce cas, le code reste relativement "plat" en évitant des indentations trop grandes et sa lecture est presque linéaire.

                                    Quel est pour toi l'avantage d'un seul return?

                                    • [^] # Re: Rust vs Go

                                      Posté par . Évalué à 3.

                                      Ici, tu te cognes entre 7 et 10 lignes de code (selon le coding style) contre juste entre 4 et 5 lignes de code pour lire la même chose.

                                      Si tu lis le fil, tu saura que pour moi normalement il y a 1 à 2 lignes pas plus.

                                      Sans compter que dans un cas tu dois faire très attention au flot de contrôle alors que dans l'autre cas il apparaît immédiatement.

                                      Pour ça que je parle de cas simples, mais tu gagne beaucoup en maintenance.

                                      Et ça c'est sur un case simple[…]

                                      D'où le fait que je parle de cas simples.

                                      Dans ce cas, le code reste relativement "plat" en évitant des indentations trop grandes et sa lecture est presque linéaire.

                                      Justement généralement quand un cas deviens compliqué j'essaie généralement de le simplifier pour qu'il reste simple et tenter d'emballer les segments complexes dans des méthodes qui ne font que ça.

                                      Quel est pour toi l'avantage d'un seul return?

                                      1. Comme dis plus haut ce n'est pas une règle d'or.
                                      2. J'utilise de multiples techniques pour me retrouver le plus souvent possible dans des cas simples.
                                      3. Un seul return améliore notablement la maintenabilité. Dans les cas simples en utiliser un ou plusieurs ne pose aucun problème tout est limpide, sous les yeux, mais lorsque le projet vieilli, il devient plus simple d'ajouter des fonctionnalités, de debuger au debugger, etc si tu n'a qu'un seul return.

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

                                      • [^] # Re: Rust vs Go

                                        Posté par . Évalué à 3.

                                        Un seul return améliore notablement la maintenabilité. Dans les cas simples en utiliser un ou plusieurs ne pose aucun problème tout est limpide, sous les yeux, mais lorsque le projet vieilli, il devient plus simple d'ajouter des fonctionnalités, de debuger au debugger, etc si tu n'a qu'un seul return.

                                        Je ne suis pas convaincu par cet argument, ou bien je ne l'ai pas compris.

                                        Les early exits ne t'empêchent pas de debugger.
                                        De plus, tu n'as pas a gérer l’état de tes variables donc le code est plus facile a lire, comprendre, faire évoluer.

                                        • [^] # Re: Rust vs Go

                                          Posté par . Évalué à 3.

                                          De plus, tu n'as pas a gérer l’état de tes variables donc le code est plus facile a lire, comprendre, faire évoluer.

                                          Pour si tu as ce genre de problèmes c'est que la méthode est trop grosse (perso je considère une méthode de plus d'une vingtaine de lignes comme trop grosse, sauf cas particulier).

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

                                          • [^] # Re: Rust vs Go

                                            Posté par . Évalué à 3.

                                            Ben déjà, rien que sur cet exemple simple, ça me fait chier de devoir regarder ou et quand la variable est assignée alors que des early exit me le montrent instantanément.
                                            Alors imagine ce que je peux ressentir sur une fonction plus complexe.

                                            Tout ce que je vois ce sont des lignes inutiles qui réduisent le rapport signal/bruit.

                                            Mais je suis entièrement d'accord avec toi, plus les méthodes sont courtes, et plus c'est lisible.

                                            • [^] # Re: Rust vs Go

                                              Posté par . Évalué à 4.

                                              Un cas simple c'est ça :

                                              int aValue(int b, int c) {
                                                  return !mafonction(b, c) ? mafonction2(b + c)
                                                                           : 4;
                                              }

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

                                              • [^] # Re: Rust vs Go

                                                Posté par . Évalué à 2.

                                                C’est amusant. Tu préfères un opérateur ternaire et un single return à une structure if/then/else à return multiple. Là je dois avouer qu’à part une histoire de goût personnel, je ne vois vraiment rien qui favorise l’un ou l’autre (personnellement je préfère le return multiple, même avec ton indentation je ne suis vraiment pas fan du ternaire).

                                                Sinon, le single return, en C, vient souvent avec la nécessité du nettoyage, qu’on ne veut pas dupliquer. C’est vilain et pas beau, heureusement C++ nous permet de nous en passer.

                                                Dans tous les cas, comme tu l’as dit ailleurs, ce qui est le plus important, c’est avant tout de limiter la taille des fonctions.

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

                                    • [^] # Re: Rust vs Go

                                      Posté par . Évalué à 4.

                                      Quel est pour toi l'avantage d'un seul return?

                                      Sur une demande de modification, tu dois modifier la fonction après, 1 mois, 5 ans… si la fonction est grande avec de multiple return, tu as une bonne chance d’insérer du nouveau code après un return qui sera passé à cause d’une condition. Alors tu finiras par trouvé, mais tu perds un peu de temps. Je suis assez partisant également d’un seul return. Parfois, tu as du code bizarre genre :

                                      
                                      if (retVal != NOError)
                                      {
                                          
                                      }
                                      
                                      if (retVal != NOError)
                                      {
                                          
                                      }
                                      
                                      
                                      return retVal;
                                      }

                                      mais le compilateur fait lui même le return ou le goto. Et le code est séparé en petits blocs ce qui aide à comprendre rapidement l’algo global. Après, sur ton exemples avec peu de ligne, je suis d’accord que ce n’est pas un problème.
                                      Mais les « règles » ne sont-elles pas là pour être contournées ?

                                      • [^] # Re: Rust vs Go

                                        Posté par . Évalué à 3.

                                        si la fonction est grande avec de multiple return, tu as une bonne chance d’insérer du nouveau code après un return qui sera passé à cause d’une condition.

                                        Euh, pour moi tu as autant sinon plus de chances d'avoir ce genre de problèmes avec du code qui a un single return.
                                        Tu as aussi le problème du code qui réassigne les variables précédemment assignées.
                                        OK, ça n'a rien a voir avec le problème dont on parle, juste que le style single return fait qu'il est plus facile de tomber dedans. Bon on peut toujours utiliser const/final pour éviter ça.

                                        
                                        if (retVal != NOError)
                                        {
                                            
                                        }
                                        if (retVal != NOError)
                                        {
                                            
                                        }
                                        
                                        return retVal;

                                        Pour moi c'est l'exemple typique pourquoi le single return est mauvais, parce qu'il permet d’écrire des horreurs pareille.
                                        OK le compilateur sait éjecter ça, mais le programmeur doit a chaque fois payer la charge cognitive de comprendre ce code pour voir que non, le deuxième if ne fait rien (Le compilateur le fait aussi, mais il n'a pas mal a la tête lui).

                                        En fait, le single return promeut une écriture de code qui peut facilement devenir non lisible. Exemple réel que j'ai refactore hier et aujourd'hui:
                                        * http://sources.forgerock.org/changelog/opendj?cs=11264 , regardez la methode equals() de ConnectionHandlersMonitoringTableModel.java
                                        * http://sources.forgerock.org/changelog/opendj?cs=11261 , regardez la methode equals() de ServerDescriptor.java

                                        Le code n'est pas mois maintenable ou debuggable. Le flot de contrôle est très facile a garder en entier dans sa tête.
                                        Bref, a mon avis, le code après est bien plus maintenable que le code avant.
                                        Je vous accorde que c'est peut être un cas dégénéré, mais que je rencontre très (trop) souvent lorsque les gens essayent de coller au maximum a la règle du single return.

                                        • [^] # Re: Rust vs Go

                                          Posté par . Évalué à 3.

                                          Tu as aussi le problème du code qui réassigne les variables précédemment assignées.

                                          Encore une fois méthode trop longue.

                                          Pour moi c'est l'exemple typique pourquoi le single return est mauvais, parce qu'il permet d’écrire des horreurs pareille.

                                          Le signe de méthode trop longue, s'il y a des sous parties c'est qu'il faut découper.

                                          En fait, le single return promeut une écriture de code qui peut facilement devenir non lisible.

                                          En fait pour moi c'est une question de limiter le nombre de return. Il y a de très bonnes raisons de faire du retour rapide et dans 95% des cas ça consiste en un schemas simples :

                                          if (!valide(var)) {
                                             return /* ... */;
                                          }
                                          
                                          /*
                                           * contenu de la méthode
                                           */
                                          return /* ... */

                                          C'est par exemple le cas des méthodes equals() en java. On veut qu'elles soit rapides donc on valide rapidement que l'objet passé est bien du même type, puis on fait un return quand on a vérifier l'égalité des données.

                                          Le problème dont tu parle c'est quelqu'un qui a peur des expressions booléennes trop grosses.

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

                                          • [^] # Re: Rust vs Go

                                            Posté par . Évalué à 3.

                                            Bon je pense que nos visions ne sont pas si éloignées que ça.

                                            Je pensais que tu étais plus jusqu'au-boutiste pour le single return.
                                            Puisque j'essaie de l’éviter au maximum et que personne n'a trouve les arguments pour me convaincre du bien fonde de cette pratique, j’étais curieux de connaître tes arguments.

                                          • [^] # Re: Rust vs Go

                                            Posté par . Évalué à 4.

                                            Fonction trop longue, fonction trop longue c'est facile a dire ca. T'en foutrais moi des fonction trop longues.

                                            Ca arrive regulierement d'avoir des fonction des 50-100 lignes de code qui ne peuvent etre divisee sans avoir des noms de fonction a la con avec des signatures des bois, exposer des methodes que tu ne veux pas exposer, meme en private, et se perdre dans un dedale d'appels. Les controlleurs dans une UI tombent souvent dans ce cas.

                                            Sans compter le "rightward shift" et les declarations de variables en dehors du bloc quand tu veux checker tes input et faire un return null.
                                            Et tu force le relecteur a se taper toute la fonction pour savoir ce qu'il se passe si un imput est null .

                                            Typiquement:

                                            Something maFonction(pointer *a)
                                            {
                                            Something = null;
                                            If (a != nil)
                                            {
                                            Qqchose
                                            If(qqchose)
                                            {
                                            Encore autre chose
                                            }
                                            }
                                            return something;
                                            }

                                            Ca se reecrit tres bien en early exit, vachement plus lisible et tu finit pas a 3 niveaux d'indentation dans la partie interessante.
                                            Desole pour l'indentation des bois, markdown me court sur le haricot ce soir.

                                            Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                                            • [^] # Re: Rust vs Go

                                              Posté par . Évalué à 5.

                                              1. Il faudrait que je le mette en signature mais quand je parle de règles de programmation c'est toujours des objectifs à atteindre et pas des règles absolues
                                              2. J'ai pas compris ce que tu voulais montrer dans ton exemple
                                              3. Je ne vois pas de cas où tu fais quelque chose de si secret que personne d'autre que ta fonction doit savoir ce que c'est (on parle de fonctions pures dans l'énorme majorité des cas)
                                              4. Plus qu'une question de taille c'est une question de complexité, il faudrait que je me penche sur la question pour pouvoir dire à partir de quelle complexité cyclomatique amha il faut se poser la question
                                              5. Ça n'oblige l'utilisateur à aller voir le code de la méthode que si tu n'a pas documenter la méthode, que tu n'a pas de convention pour ça et que ton langage ne t'aide pas.
                                              6. D'expérience dans la majorité des cas tu peux découper. C'est pas une lubie que j'ai eu en me levant un matin. C'est juste que je me suis rendu compte qu'en 3 ans la taille des méthodes que j'écris c'est réduit pour arriver généralement à une vingtaine de lignes tout au plus.

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

                                              • [^] # Re: Rust vs Go

                                                Posté par . Évalué à 4.

                                                J'ai pas compris ce que tu voulais montrer dans ton exemple

                                                Dans cet exemple, la partie interessante est planquee a 3 niveau d'indentation, dans 2 if. ton code gestion du cas ou tu ne veux rien faire est melange avec celui ou tu fais effectivement qqchose. Dit autrement, c'est beaucoup plus simple a relire un code qui dit "valide tes input et annule tout si ca va pas, puis fait qqchose", plutot que "si des conditions sont verifiees, alors fait ca, et suit toute la fonction pour apprendre toute a la fin que si pointeur est nul, alors on return la valeur qui a ete sete par defaut 20 lignes plus haut.".
                                                Ton code est plus robuste aussi, tu risques pas de faire une connerie si t'es deja sorti de la fonction. Plus t'as de code entre la creation d'une variable et son return, plus t'as de chance de faire de la merde avec, c'est une variante du concept de "les seuls bugs que t'aura pas sont dans du code que t'as pas ecrit".

                                                Je ne vois pas de cas où tu fais quelque chose de si secret que personne d'autre que ta fonction doit savoir ce que c'est (on parle de fonctions pures dans l'énorme majorité des cas)

                                                Sans etre secret, on peut etre sympa pour ceux qui passent derriere et eviter de leur laisser une tonne de fonction a noms abscons qui ne sont appelees qu'a un seul endroit.

                                                Ça n'oblige l'utilisateur à aller voir le code de la méthode que si tu n'a pas documenter la méthode, que tu n'a pas de convention pour ça et que ton langage ne t'aide pas.

                                                Si t'ecris du code trivial tout seul dans ton coin, oui, c'est sur. mais c'est pas un cas tres pertinent. Les conventions, faut bien relire le code pour s'assurer qu'elle a bien ete suivie. Et mon langage m'aide beaucoup pour ce que je fais, merci bien, mais il ne resoud pas tous les problemes.

                                                D'expérience dans la majorité des cas tu peux découper.

                                                Ben d'experience, c'est pas le cas. J'ai des controlleurs qui font 80-100 lignes dans -viewDidLoad, et ya pas grand chose que je puisse y faire, a part dire au gars du produit d'aller se faire cuire un oeuf. J'ai essaye de les couper "setupThis, setupThat", et au final t'as un setup qui depend du resultat d'une operation au dessus, et t'as un gros merdier sur les bras. Soit t'as des signatures a la con, soit t'as une imbrication d'appel de fonction douteuses. Dans les deux cas, le code qui t'interesse est eparpille, et t'as au final rien gagne du tout.

                                                Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                                                • [^] # Re: Rust vs Go

                                                  Posté par . Évalué à 4.

                                                  Je crois qu'une partie de la discution t'a échappé. Ce que je suis c'est qu'il faut garder ses méthodes aussi courtes/simples que possible et réduire autant que possible le nombre de return.

                                                  Donc non il n'y a pas 15Mio de code entre une assignation et le retour parce que les méthodes sont courtes.

                                                  Au niveau qualité du code, l'utilisation de méthodes quand c'est bien fait permet de gagner en abstraction et de rendre le code bien plus lisible (le code informe sur le comportement métier recherché et pas sur une série d'actions bas niveau). On gagne aussi car on peut tester plus facilement le code et, si on prend le temps de faire du refactoring régulièrement, on peut gagner en réutilisation. En fin on adopte une vision API, ce qui améliore la maintenabilité.

                                                  Ça demande à se poser la question des responsabilités et on segmente un peu plus notre code et on regroupe plus facilement le code d'une même responsabilité. Ça permet de mieux repérer les problèmes de couplages (c'est ce dont tu parles quand tu dis qu'on se retrouve avec pleins de méthodes pour celui qui passe après).

                                                  J'ai pas compris ton argument qui dit que l'on ne documente et suit des conventions que lorsque l'on écris du code trivial dans son coin. C'est exactement l'inverse.

                                                  Pour ton laïus sur les contrôleurs. C'est justement un cas de code qui va manipuler potentiellement une bonne partie de l'application et qui devrait utiliser que du code de très haut niveau.

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

                            • [^] # Re: Rust vs Go

                              Posté par (page perso) . Évalué à 3.

                              S’ils le parlent aussi mal que les Français parlent leur propre langue, ça va plutôt dans mon sens : une trop grande complexité ne sert à rien. Combien de Français aujourd’hui comprennent les implications d’un imparfait du subjonctif ? Bon ben ils ne s’en servent pas, c’est tout.

                              La différence principale, c'est que même les langages de programmation soi-disant compliqués, sont vraiment beaucoup plus réguliers et faciles à apprendre qu'une langue naturelle, si on met de côté les concepts de programmation génériques qui ne sont pas spécifiques à un langage. Passer de python à perl, ou de perl à ruby, c'est extrêmement facile par rapport à passer du français au russe, ou du russe au chinois.

                              Et si certaines tournures semblent trop concises dans des langages comme perl, je n'ai pas l'impression qu'en pratique ce soit un problème pour peu qu'on s'y mette; je sais que certains semblent avoir souffert avec ce langage, mais la seule explication convaincante que j'ai pu trouver jusqu'à présent c'est qu'ils ont dû supporter la lecture d'un code dans un style d'il y a quinze ans ou plus écrit à la va-vite et dont le problème majeur n'était pas l'utilisation de tournures concises.

                        • [^] # Re: Rust vs Go

                          Posté par . Évalué à 2.

                          Il y a plein de constructions de base en haskell que je trouve complètement illisibles. Les développeurs haskell les trouvent parfaitement lisibles, et très concises, moi pas. Après, les goûts et les couleurs…

                          Moi, quand j’ai vu l’exemple de la liste de fibo infinie, et on demande la valeur qu’on veut, comme l’index de la liste, je me suis mis en tête de faire la même pour les nombres premiers. Je suis d’accord que dans ce cas, l’exercice est intéressant pour le style, pour la lisibilité…

                          prem = 2:[a | a <- [3,5..], (product (map (\x -> mod a x) ([3,5..truncate(sqrt (fromIntegral a::Float))]))) /= 0 ]
                          prem' = 2:[a | a <- [3,5..], (product (map (\x -> mod a x) (takeWhile (<= truncate(sqrt (fromIntegral a::Float))) prem'))) /= 0 ]
                          prem'' = 2:[a | a <- [3,5..], (all (/= 0) (map (\x -> mod a x) (takeWhile (<= truncate(sqrt (fromIntegral a::Float))) prem''))) ]

                          Il m’a fallu deux jours pour aboutir… la version la plus rapide est la liste prem''.

                          Sinon, je trouve haskell plutôt simple et clair. Il faut rentrer dans le langage, mais comme dans tous. On peut y écrire des trucs affreux comme dans tous.

                    • [^] # Re: Rust vs Go

                      Posté par (page perso) . Évalué à 4.

                      par analogie, trop spécifiques au langage

                      Donc en fait tu n'utilises pas ce qui est offert par ton langage ?
                      J'avoue avoir du mal à comprendre. C'est parce que tu n'arrives pas à relire plus tard ? Dans ce cas c'est pas plutôt un problème d'apprentissage du langage ?

                  • [^] # Re: Rust vs Go

                    Posté par (page perso) . Évalué à 1.

                    Quand tu écris français cherche-tu a limiter ton vocabulaire et à utiliser des phrases courtes et simples pour faciliter la vie des non-francophones ?

                    Personnellement, oui. Mais ça n’est pas qu’une histoire de non-francophones, je pense simplement qu’il est inutile de faire compliqué pour la clarté, quand on est fatigué, les handicapés mentaux, et effectivement les non-francophones.

                    Mais en effet, je ne vais pas utiliser une paraphrase là où un ou deux mots pas trop tordus suffisent parce que ça permettrait aux non-francophones de comprendre.

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

                    • [^] # Re: Rust vs Go

                      Posté par . Évalué à 5.

                      Personnellement, oui.

                      Alors tu devrais éviter les phrases à rallonge avec une foule de propositions comme :

                      Mais ça n’est pas qu’une histoire de non-francophones, je pense simplement qu’il est inutile de faire compliqué pour la clarté, quand on est fatigué, les handicapés mentaux, et effectivement les non-francophones.

                      C'est plus pénalisant qu'une question de vocabulaire pour le lecteur.

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

                      • [^] # Re: Rust vs Go

                        Posté par (page perso) . Évalué à 3.

                        Certes, mais ça n’est qu’une énumération. De plus, je n’ai pas dit que je cherchais la simplicité par-dessus tout, mais que c’était un critère auquel je donne de l’importance.

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

                • [^] # Re: Rust vs Go

                  Posté par (page perso) . Évalué à 2.

                  Tu peux détailler un peu plus, histoire de bien comprendre ?

                  myArray = []
                  mySelection = myArray.select { |value| value.even? }

                  Bon, ok la syntaxe { |…| } peut perturber si on ne connait pas ruby.
                  Peut-être qu'un

                  myArray = []
                  mySelection = myArray.select do |value|
                    value.even?
                  end

                  peut aider, mais bref c'est un faux problème qui n'est pas le notre, là c'est juste être capable de lire les constructions de base du langage. C'est comme discuter de * et & en C++.

                  Donc ensuite, qu'est ce qu'on a ?
                  On a un objet qui reçoit le résultat de l'appel de la méthode select sur un tableau myArray. On en déduit quand même facilement (= juste en lisant les mots) qu'on réalise une sélection de myArray.
                  Ensuite un bloc est passé, et on retourne un booléen un pour chaque valeur, ici vrai s'il est pair.
                  Ben je sais pas mais moi quand je lis tout ça je lis "mySelection est la sélection de myArray en gardant les pairs".

                  Le truc c'est que si tu lis la première version du extrapole un comportement (qui est de sélectionner les pairs) alors qu'il est explicite dans la version concise.

                  mais pour moi c’est incompréhensible au premier abord

                  C'est un problème de concision, de langage ou de n'utiliser qu'un ensemble très réduit d'instructions, un dénominateur commun basique et pauvre qu'on retrouve partout ?

                  • [^] # Re: Rust vs Go

                    Posté par (page perso) . Évalué à 2.

                    Perso je me pose moins de question avec:

                    myArray = []
                    mySelection = [ x for x in myArray if x%2==0 ]

                    Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

                    • [^] # Re: Rust vs Go

                      Posté par (page perso) . Évalué à 6.

                      Honnêtement je suis moins habitué aux x for x in mais c'est parce que je fais pas beaucoup de python. Mais ça reste concis et lisible.

                      Par contre, je note deux grosses différences qui me font préférer la version ruby :

                      • avoir x.even? au lieu de x % 2 == 0 est pour moi plus clair. Dans un cas on dit clairement ce qu'on souhaite, quel est le but (un pair) dans l'autre on donne une formule et on en déduit qu'on veut un pair
                      • avoir myArray.select au lieu de x for x in myArray if Idem, dans un cas on dit ce qu'on veut (sélectionner) dans l'autre on doit le déduire (si je met un test c'est que je ne les prend pas tous donc je fais une sélection)

                      En gros dans un cas on dit ce qu'on fait, dans l'autre on décrit des actions et on en déduit une volonté.

                      • [^] # Re: Rust vs Go

                        Posté par (page perso) . Évalué à 2. Dernière modification le 04/11/14 à 20:12.

                        Si on veut se rapprocher de l'idée Ruby.

                        def even(x):
                            return x%2==0

                        (désolé, even n'existe pas en standard en Python à ma connaissance - peut-être dans numpy)

                        Puis simplement:

                        myArray = []
                        mySelection = filter(even, myArray)

                        (bon, ça retourne un itérateur, si on veut les valeurs dans une liste: mySelection = list(filter(even, myArray)))

                        Bon, avec la fonction on peut aussi écrire l'expression de liste-compréhension de façon plus claire:

                        mySelection = [ x for x in myArray if even(x) ]

                        Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

                  • [^] # Re: Rust vs Go

                    Posté par . Évalué à 1.

                    mySelection = myArray.select { |value| value.even? }

                    J'aime bien ruby donc je comprend, mais je pense que dans le cas inverse je m'attendrai presque à ce qu'il me renvoi un tableau de booléen
                    En l'occurrence je préfère dans ce cas la construction python avec les listes en compréhension

                    • [^] # Re: Rust vs Go

                      Posté par . Évalué à 3.

                      select me semble pourtant clair. Tu préfèrerais filter ou grepcomme en perl ?

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

                      • [^] # Re: Rust vs Go

                        Posté par . Évalué à 2.

                        non select est très bien, grep fait trop unixien

                        cest pas tant le nom de la méthode, cest surtout que je n'apprécie pas des masses les valeurs de retour implicites (trop souffert avec perl surement)
                        du coup je préférerais {|value| return value if value.even?} (non valable en ruby), ou en pratique j'écrirais {|value| value if value.even?} qui me parait plus lisible

                        • [^] # Re: Rust vs Go

                          Posté par . Évalué à 4.

                          retour implicites (trop souffert avec perl surement)

                          Je ne me souviens plus d'où il y en a en perl, mais ça vient surtout des langages fonctionnels comme haskel, personnellement je trouve ça très propre. Justement ta forme et la compréhension de liste de python ne sont pas DRY du tout (tout à fait inutilement et piégeux AMHA).

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

                        • [^] # Re: Rust vs Go

                          Posté par (page perso) . Évalué à 4.

                          en pratique j'écrirais {|value| value if value.even?} qui me parait plus lisible

                          En fait dans l'exemple que j'ai donné on retourne un booléen qui indique si on prend ou non la valeur.
                          Sans le return implicit ça donne juste { |value| return value.even? }
                          On est dans le cas d'une sélection où on indique si on doit sélectionner ou non la valeur et pas renvoyer la valeur (ce qui a un sens différent au final).

                    • [^] # Re: Rust vs Go

                      Posté par (page perso) . Évalué à 2.

                      si tu avais un each oui, mais vu que tu as un select tu dis quand même clairement que tu réalises une sélection

                  • [^] # Re: Rust vs Go

                    Posté par . Évalué à 3.

                    Je vais te retourner la question. Que penses-tu de :

                    std::vector<int> v1, v2 = { … }
                    std::copy_if(v2.begin(), v2.end(), std::back_inserter(v1), [](int x) { return x%2 == 0; })
                    

                    Cette structure est triviale en C++. Et elle se comprend très bien telle qu’elle (au moins aussi bien que ta structure ruby), et est concise.

                    Maintenant, replace la dans un contexte, à savoir, au milieu d’autres structure du même type, peut-être dans une boucle, bref. J’estime être pas mauvais en C++, je travaille avec quotidiennement, j’ai l’habitude d’en lire, et pourtant, quand j’écris du code, j’évite ce genre de trucs. Au final, la forme que je vais utiliser, c’est beaucoup plus :

                    copy_even_numbers(v2, v1); // là, je vois tout de suite ce que ça fait, et je suis sûr que tout le monde comprend
                    

                    Et pour l’implémentation de copy_even_numbers, qu’elle fasse une ligne ou 4 ne change finalement pas grand chose. Si j’opte au final pour la forme du std::copy_if, c’est parce que je sais qu’elle est plus efficace qu’une boucle naïve.

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

                    • [^] # Re: Rust vs Go

                      Posté par . Évalué à 4.

                      Maintenant, replace la dans un contexte, à savoir, au milieu d’autres structure du même type, peut-être dans une boucle, bref. J’estime être pas mauvais en C++, je travaille avec quotidiennement, j’ai l’habitude d’en lire, et pourtant, quand j’écris du code, j’évite ce genre de trucs.

                      AMHA le problème vient plus de la taille de la ligne (c++ n'est pas aussi concis qu'on voudrait le croire) et à ta place je pense que je nommerais le prédicat et une ligne de cette forme :

                      std::copy_if(v2.begin(), v2.end(), std::back_inserter(v1), isEvent);

                      Bizarrement on passe sous la barre des 80 colonnes et on gagne en lisibilité.

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

                    • [^] # Re: Rust vs Go

                      Posté par (page perso) . Évalué à 4.

                      Cette structure est triviale en C++. Et elle se comprend très bien telle qu’elle (au moins aussi bien que ta structure ruby), et est concise.

                      Oué, faut pas déconner quand même.
                      C'est pas trivial vu le nombre de dev c++ qui ne comprennent pas les lambda, et c'est pas concis non plus.
                      Et c'est pas aussi expressif (even? l'est beaucoup plus)

                      • [^] # Re: Rust vs Go

                        Posté par . Évalué à 0.

                        Oué, faut pas déconner quand même.
                        C'est pas trivial vu le nombre de dev c++ qui ne comprennent pas les lambda, et c'est pas concis non plus.

                        Amusant que tu répondes ça. Pour moi ce code est aussi trivial que l’est la forme ruby que tu as donnée pour toi. Et la syntaxe des lambdas se comprend en deux minutes…

                        Et c'est pas aussi expressif (even? l'est beaucoup plus)

                        Cf la réponse de michel à propos de nommer le prédicat. Mais quitte à nommer, je préfère nommer la ligne entière : la lisibilité est nettement meilleure, pour tout le monde.

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

                        • [^] # Re: Rust vs Go

                          Posté par (page perso) . Évalué à 3.

                          Amusant que tu répondes ça

                          Pas tant que ça.
                          Autant des devs ruby qui ne comprennent pas { |plop| … } j'en connais pas, autant des devs c++ qui ne comprennent pas les lambda j'en connais.
                          C'est triste. (bon par contre moi j'aime bien les lambdas en C++ et je les utilises autant qu'en ruby j'utilise ce qui est possible)

                          Cf la réponse de michel à propos de nommer le prédicat.

                          Oui mais ça veut dire qu'il faut sortir le IsEvent ailleurs donc au final on ne fait que déplacer le problème.
                          Et reste qu'on perd l'idée de sélection, il faut l'extraire par la compréhension du code.

                          • [^] # Re: Rust vs Go

                            Posté par . Évalué à 4.

                            Oui mais ça veut dire qu'il faut sortir le IsEvent ailleurs donc au final on ne fait que déplacer le problème.

                            On le rend testable ! Et on si pour les nombres pairs ça paraît trivial sortir les concepts métier me semble une bonne pratique.

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

                        • [^] # Re: Rust vs Go

                          Posté par . Évalué à 3.

                          je préfère nommer la ligne entière : la lisibilité est nettement meilleure, pour tout le monde.

                          Alors en fait pour moi, non. Se contenter de sortir la lambda et la nommer ça permet de la réutiliser ailleurs (parce que normalement ta lambda a un sens "métier") et ça permet de garder une forme générique pour le filtrage plutôt que de multiplier les helpers qui ont très peu de valeur ajouté et qui ne respectent pas forcément tous la même convention de nommage (toi tu l'appel copy_even_numbers, mais ton voisin l'aurait peut être appelé keep_even).

                          Donc personnellement à réduire encore j'écrirais plutôt une méthode qui prend un prédicat et 2 vecteurs ou un prédicat, un vecteur et un itérateur. Ça permet d'écrire bien moins de code avec une grosse ré-utilisabilité et d'avoir toujours la même manière de faire la même chose partout dans ton code.

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

                    • [^] # Re: Rust vs Go

                      Posté par . Évalué à 8. Dernière modification le 04/11/14 à 18:35.

                      Tu as quand même vachement plus de bruit là dedans en C++ relativement à la version Ruby: v2.begin(), v2.end() juste pour dire « la totalité de v2 », std::back_inserter(v1) juste pour dire v1, et dans cette version tu dois te poser la question « est-ce que je copie v1 dans v2 ou v2 dans v1 ? », la réponse est certes triviale et déductible en 5s même pour moi qui connaît pas l’API, mais dans la version Ruby c’est 0s, j’ai une assignation avec une sortie à gauche et une entrée à droite.

                      Et je dis ça, je fais aussi peu de Ruby que de C++.

      • [^] # Re: Rust vs Go

        Posté par . Évalué à 3.

        peut on en 2014 faire un langage «accessible» qui produit du code robuste (ce que ni Haskell, ni Scala, ni OCaml n'ont réussi à faire par exemple) ?

        C'est marrant, c'est pas la manière dont j'avais envisagé rust. J'aurais plutôt dit que l'objectif c'est de fiare un langage performant, qui ne sacrifie pas le contrôle que possède le développeur sur la gestion de la mémoire pour obtenir de la robustesse.

        C'est quelque chose que ni ocaml, ni haskell, ni scala n'ont essayé de faire.

    • [^] # Re: Rust vs Go

      Posté par . Évalué à 2.

      Puisque Rust est apparemment en concurrence avec Go en tant que "language compilé généraliste qui va remplacer C++"

      Plus le temps passe et plus je pense que rien ne va remplacer le c++, j'ai espéré pendant longtemps que le D prenne plus d'ampleur puis c++11 est arrivé et je me dis que j'ai de moins en moins besoin d'un autre langage. Bien sur il me manque encore certaines choses qui pourraient être sympa comme la reflection, la standardisation de l'accès au fichiers, … Mais personnellement je ne crois pas trop à la génaralisation de ce langage (et j'espère vraiment me tromper).

      • [^] # Re: Rust vs Go

        Posté par (page perso) . Évalué à 6.

        Plus le temps passe et plus je pense que rien ne va remplacer le c++, j'ai espéré pendant longtemps que le D prenne plus d'ampleur puis c++11 est arrivé et je me dis que j'ai de moins en moins besoin d'un autre langage.

        D est boiteux:

        • Ça se barre dans tous les sens: deux bibliothèques standard concurrentes pendant très longtemps (celle maintenue par la communauté n’est plus maintenue on dirait), compilateur officiel DMD avec des fuites de mémoire, GCD basé sur GCC n’est plus très actif, LDC qui ne fonctionnaient pas trop bien pendant un moment.
        • Trop de fonctionnalités — ramasse-miettes, programmation par contrat, des exceptions, des templates, etc. À mon avis ils y en avait un peu trop.
        • Très peu de logiciels en D
        • Pas de gros organisme derrière

        Rust, au contraire:

        • Sa bibliothèque standard qui est le résultat d’un consensus entre les développeurs
        • le nombre de fonctionnalités du langage a diminué et les plus pertinentes se retrouvent dans la bibliothèque standard
        • Deux gros projets (le compilateur Rust et Servo) utilisent Rust mais ce sont loin d’être les seuls
        • Il y a Mozilla derrière (et Samsung pour Servo)
        • Il arrive plus tard, une période où de nombreux langages émergent et où l’on veut plus d’un énième copié-collé qui reprend les erreurs du passé, où les développeurs doivent souvent travailler avec plus d’un langage, où la parallélisation et surtout la sécurité sont importantes.

        De plus, il est très probable que l’activité autour de Rust, déjà importante au stade auquel est le langage, s’intensifiera à la sortie de la première version stable.

        Bien sur il me manque encore certaines choses qui pourraient être sympa comme la reflection, la standardisation de l'accès au fichiers, … Mais personnellement je ne crois pas trop à la génaralisation de ce langage (et j'espère vraiment me tromper).

        Les fichiers d’entêtes en 2014, sérieusement.

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

        • [^] # Re: Rust vs Go

          Posté par . Évalué à 3.

          Même constat pour D, et tu oublies les gros changements entre D v1 et D v2. J'ai vite laissé tomber.

          Il y a Mozilla derrière (et Samsung pour Servo)

          C'est pour moi le point qui m’effraie le plus au vue de la longue liste de managements piteux de Mozilla dans le passé (XUL, SpiderMonkey, etc). Mais le projet semble très autonome depuis le début ce qui est bon signe.

          • [^] # Re: Rust vs Go

            Posté par (page perso) . Évalué à 5.

            Oui enfin chez Mozilla il y a aussi plein de trucs qui sont bien, comme Firefox, Thunderbird (plus de nouvelles fonctionnalités développées par Mozilla, certes…), asm.js, du boulot sur emscripten, Firefox OS (qui a l’air de bien évoluer pour le moment), etc.

            Puis le fait qu’ils payent des gens pour travailler sur Rust c’est quand même plutôt bien. Mais effectivement, ils n’utilisent pas l’infrastructure de Mozilla par exemple, ces derniers sont «simplement» sponsors (en tout cas c’est ce qui est dit dans le wiki sur le Github de Rust).

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

  • # Graphviz

    Posté par (page perso) . Évalué à 2.

    Un des seuls langages au monde que je connaisse intégrant Graphviz dans sa bibliothèque standard. J'ai du mal à voir ce que ce module vient faire dans un langage supposé "système".

    l'azerty est ce que subversion est aux SCMs

    • [^] # Re: Graphviz

      Posté par . Évalué à 4.

      Au pif, c’est nécessaire à rustdoc, et quitte à l’avoir autant que ça soit dans la bibliothèque standard ?

      Mais c’est vrai que c’est un peu bizarre comme décision.

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

    • [^] # Re: Graphviz

      Posté par . Évalué à 3.

      C'est pas inclut dans R ?

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

    • [^] # Re: Graphviz

      Posté par . Évalué à 2. Dernière modification le 03/11/14 à 20:36.

      On dirait que le menu de gauche sur la page de la doc std affiche la liste des crates utilisées par Rust, alors que celui présent sur les pages des modules de la std affiche la liste qu'on attendait (voir par ex. sur std::ptr).

      Et pour pinailler : le module en question ne fait « que » générer des graphes au format dot (donc pas de dépendance à Graphviz).

    • [^] # Re: Graphviz

      Posté par (page perso) . Évalué à 1.

      Je ne suis pas expert en Rust, mais le crate graphviz ne fait pas partie de "std", c'est a dire qu'il est la si tu en as besoin, mais c'est une bibliotheque separer et sur laquelle tu ne link pas de maniere implicite.

      Donc en gros sa presence n'est pas genante vu qu'elle n'alourdit pas un programme qui ne l'utilise pas.

  • # Web

    Posté par . Évalué à 2.

    Concernant l’aspect Web, j'attends avec impatience l'avènement de Teepee dont l'auteur avait déjà commencé rust-http. Voir d'ailleurs son blog pour quelques détails d'implémentations.

    Il semble aussi posséder une grande vision sur ce que devrait être un framework Web. Mais le problème avec ce genre de vision c'est quelles ne voient souvent pas le jour.

  • # @propos Computer Language Benchmark Game

    Posté par (page perso) . Évalué à 2.

    Je ne connaissais pas ce benchmark et j'ai donc jeté un oeil sur le site de Computer Language Benchmark Game.
    Quelqu'un a-t-il regardé la nature des algorithmes mis en avant ? Vu rapidement, je suis quand même fortement étonné du décalage complet entre le type d'algo du benchmark et quelques usage pourtant majoritaires aujourd'hui des ordinateurs à savoir, le traitement massif de petites requêtes indépendantes et donc facilement parallélisable. À part l'accès à des arbres binaires, je ne vois pas en quoi du pur calcul (pidigits, mandelbrot, …) permet de juger de la performance d'un langage dans ce cas d'utilisation, pourtant majoritaire.

    A moins qu'on ne se mette à écrire des langages pour satisfaire aux benchmarks ???

  • # Cargo sous Linux

    Posté par (page perso) . Évalué à 2.

    Selon la page du projet, si on veut obtenir Cargo sous Linux:

    curl https://static.rust-lang.org/rustup.sh | sudo bash

    Pas terrible terrible. Je n'aime pas vraiment qu'un programme vienne s'installer je ne sais où, sans que je sache comment je vais le désinstaller/mettre à jour proprement.

    Il y a un PPA pour Ubuntu, mais la dernière version dispo date de plusieurs mois et ne compile pas des projets récents.

    Alors pour moi qui connait le confort d'utiliser Maven en Java (qui récupère toutes les dépendances), un outil comme ça est quasi-indispensable pour ma productivité. Mais son installation me fait peur.

    • [^] # Re: Cargo sous Linux

      Posté par (page perso) . Évalué à 4.

      Ce n'est pas la seule façon d'installer cargo :

    • [^] # Re: Cargo sous Linux

      Posté par . Évalué à 5.

      C'est un vieux débat qui a enflamé la mailing list. Je trouve ca stupide d'empecher une méthode simple d'installer un logiciel alors que les autres méthodes ne le sont pas plus. A un moment on execute un sudo make install et donc c'est exactement pareil, si on veut y placer un rm -rfv / au millieu, on peut, dans les 2 cas.

      Utiliser le PPA oui c'est pour ceux qui sont sous ubuntu. Pour les autres, il faut une procédure d'installation, quite à expliquer pourquoi c'est une mauvaise idée, mais tout en la laissant quand même.

Suivre le flux des commentaires

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