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 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
É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
- Le blog de Rust ;
- forum du site officiel ;
- this week in Rust ;
- une comparaison entre Rust, Haskell et Go
-
Reddit - The Rust programming language
- Le subreddit de rust est actif et compte la présence de développeurs rust et servo d'où des réponses en général très pointues. Des exemples de liens passés sur le subreddit :
- Rust Means Never Having to Close a Socket ;
- why your first FizzBuzz implementation may not work: an exploration into some initially surprising but great parts of Rust.
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.
Aller plus loin
- Site officiel de Rust (343 clics)
- Annonce de la version 0.12 (27 clics)
- Tag `rust` sur LinuxFr.org (journaux et dépêches sur Rust) (74 clics)
- Tag `langage_rust` sur LinuxFr.org (62 clics)
- Le guide de Rust, idéal pour découvrir le langage (191 clics)
# Une petite question
Posté par reno . Évalué à 3.
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 Uther Lightbringer . É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 ariasuni . Évalué à 3.
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 Stibb . É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 nazeman (site web personnel) . É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 cozo . É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 patrick_g (site web personnel) . Évalué à 3.
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 JoeltheLion (site web personnel) . É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 Benoît Laurent (site web personnel) . Évalué à 3.
À ce sujet il y a une interview de Steve Klabnik (qui est la personne qui est en charge de la doc de rust à Mozilla):
Interview with Steve Klabnik: How Rust Compares to Other Languages and More - Codementor
Voir aussi le fil reddit : https://www.reddit.com/r/rust/comments/2kkqjw/steve_klabnik_how_rust_compares_to_other/
[^] # Re: Rust vs Go
Posté par JGO . Évalué à 4. Dernière modification le 03 novembre 2014 à 12:56.
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 Uther Lightbringer . Évalué à 4. Dernière modification le 03 novembre 2014 à 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 Sébastien Douche . É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 Physche . É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 JGO . É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 barmic . Évalué à 7.
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.
Il a 3 ans d'avance, il est plus facile d'accès, il bénéficie de l'appuie de google.
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 whity . Évalué à 6.
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 barmic . Évalué à 7.
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).
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.
En est d'accord, comme le C, il est simple.
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.
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 ariasuni . Évalué à 4.
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 Xinfe (site web personnel) . Évalué à 6.
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 JGO . Évalué à 1. Dernière modification le 04 novembre 2014 à 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 LupusMic (site web personnel, Mastodon) . Évalué à 1.
C'est d'ailleurs pour ça que C# a un comportement indéfini B-)
[^] # Re: Rust vs Go
Posté par CrEv (site web personnel) . Évalué à 5.
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 whity . Évalué à 1.
Les choses ont pas mal évoluées depuis les dernières fois où j’avais regardé, mais :
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 CrEv (site web personnel) . Évalué à 4.
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 reno . É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 Blackknight (site web personnel, Mastodon) . Évalué à 2.
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 CrEv (site web personnel) . Évalué à 5.
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 rakoo (site web personnel) . Évalué à 10.
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 barmic . Évalué à 5.
La phrase m'a choquée au début, mais finalement je suis plutôt d'accord.
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 Uther Lightbringer . É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 jeberger (site web personnel) . Évalué à 4.
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 patrick_g (site web personnel) . Évalué à 3.
Pourquoi est-ce que l'article Wikipédia de Rust indique "Appeared in : 2012" ?
[^] # Re: Rust vs Go
Posté par jeberger (site web personnel) . Évalué à 1.
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 Sébastien Douche . É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 xcomcmdr . Évalué à 6. Dernière modification le 03 novembre 2014 à 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 :
qu'un
voire un
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 Moonz . Évalué à 5. Dernière modification le 04 novembre 2014 à 05:48.
Heu non, le code équivalent en Go à ton code C#/Ruby ce serait plutôt au choix :
[^] # Re: Rust vs Go
Posté par barmic . Évalué à 5.
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 xcomcmdr . É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 barmic . Évalué à 7.
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, unforou unforeachavec au choix unbreak/returnou une condition après la boucle). Une commeexisten 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 CrEv (site web personnel) . Évalué à 7.
vs
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 :
ou alors
On a, à mon avis, plus compact et plus lisible.
[^] # Re: Rust vs Go
Posté par xcomcmdr . É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 CrEv (site web personnel) . Évalué à 4.
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
selectparsdans 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 whity . É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 :
sont nettement plus lisibles que :
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 :
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 xcomcmdr . É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 Moonz . Évalué à 9.
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 barmic . Évalué à 5.
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 xcomcmdr . É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 CrEv (site web personnel) . Évalué à 3.
C'est comme tout, il y a les bonnes et les mauvaises utilisations.
Mais genre :
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 Anthony Jaguenaud . Évalué à 2.
Je crois que le problème vient plus de l’usage détourné de certaines spécificités :
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 barmic . É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.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 barmic . É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 :
const/finalsans avoir à créer une méthode pour çaTous 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 CrEv (site web personnel) . Évalué à 3.
Ça c'est aussi que certains langages ne permettent pas des trucs cool.
En ruby on peut très bien avoir :
[^] # Re: Rust vs Go
Posté par whity . É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 Dr BG . Évalué à 4.
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 groumly . É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 whity . Évalué à 2.
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 barmic . Évalué à 4.
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.
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
whilede 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 whity . Évalué à 0.
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…
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 CrEv (site web personnel) . Évalué à 2.
Oui mais c'est quoi intuitive ?
[^] # Re: Rust vs Go
Posté par barmic . Évalué à 6.
Je comprends pas un mot de russe, pourtant les russes le parlent depuis leur plus tendre enfance.
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é.
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.
"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.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 whity . Évalué à 2.
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.
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
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
réussit à être à la fois plus lisible et plus concis en toute circonstance, mais que
est en général inférieur en lisibilité à
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 barmic . Évalué à 3.
Je déteste cette forme !
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) :
Je préfèrerais toujours écrire :
Bien sûr le
aValuedoit avoir un sens métier. L'énorme avantage c'est :aest initialisé dès sa création donc on peut le déclarerconsta, on voit immédiatement que sa valeur dépend debet decTous 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 whity . Évalué à 2.
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 djano . Évalué à 2.
Je préfère nettement ceci:
Voire même:
[^] # Re: Rust vs Go
Posté par barmic . Évalué à 5.
Je suis partisan d'un seul
returnsurtout 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 djano . É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 barmic . Évalué à 3.
Si tu lis le fil, tu saura que pour moi normalement il y a 1 à 2 lignes pas plus.
Pour ça que je parle de cas simples, mais tu gagne beaucoup en maintenance.
D'où le fait que je parle de cas simples.
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.
returnamé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 djano . Évalué à 3.
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 barmic . Évalué à 3.
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 djano . É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 barmic . Évalué à 4.
Un cas simple c'est ça :
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 whity . É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 Anthony Jaguenaud . Évalué à 4.
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 :
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 djano . Évalué à 3.
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.
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 barmic . Évalué à 3.
Encore une fois méthode trop longue.
Le signe de méthode trop longue, s'il y a des sous parties c'est qu'il faut découper.
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 :
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 unreturnquand 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 djano . É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 groumly . É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 barmic . Évalué à 5.
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 groumly . Évalué à 4.
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".
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.
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.
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 barmic . É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 anaseto . Évalué à 3.
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 Anthony Jaguenaud . Évalué à 2.
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é…
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 CrEv (site web personnel) . Évalué à 4.
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 ariasuni . Évalué à 1.
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 barmic . Évalué à 5.
Alors tu devrais éviter les phrases à rallonge avec une foule de propositions comme :
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 ariasuni . É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 CrEv (site web personnel) . Évalué à 2.
Tu peux détailler un peu plus, histoire de bien comprendre ?
Bon, ok la syntaxe
{ |…| }peut perturber si on ne connait pas ruby.Peut-être qu'un
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
selectsur un tableaumyArray. On en déduit quand même facilement (= juste en lisant les mots) qu'on réalise une sélection demyArray.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.
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 lolop (site web personnel) . Évalué à 2.
Perso je me pose moins de question avec:
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Rust vs Go
Posté par CrEv (site web personnel) . É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 :
x.even?au lieu dex % 2 == 0est 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 pairmyArray.selectau lieu dex for x in myArray ifIdem, 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 lolop (site web personnel) . Évalué à 2. Dernière modification le 04 novembre 2014 à 20:12.
Si on veut se rapprocher de l'idée Ruby.
(désolé, even n'existe pas en standard en Python à ma connaissance - peut-être dans numpy)
Puis simplement:
(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:
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Rust vs Go
Posté par Alex . É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 barmic . Évalué à 3.
selectme semble pourtant clair. Tu préfèreraisfilterougrepcomme 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 Alex . É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 barmic . Évalué à 4.
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 CrEv (site web personnel) . Évalué à 4.
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 Moonz . Évalué à 3.
Heu non,
returndans un bloc n’est pas un retour du bloc mais de la méthode contenant le bloc.http://stackoverflow.com/questions/2325471/using-return-in-a-ruby-block
[^] # Re: Rust vs Go
Posté par CrEv (site web personnel) . Évalué à 2.
Voui, bien vu, en fait je ne l'écris jamais donc j'ai supposé, j'aurais du vérifier.
Dans tous les cas on ne retourne pas la valeur, c'était surtout ça ;-)
[^] # Re: Rust vs Go
Posté par CrEv (site web personnel) . Évalué à 2.
si tu avais un
eachoui, mais vu que tu as unselecttu dis quand même clairement que tu réalises une sélection[^] # Re: Rust vs Go
Posté par whity . Évalué à 3.
Je vais te retourner la question. Que penses-tu de :
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 :
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 barmic . Évalué à 4.
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 :
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 CrEv (site web personnel) . Évalué à 4.
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 whity . Évalué à 0.
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…
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 CrEv (site web personnel) . Évalué à 3.
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)
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 barmic . Évalué à 4.
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 barmic . Évalué à 3.
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 Moonz . Évalué à 8. Dernière modification le 04 novembre 2014 à 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 direv1, 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 Enj0lras . Évalué à 3.
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 mosfet . Évalué à 2.
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 ariasuni . Évalué à 6.
D est boiteux:
Rust, au contraire:
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.
Les fichiers d’entêtes en 2014, sérieusement.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Rust vs Go
Posté par Sébastien Douche . Évalué à 3.
Même constat pour D, et tu oublies les gros changements entre D v1 et D v2. J'ai vite laissé tomber.
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 ariasuni . É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 David Demelier (site web personnel) . É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".
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Graphviz
Posté par whity . É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 barmic . É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 potate . Évalué à 2. Dernière modification le 03 novembre 2014 à 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 Allan Simon (site web personnel) . É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 Spack . É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 Jean Parpaillon (site web personnel) . É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 ???
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
# Cargo sous Linux
Posté par Fabimaru (site web personnel) . Évalué à 2.
Selon la page du projet, si on veut obtenir Cargo sous Linux:
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 CrEv (site web personnel) . Évalué à 4.
Ce n'est pas la seule façon d'installer cargo :
[^] # Re: Cargo sous Linux
Posté par Stibb . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.