Rust s’oxyde en version 0.10

Posté par ariasuni le 08 avril 2014 à 21:27. Édité par olivierweb, BAud, sebcrozet, Fabien, Leo, Bruno Michel, Nÿco, jcr83, reno, stiffux, Ontologia et bubar🦥. Modéré par patrick_g. Licence CC By‑SA.

Étiquettes :

avr.

2014

Mozilla et la communauté Rust ont annoncé la version 0.10 de Rust le 3 avril. Rust est un langage de programmation développé par Mozilla. La version 0.1 a été annoncée par Mozilla le 20 janvier 2012. Pour découvrir le langage, on peut se référer au nouveau site web sur lequel on peut lire :

Rust est un langage de programmation système qui est extrêmement rapide, empêche presque tous les plantages et élimine les accès concurrent.

Rust se veut donc une alternative à C/C++, comme D et Go, et possède tout comme ces derniers un ramasse-miettes, mais qui est optionnel. Sa syntaxe est proche de celle du C/C++/Java tout en étant beaucoup plus expressif. Sa force est de mélanger les fonctionnalités de différents paradigmes, beaucoup venant du fonctionnel (immuabilité par défaut, modèle objet proche de celui d'Haskell, fermetures, etc). Il met l'accent sur la sûreté d'exécution, notamment grâce à son système élaboré de pointeurs intelligents et son système de types forts, sans sacrifier les performances.

Depuis la version 0.9, qui a fait l’objet d’une dépêche, les efforts ont notamment porté au cours des 1500 changements sur la simplification du langage. Le langage Rust n'est pas stabilisé, cela viendra avec la version 1.0.

Cette itération de développement a apporté le découpage de la bibliothèque libextra, introduit des extensions de syntaxe inter crate, amélioré la manipulation des pointeurs avec le trait Deref et la gestion des erreurs des entrées/sorties.
En dehors du compilateur, cette nouvelle version a vu l'introduction d'un nouveau processus de RFC ainsi que la construction quotidienne des installateurs binaires.

Des améliorations ont été données à l'infrastructure de tests et aux scripts de construction. Des installeurs sont désormais disponibles pour Linux, MacOS et Windows. Même si certains font tourner Rust sur ARM, ce n'est pas une architecture proposée dans la documentation.

Comme pour les précédentes versions, cette version 0.10 doit être considérée comme une version alpha, appropriée pour les adopteurs précoces et les amateurs de langages.

Sommaire

Changements du langage

Vous pouvez consulter les notes de version officielles, mais ne vous inquiétez pas, on vous résume tout plus bas.

Syntaxe

Suppression de do. Il faut remplacer do spawn { ... } par spawn(proc() { ... }),
Paramètres de type par défaut dans les types génériques : il est désormais possible de spécifier un type de paramètre par défaut pour les types génériques (à activer avec un attribut de crate feature).

#![feature(default_type_params)]
struct Foo<T = char> { a: T }
struct Bar<A, B = int, C = (int,char)> {
    field1: A,
    field2: B,
    field3: C
}

Pour l'utilisation de bibliothèque, il faut utiliser extern crate au lieu de extern mod.
Suppression du filtrage par motif sur ~str. Il faut désormais utiliser as_slice() :

match s.as_slice() {
       "a" => do_a(),
       "b" => do_b(),
       _   => fail!("autre")
}

Déplacement de la macro debug! dans la bibliothèque log.
Modifications de la syntaxe des attributs de crate. Par exemple, au lieu de #[license = "MIT/ASL2"];, il faut utiliser #![license = "MIT/ASL2"] (sans point-virgule).
Suppression de Vec::map(), il faut utiliser les fonctions anonymes ou .iter().map().
Suppression de collections::List. On peut utiliser à la place Vec ou collections::DList si on veut vraiment une liste chainée.

Suppression des conditions

Les conditions ont été supprimées, cela change donc la façon de gérer les erreurs d’entrée/sortie.

Les conditions permettaient de gérer les erreurs un peu à la manière des exceptions en Java et C++, mais de manière sûre. Néanmoins c’était plus complexe à utiliser, et il était difficile de deviner quand la bibliothèque standard utilisait les Option/Result ou les conditions pour gérer les erreurs.

Dans la plupart des cas, il faut maintenant utiliser le filtrage par motif (pattern matching) sur les résultats des opérations. Par exemple, pour supprimer un fichier :

let path = Path::new("chemin/vers/fichier.txt");
match fs::unlink(&path) {
    Err(e) => fail!("L'ouverture de {:?} a échoué: {}.", path, e),
    _ => debug!("L'ouverture de {:?} a réussi.", path)
}

En effet, désormais toutes les opérations d’entrées/sorties renvoient un IoResult (qui est un petit alias de type : type IoResult<T> = Result<T, IoError>;).

On peut aussi utiliser la macro try!, qui arrêtera immédiatement le programme si la récupération du résultat échoue. Cela donne un code plus court dans les cas où l’arrêt du programme n’est pas un souci/est préférable :

let path = Path::new("chemin/vers/fichier.txt");
let file = try!(fs::unlink(&path));

Les traits `Deref` et `DerefMut`

Ce sont globalement une surcharge à l’opérateur *. Par exemple :

struct Foo { a: int }
impl Deref<int> for Foo {
    fn deref<'a>(&'a self) -> &'a int { &self.a }
}

let test = Foo { a: 3 };
println!("{}", *test); // affiche « 3 »
let borrowed: &int = &*test; // déréférence, mais ne déplace pas
println!("{}", *borrowed);

Le trait DerefMut permet la surcharge de la forme *test = value;, ainsi que de prendre une adresse mutable du contenu comme &mut *test.

Ces deux traits participent à la fonctionnalité d’auto-déréférencement du compilateur, rendant les pointeurs intelligents beaucoup plus faciles à utiliser. C’est une étape très importante, car après la disparation du pointeur @, on a commencé à utiliser les alternatives dans la bibliothèque standard qui étaient beaucoup moins pratiques, comme Rc<T>. Leur utilisation est maintenant beaucoup moins verbeuse et devient, dans plusieurs cas, transparente.

Modifications des durées de vie des valeurs temporaires

let slot = RefCell::new(1);
*slot.borrow_mut() = 4;
println!("{}", *slot.borrow());

Ce code ne compilait pas précédemment car l’information de durée de vie liée de la valeur renvoyée par slot.borrow_mut() n’était pas désallouée ; la slot.borrow() échouait alors (on ne peut emprunter (borrow) plusieurs fois une même variable en Rust). Désormais, l’information de durée de vie liée à une valeur temporaire est désallouée le plus tôt possible, c’est-à-dire ici à la fin de la ligne.

Modification du traitement des valeurs `static`

Les expressions static ne doivent pas être d’un type qui a un destructeur défini par l’utilisateur,
ne doivent pas avoir une valeur qui elle-même requiert un destructeur,
celles qui contiennent un Unsafe<T> ne peuvent avoir leur adresse prise,
enfin, les expression static mut ne doivent pas avoir de type qui nécessite un destructeur (défini par l’utilisateur ou non).

Bibliothèque standard

La fonction println a été déplacée dans le module std::io::stdio. Pour l'utiliser il faut la macro println! ou insérer use std::io::stdio::println;.
Les constantes ont été mises en capitales.
Amélioration de la vitesse de lancement des green threads
Les canaux ont été réécrits. Plutôt que d’utiliser feu SharedChan, Chan peut maintenant être cloné.
Réusinage de collections::list.
Le gestion des fichiers sous Windows a été réécrite et fonctionne désormais. rustc utilise maintenant libnative par défaut.
Il y a désormais un avertissement lorsqu’une méthode publique a un type privé qui apparait dans sa signature.
std::io::stdout() et stderr() sont maintenant bufferisés par défaut.
On peut maintenant utiliser des constantes littérales (les valeurs que l’on trouve directement derrière le = lors de l’initialisation d’une variable par exemple) au format hexadécimal flottant avec l’extension de syntaxe hexfloat!, par exemple let a = hexfloat!("0x1.999999999999ap-4"); ou let b = hexfloat!("-0x1.fffp-4", f32); (notez les deux façon d’appeler l’extension de syntaxe).
Les Hashmaps utilisent désormais le hachage de robin des bois. Voir ici pour plus d’informations sur les avantages de cet algorithme.

Extensions de syntaxe

Il est désormais possible de créer des extensions de syntaxe dans une crate et de l’utiliser dans une autre : c’est une limitation très ennuyeuse qui disparait ! Les extensions de syntaxe définies par l’utilisateur sont appelées macros et permettent de faire de la méta-programmation. Elles sont donc un outil puissant et non du sucre syntaxique !

Pour rappel, les extensions de syntaxe sont par exemple utilisées dans print! et println! pour la syntaxe « à la Python », il y a également des exemples dans la section d’au-dessus et d’en dessous !

DST

Depuis quelques temps, un travail est en cours pour prendre en charge les Dynamically-sized types (DST) dans Rust.

std::vec a été réécrite (dépréciée un temps au profit de std::vec_ng), et ~[T] a disparu.

Découpage

Afin d'avoir une séparation nette des fonctionnalités entre les modules et de pouvoir n'utiliser que les fonctionnalités nécessaires dans un module, std et extra sont découpées. On a donc désormais un std plus petit, et les modules résultant seront à terme gérés sur leur propre dépôt.

La documentation pour ces bibliothèques a ainsi été séparée.

libextra a été supprimée. Ses différentes fonctionnalités ont été séparées en plusieurs crates :

libarena
libcollections (dans laquelle a été migré std::trie ainsi que les types std::HashMap, std::HashSet et EnumSet)
libflate
libgetopts
libglob
libnum (contient désormais le trait Integer)
libsemver
libserialize (on y trouvera serialize::json qui a gagné une API à la JackonJSON).
libsync (modules de programmation concurrentielle)
libterm
libtest
libtime
libuuid
liburl
libworkcache

En outre, deux modules ont été extraits de la libstd :

librand
liblog

Ces découpages permettent également d’éviter les dépendances circulaires et donc de compiler plus de bibliothèques en parallèle. Cela devrait également améliorer légèrement les temps de compilation.

Compilateur

Avertissement pour les Result non-utilisés (désactivé par défaut).
Beaucoup d’options ont été enlevées et ajoutées, notamment ici.
Quelques optimisations sur la taille des binaires générés.
Les opérateurs composés (comme +=) ne peuvent plus être utilisés avec des variables potentiellement non-initialisées.
Le déréférencement est maintenant surchargeable. C’est une autre partie des changements sur les pointeurs intelligents. Un code tel que let x = *Rc::new(5) est maintenant valide. Il y a une pull request complémentaire qui déréférencera automatiquement les pointeurs intelligents lorsque approprié, pour éviter les expressions du type foo.borrow().get().borrow_mut().get() (ce qui facilitera l’utilisation des pointeurs de la bibliothèque standard qui remplacent @ et @mut).

LLVM aura bientôt un ramasse-miettes précis, le courriel annonce même que l’implémentation arrivera dans quelques mois (« pas dans quelques semaines ni dans quelques années ! »). Cela pourrait fournir une base solide à une implémentation d’un ramasse-miettes dans Rust.

Plateformes prises en charge

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

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

Autres outils

rustpkg qui avait été réécrit pour la version 0.9 a été supprimé, les sources avec leur historique et leurs bogues ont été extraites dans un projet sous GitHub.
Une réflexion avait été lancée sur la création d'une base de données des projets Rust pour la gestion des dépendances. 0install a reçu des avis positifs. Finalement cette idée ne sera pas retenue.
Un nouveau gestionnaire de paquets Cargo a été annoncé. Yehuda Katz et Carl Lerche, de Tilde Inc., ont à leur actif le gestionnaire de paquets Bundler pour Ruby et vont construire celui de Rust. Yehuda Katz a donné quelques précisions ici et là, en indiquant qu'ils utilisent déjà Rust en production dans leur entreprise.
Les demandes de fusion pull requests sur GitHub subissent désormais certains tests d'intégration automatiques dans Travis CI.
La coloration syntaxique a été ajoutée dans rustdoc.
rustdoc teste désormais tous les blocs de code.
Les codes inclus dans la documentation (par exemple dans le tutoriel) sont maintenant testés.

Autour du langage

Nick Cameron — alias nrc — a rejoint l'équipe de Mozilla dédiée à Rust, qui compterait désormais 6 personnes (discussion au MozSpace du 25 février). Nick a un doctorat en théorie des langages de programmation du Imperial College London (thèse intitulée Existential Types for Variance - Java Wildcards and Ownership Types), il travaillait depuis deux ans sur la composition et les graphiques de Gecko. Depuis, Aaron Turon a rejoint Mozilla Research à San Francisco. Une douzaine d’employés de Samsung s'occupent d’une autre partie du travail.

Un programme de triage de bugs a été lancé : si on s’inscrit, on reçoit une liste des plus vieux bugs afin de vérifier qu’ils sont toujours d’actualité, s’il y a des doublons, voire corriger le bug.

La façon dont sont traitées les RFC va évoluer, en effet la maturation du projet et l’activité toujours grandissante autour du langage nécessitaient un processus un peu plus rigoureux pour évaluer et implémenter les fonctionnalités de manière organisée.

Nouveau site web

Le thème du site web de Rust a été mis à jour, avec une présentation plus accrocheuse. On peut désormais télécharger des installateurs pour les plateformes Windows et Mac, et des binaires pour Mac ainsi que GNU/Linux, des versions 0.10 et nocturne.

Informations techniques

Une question a été posée sur Reddit : quels sont les types d’optimisation possibles en Rust ? (la plupart n’ayant malheureusement pas encore été implémentés, faute de temps)

La non-mutabilité par défaut permet de nombreuses optimisations, par exemple :

fn f(x: &int) {
    let y = *x;
    g();
    let z = *x;
    println(z.to_str());
}

L’optimiseur peut transformer cela de manière valide en :

fn f(x: &int) {
    let y = *x;
    g();
    println(y.to_str());
}

Et ce quelle que soit l’opération qu’effectue g(); car ici x est non-mutable (rappel : le mot mut doit être explicitement utilisé, comme ceci : fn f(mut x: &int)).

D’autre part, cela permettra aussi de faire des optimisations dans certaines boucles, par exemple en C/C++ :

int x = 0;
foo(&x);
for(int i = 0; i < x; i++) bar();

on ne sait pas si &x a été récupéré autre part depuis foo, ou si bar la modifie, on est donc obligé de recharger la valeur de x à chaque tour de boucle. En Rust, le compilateur sait si x a été emprunté ou pas. Remarque : ça n’est pas le plus beau bout de code que vous ayez vu mais il montre bien l’idée.

Vous pouvez aussi consulter une autre discussion à propos d’optimisations.

Chiffres

Depuis la dernière dépêche, Ohloh a mis à jour ses statistiques sur Rust. On peut ainsi voir que le nombre de personnes qui modifient du code Rust est relativement faible mais augmente (121 projets dans les projets recensés sur Ohloh). 1428 projets sont recensés sur GitHub.

Rust est le deuxième dépôt sur Github en nombre de tickets fermés sur l’année 2013, un chiffre très impressionnant qui donne une petite idée de l’énorme travail en cours sur le langage. Espérons que cette année soit au moins aussi fantastique pour Rust !

Computer Language Benchmark Game

Rust fait son entrée dans le fameux Computer Language Benchmark Game. Déjà avec un très bon benchmark, fasta. En effet, sur ce banc d’essai, Rust est aussi rapide que C++ en prenant moins de mémoire sans « tricher » (utiliser de bloc unsafe), contrairement à l’implémentation Haskell par exemple, qui utilise des unsafeUseAsCString et unsafeIndex.

D’autre part, on a aussi un mauvais banc d’essai, pidigits car l’implémentation de Rust, selon un des développeurs, « extra::bigint n’est pas tellement optimisé ni maintenu et est très très lent » et malgré un commit pour améliorer les performances de bigint (20× plus rapide). Il convient néanmoins de préciser que les meilleurs résultats sur ce benchmark sont réalisés par des programmes utilisant GMP.

Vous pouvez consulter la comparaison avec le C et le C++ sur X86-64. En comparant les résultats sur X86, on voit que les écarts sont moindres sur plateforme 64 bits. Rust n’a pas encore été vraiment optimisé (LLVM ne peut notamment pas effectuer certaines optimisations car on doit lui fournir plus d’informations), ce qui explique l’écart de performance encore important avec le C ou le C++, dont les compilateurs ont quand même plusieurs dizaines d’années d’optimisation derrière eux. De plus, la différence de performance avec un code lambda (qui ne sollicite pas de manière intensive la machine comme lors de ces bancs d’essai) est beaucoup plus faible.

Anecdotes

Sur Reddit, plusieurs utilisateurs indiquent pourquoi ils ont choisi Rust plutôt que d’autres langages.

Il a été de nombreuses fois demandé si Rust prendrait en charge les tail call optimizations, c’est-à-dire l’optimisation des récursions terminales. C’est une fonctionnalité présente dans les langages fonctionnels, qui transforme l’appel récursif en itération (donc série d’étapes séquentielles) lors de la compilation, ce qui est bien plus performant et sauve de la place sur la pile. Un courriel envoyé sur la liste de diffusion du projet explique pourquoi elle ne sera jamais implémentée.

Il arrive régulièrement que quelqu’un poste, sur le sous-reddit (sous-partie du site web Reddit) consacré à Rust, un sujet en rapport avec le jeu Rust, un jeu de survie en développement également, et disponible sur GNU/Linux! (exemples : ici, ici, ici).

Du coup, le sous-Reddit a été renommé récemment (et temporairement?) en Rust is not a game where naked men murder each other with hatchets (« Rust n’est pas un jeu où des hommes nus s’entretuent avec des haches »).

Servo

Servo est un moteur de rendu HTML et CSS expérimental développé en Rust par Mozilla, Samsung le porte sur Android et les processeurs ARM. L'objectif est de tester un moteur fortement parallélisé dans tous ses aspects (rendu, mise en page, analyse HTML, lecture d'image) en utilisant les tâches isolées. Mozilla ne prévoit pas de sortie immédiate de Servo, puisque son succès repose sur la finalisation de Rust.

Le nom du moteur de rendu vient du robot Tom Servo de la série télévisée américaine Mystery Science Theater 3000.

À noter que les sources de Servo incluent une version figée de Rust. Au 3 avril, c'est la version du 24 février de Rust qui est utilisée.

Feuille de route

Bien qu'il ne soit pas prévu d'intégrer ce moteur dans les projets Mozilla, le projet est avancé et quelques captures d'écran ont été publiées. Pour 2014, la feuille de route est ambitieuse :

1er trimestre, pouvoir naviguer sur Wikipédia (passer le test Acid2, gestion des appareils à haute densité de pixels (HiDPI)…),
2nd trimestre, prendre en charge des applications web simples (passer le test Acid3, gérer le Javascript et Ajax, le webgl…),
3ème trimestre, ajouter des fonctionnalités et tests architecturaux (TLS/SSL, système de cache, canvas, web animations…),
4ème trimestre, ajouter une interface (multiprocessus, isolation (sandboxing), marques-pages, historiques, témoins (cookies), extensions, etc.).

En mars, Mozilla a publié trois nouvelles offres d'emploi pour travailler sur Servo.

Évolutions

Revamped parallel layout in Servo (évolution de l’algorithme concernant le parallélisme).
Servo passe le test Acid2.

Liens

Comme dans les précédentes dépêches, sauf indication contraire, les contenus liés sont en anglais. Et il y en a un nombre certain.

Notes de version

Récapitulatifs

This Week in Rust

Si vous voulez suivre le mouvement de tout ce qui se passe à propos de Rust sans avoir à lire le détail des commits, des annonces sur la liste de diffusion ou de Reddit, le blog This Week in Rust fait une synthèse hebdomadaire des nouveautés et actualités autour de Rust :

Vous pouvez voir que désormais sont indiqués les nouveaux contributeurs rejoignant le projet, et le moins que l’on puisse dire c’est qu’il y en a beaucoup !

Meeting Weekly

Les employés de Mozilla se rencontrent (par IRC) chaque mardi à 10h du matin, heure du pacifique (UTC-8). C’est ensuite enregistré sur Etherpad et archivé sur le wiki de Rust (sur Github).

14/01 (Friend of the Tree; statics on traits; env pointers; lang freeze; iterator naming; statics; docs on primitives)
21/01 (primitive impl lang items; env ptrs; boehm; fmt::Default; foo_opt => foo; \xNN; #[no_mangle]; crate_type="lib")
28/01 (Friend of the Tree; default type params; allocators; dylib to extra; unused Result warning; attributes; I/O; visit_glue)
04/02 (libprim; operator overloading; using system LLVM)
11/02 (Friend of the Tree; binding in struct patterns; rules on static values; crate keyword; pizza; finally macro; implicit trait bounds)
18/02 (if_ok!, issue numbers in commits, debug assertions, hash trait, vector syntax)
27/02 (Friend of the Tree; TotalEq; weak extern fn; channel names; relative paths)
11/03 (self argument destructuring; type hints; coercion rules; unsafe ptrs)
18/03 (Friend of the Tree; RFCs; 0.10; documentation; RFC review)

Évènements

Zurich, mercredi 19 février 2014, 18h30 — Rencontre avec pour thème « un mois avec Rust »,
Paris, mardi 25 février, 18h30 à 23h30 — Rencontre sur Rust au Mozilla Space,
San Francisco, le même jour, 19h00 — Cap'n Proto, Macros, and Testing, présentation retransmise sur Air Mozilla.
Londres, le 11 mars — Rust London MeetUp.
San Francisco, le 13 mars — Building an operating system, Parallel layout in Servo, Debugging Rust, présentations retransmises sur Air Mozilla.
Milan, jeudi 27 mars, 19h00 — Rust Hands On.
Paris, lundi 31 mars, 19h00 à 22h00 — Seconde rencontre Rust au Mozilla Space, annoncée sur la liste de diffusion Rust-dev.

Présentations

Diaporama et/ou vidéos de présentations concernant Rust.

Présentation de Geoffroy Couprie à ScalaIO en octobre 2013 retransmise sur InfoQ.
A Dablerr's adventures in Rust.
A 30 minute introduction to Rust.
Presentiamo Rust.
Felix Klock II on Rust: Concurrency, GCs, Type System (vidéo), aussi disponible sur Vimeo (Felix Klock II - Rust: Safe Systems Programming with the Fun of FP).
An Introduction + Ruby Extensions in Rust par Yehuda Katz au PDX Ruby.
Servo: building a parallel web browser — FOSDEM 2014.
« Courte présentation faite à un petit groupe d’amis ».
Macros in Rust.
Cap'n Proto, Macros and Testing.
Présentations données au Mozilla Space à Paris le 25 février 2014.
Construire un système d’exploitation en Rust (sans connaitre Rust ou comment écrire un système d’exploitation). Plus d’informations dans cet article de blog.

Tutoriels et documentation

Rust is surprisingly expressive (assez vieux, mais jamais publié ici et surtout intéressant)
Safari Books Online Blog
Using LLVM From Within Rust
Getting Rusty
Rust par l’exemple: machine à états sûre en utilisant des types fantômes (phantom types)
Le tableau périodique des types de Rust a été mis à jour.
Comparaison entre le système de modèles (templates) en C++ et les types génériques en Rust.
How To Organize Code in Rust per Object or Function.
Une réflexion sur le ramasse-miettes.

Projets

rust-ci, le projet indépendant qui liste les projets Rust qui utilisent Travis-CI comme plateforme d'intégration continue, a subi quelques mises à jour : catégorisation des projets, envoi de la documentation lors de l'exécution du projet dans Travis-CI.

Il y a un projet qui existe depuis un moment mais qui n’a jamais été présenté ici, c’est un compilateur de Rust vers Javascript.

Nouveaux projets

Voici maintenant la liste des nouveaux projets écrits en Rust. La majorité sont petits et sont très souvent dans un état de développement pas très avancé. En effet, ce sont souvent des projets personnels pour apprendre et tester le langage.

diffbot-rust-client, développement d'une API commandée par Diffbot.
RustLex, un générateur d'analyseurs lexicaux, à la manière de Lex, implémenté en Rust et produisant du code Rust via un système d'invocation par extensions de syntaxe.
rust-hash, implémentation de xxHas en Rust.
rust-lua.
rust-rosetta rassemble des codes pour RosettaCode — comparaison d'implémentation de tâches dans différents langages —, il reste de nombreux codes à écrire.
rs-persistent-datastructures, des structures de données persistantes en Rust.
ruste, prise en charge expérimentale de Rust dans Eclipse.
rust-gamedev-kit, une compilation des bibliothèques de jeu disponible pour rust au sein d’un seul dépôt git.
rust-mk, un script makefile pour compiler ses programmes un peu comme rustpkg.
Un clone de tetris en Rust, qui se joue dans le terminal.
rust-dominion, un jeu de dominion.
rust-bloom-filter, un filtre de Bloom.
uCTF-rs, un émulateur/débugueur de msp430.
Rust-Sudoku-Solver, un solveur de sudoku.
atom-language-rust, coloration syntaxique pour Atom.
Le tutoriel Kaléidoscope de LLVM sur comment implémenté un langage avec LLVM a été porté sur Rust.
QuickCheck, permet de tester la robustesse de son code face à des entrées aléatoires.
Racer (Rust Auto-CompletER) est un utilitaire qui fournit une auto-complétion basique pour les éditeurs et IDE.
rust-highlight, colore le code Rust pour les formats LaTex, HTML et JSON.
rust-tabular.
rust-csv.
Experiments with Rust and other languages : Parallel building, Echo TCP server.
tcp_echo.rs.
Asterisk module.

Futur

Conclusion

Un énorme réusinage et nettoyage qui permet d’envisager l’avenir de Rust plus sereinement, avec un code plus simple et mieux organisé, mais qui nécessitera encore une fois un peu de boulot pour les projets programmés en Rust.

Aller plus loin

# modèle objet proche de celui d'Haskell?

Posté par パパフラクス le 08 avril 2014 à 22:08. Évalué à 3.

modèle objet proche de celui d'Haskell
Comment est-ce possible?

Ou bien tu parles des classes de types, mais cela me semble assez éloigné d'un "modèle objet".
- [^] # Re: modèle objet proche de celui d'Haskell?
  
  Posté par ariasuni le 08 avril 2014 à 23:00. Évalué à 4. Dernière modification le 08 avril 2014 à 23:00.
  
  Oui, en Rust il y a des classes de types qui se rapprochent des interfaces de Java par exemple. Mais effectivement c’est un peu plus que ça.
  
  Écrit en Bépo selon l’orthographe de 1990
# Dans l'épisode précédent

Posté par claudex le 08 avril 2014 à 22:22. Évalué à 10.

À ceux qui n'ont rien compris à la dépêche, je conseille la lecture de la précédente sur la version 0.9, ça aide à comprendre les concepts.

« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Rust vs Go

Posté par Sébastien Douche le 09 avril 2014 à 05:35. Évalué à 10.

Rust se veut donc une alternative à C/C++, comme D et Go

J'ai toujours du mal a lire ce genre de phrases qui laisse a penser que Rust et Go sont des concurrents. Pour moi :

Go

C'est un langage "pauvre" (peu de concepts), typage fort certes mais faisant peu de vérification (une sorte de "Python en typage statique") mais bien pensé, géré de main de maitre et surtout rapidement assimilable. Il pourrait remplacer Python, Ruby, Nodejs et les programmes C++ écrient seulement pour le besoin de vitesse. Go ne remplace pas du C / C++ car le GC est handicapant dans bien des cas. De plus il n'apporte aucun concept qui le rendrait attirant aux yeux des dev C++ (on se gave pas de 10 de C++ pour ensuite changer).

Pour moi, le gros plus de Go est pour moi d'abaisser furieusement le cout d'entrée pour un langage concurrent et qui compile en statique. Apprendre le Go est peanut par rapport a du C++ / Rust.

Rust

C'est un langage riche, avec beaucoup de fonctionnalités sexy qui font bavées un peu tout le monde (immutabilité, choix du GC, race condition, coroutine, macro…) permettant de remplacer potentiellement le C / C++ partout. Mais au prix d'un apprentissage bien plus élevé.

C'est effectivement en concurrence frontale avec D amha.

En résumé

Go en haut, Rust en bas. Bien sur, un dev Rust pourra surement en faire la le Go est utilisable (mais pas le contraire dans la plupart des cas) mais je pense que l'apprentissage de ces 2 langages est loin d’être déconnant. Juste que j'ai toujours une grosse crainte de la part de Mozilla qui gèrent ses projets comme des barbouzes.
- [^] # Re: Rust vs Go
  
  Posté par Sébastien Douche le 09 avril 2014 à 05:37. Évalué à 10.
  
  Cela étant dit, chapeau a l'auteur de prendre du temps pour ses news sur Rust. J'apprécie :).
- [^] # Re: Rust vs Go
  
  Posté par Thom (site web personnel) le 09 avril 2014 à 08:12. Évalué à 3.
  
  C'est bien vrai tout ça.
  
  J'ai un peu essayé de me mettre à Rust et il y a pas mal de concepts assez rudes et la syntaxe n'est pas forcément intuitive non plus.
  
  Mais, sinon, c'est un chouette langage sinon le plus à suivre l'évolution.
  
  Merci pour la dépêche.
  
  La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
  - [^] # Re: Rust vs Go
    
    Posté par mosfet le 09 avril 2014 à 12:58. Évalué à 4.
    
    J'ai regardé rapidement la syntaxe et j'avoue que çà ne m'a pas l'air simple d'accès à la différence du langage D qui lui se comprend assez facilement je trouve.
    Il me semble que le D sera intégré dans la prochaine version de gcc, enfin en tout cas ceux qui travaillent dessus l'affirment (https://github.com/D-Programming-GDC/GDC).
    J'avoue que si on me demandait par quoi j'aimerais que le c++ soit remplacé, la tout de suite je dirais le D mais je vais me faire violence et essayer d'approfondir Rust.
    - [^] # Re: Rust vs Go
      
      Posté par ariasuni le 09 avril 2014 à 14:18. Évalué à 3.
      
      Le D est beaucoup plus proche du C++, mais la syntaxe du Rust est quand même relativement simple et pas très éloignée (à part bien sûr certains trucs qui n'existent pas en C++: modules/use, macros, etc).
      
      Écrit en Bépo selon l’orthographe de 1990
    - [^] # Re: Rust vs Go
      
      Posté par rewind (Mastodon) le 09 avril 2014 à 14:24. Évalué à 10.
      
      J'avoue que si on me demandait par quoi j'aimerais que le c++ soit remplacé
      
      Pourquoi vouloir remplacer C++ ? Depuis C++11, honnêtement, c'est devenu un vrai plaisir d'écrire du C++ et ça va être encore mieux avec C++14 et C++17.
      - [^] # Re: Rust vs Go
        
        Posté par reno le 09 avril 2014 à 14:39. Évalué à 3.
        
        Parce qu'un bon langage ne devrait pas avoir des manuels de 700 pages et plus et des livres qui donnent les bonnes parties et les partie a éviter.
        
        C++ n'est donc pas un bon langage même s'il est très puissant.
        
        [^] # Re: Rust vs Go
        
        Posté par rewind (Mastodon) le 09 avril 2014 à 14:48. Évalué à 7.
        
        Avec ta définition, un vieux langage ne pourra jamais être un bon langage. Parce qu'un vieux langage se traînent nécessairement une dette technique dont il est parfois difficile de se débarrasser, surtout quand le langage en question est une norme ISO et est aussi répandu que C++.
        
        Moi, je trouve que C++ est un bon langage.
        
        [^] # Re: Rust vs Go
        
        Posté par reno le 09 avril 2014 à 15:50. Évalué à 4.
        
        Avec ta définition, un vieux langage ne pourra jamais être un bon langage.
        
        Tel que la plupart des langages sont développés effectivement c'est le cas car quand les créateur cherchent a améliorer le langage (cf Python3) souvent les mises à jours ne prennent pas..
        
        Après il y a des degrés et C++ a une dette technique abyssale, Ada moins par exemple.
        
        La seule alternative potentielle ce serait le "go fmt": faire évoluer le langage en fournissant des outils pour simplifier le portage, problème: ça marche bien quand tu as du code simple, mais dès que tu utilise les macros, la reflection, un outil ne peut pas faire grand chose..
        
        [^] # Re: Rust vs Go
        
        Posté par ariasuni le 09 avril 2014 à 17:12. Évalué à 4.
        
        Tel que la plupart des langages sont développés effectivement c'est le cas car quand les créateur cherchent a améliorer le langage (cf Python3) souvent les mises à jours ne prennent pas..
        
        Pour Rust ils feront en sorte que ça soit rétrocompatible très longtemps, et ça je pense que pour migrer du C++ c’est une condition nécessaire.
        
        Écrit en Bépo selon l’orthographe de 1990
      - [^] # Re: Rust vs Go
        
        Posté par c^3 le 10 avril 2014 à 00:19. Évalué à 7.
        
        mozilla travaille sur rust précisément pour remplacer C++, parce que :
        
        C++ est très "unsafe" (pointeurs nuls, gestion manuelle de la mémoire, sémantique compliquée, unions, mutabilité par défaut) même si pas autant que C,
        
        écrire un programme concurrent correct en C++ est très difficile.
        
        Là où rust est très intéressant de mon point de vue, c'est qu'il est influencé par des langages fonctionnels (ML, Haskell) en gardant des caractéristiques bas niveau le rendant performant et prédictible (pas de GC, contrôle du layout mémoire). L'absence de pointeur nul, l'immutabilité par défaut, le filtrage et les énumérations (types algébriques) sont cruciaux.
        
        The cake is a lie.
        
        [^] # Re: Rust vs Go
        
        Posté par rewind (Mastodon) le 10 avril 2014 à 11:54. Évalué à 3.
        
        C++ est très "unsafe" (pointeurs nuls, gestion manuelle de la mémoire
        
        Dire que la gestion manuelle de la mémoire est «unsafe», c'est vraiment un truc à la mode ces dernières années. Surtout qu'avec C++11, on n'a quasiment plus aucun besoin de gérer la mémoire. En C++14, on n'aura même plus besoin de faire des new et delete, ils seront masqués complètement. Qu'est-ce qu'on reproche encore à C++ à ce niveau ? Des fantasmes sans doute. Le C++ n'est pas du C !
        
        Qu'est-ce qui le différenciera de Rust ? Plus grand chose à mon sens. Ceux qui font de la merde avec la gestion mémoire, ils le savent en C++, il n'ont pas besoin de mettre un préfixe unsafe.
        
        sémantique compliquée, unions, mutabilité par défaut) même si pas autant que C,
        
        La sémantique de C++ n'est pas plus compliquée que celle de Rust. Juste différente. Question de goût.
        
        Les unions… Hormis dans des cas extrêmes et bien identifiés, qui utilisent des unions ?
        
        écrire un programme concurrent correct en C++ est très difficile.
        
        Faux ! Ce qu'il manque à C++, c'est un modèle de programmation dans la bibliothèque standard. C++ laisse l'utilisateur le définir. En Rust, comme en Go d'ailleurs, le modèle de programmation est imposé. Maintenant, en C++, tu peux très bien trouver des bibliothèques comme TBB qui permettent d'avoir de la concurrence très facilement.
        
        [^] # Re: Rust vs Go
        
        Posté par reno le 10 avril 2014 à 12:37. Évalué à 4.
        
        Le C++ n'est pas du C !
        
        Faux! Le C++ n'est pas que du C, mais quand tu regardes pas mal de projet soit-disant C++, en fait c'est principalement du C et donc on se retrouve avec tout les problèmes du C.
        
        [^] # Re: Rust vs Go
        
        Posté par barmic le 10 avril 2014 à 13:28. Évalué à 4.
        
        Dire que la gestion manuelle de la mémoire est «unsafe», c'est vraiment un truc à la mode ces dernières années. Surtout qu'avec C++11, on n'a quasiment plus aucun besoin de gérer la mémoire. En C++14, on n'aura même plus besoin de faire des new et delete, ils seront masqués complètement. Qu'est-ce qu'on reproche encore à C++ à ce niveau ? Des fantasmes sans doute.
        
        Tu va peut être être surpris mais le C++ n'a pas 3 ans, donc il faut supporter le code plus ancien. C'est bien l'intérêt d'une norme ISO, non, de ne pas avoir à tout réécrire à chaque version ?
        
        Tu as quoi pour vérifier que tu ne fais pas des usages dommageables ? Tu peut utiliser le dernier icc, g++, clang++ en appliquant la dernière version de la norme, tu pourra toujours faire un brk(2) des familles. Un langage sûr c'est un langage qui te l'interdit.
        
        Les unions… Hormis dans des cas extrêmes et bien identifiés, qui utilisent des unions ?
        
        Ceux qui ne savent pas ce qu'est le polymorphisme ? ;-)
        
        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 Anthony Jaguenaud le 10 avril 2014 à 14:04. Évalué à 3.
        
        Les unions… Hormis dans des cas extrêmes et bien identifiés, qui utilisent des unions ?
        
        Ceux qui ne savent pas ce qu'est le polymorphisme ? ;-)
        
        Il y a quand même des usages utiles, avoir une seule structure pour un message pouvant avoir plusieurs formes, etc. Mais il est vrai que comme pour l'héritage multiple il faut l'utiliser à bon escient.
        
        [^] # Re: Rust vs Go
        
        Posté par barmic le 10 avril 2014 à 15:40. Évalué à 6. Dernière modification le 10 avril 2014 à 15:40.
        
        un message pouvant avoir plusieurs formes
        
        Un genre de message polymorphique, 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 rewind (Mastodon) le 10 avril 2014 à 17:28. Évalué à 3.
        
        Tu va peut être être surpris mais le C++ n'a pas 3 ans, donc il faut supporter le code plus ancien.
        
        Oui, et ce code plus ancien, a priori, il doit bien marcher et ne pas faire trop de connerie, sinon ça serait corrigé.
        
        Tu as quoi pour vérifier que tu ne fais pas des usages dommageables ? Tu peut utiliser le dernier icc, g++, clang++ en appliquant la dernière version de la norme, tu pourra toujours faire un brk(2) des familles. Un langage sûr c'est un langage qui te l'interdit.
        
        brk(2) est un appel POSIX, il n'est pas dans la norme C++.
        
        Ceux qui ne savent pas ce qu'est le polymorphisme ? ;-)
        
        Ceux qui utilisent GNU Bison…
        
        [^] # Re: Rust vs Go
        
        Posté par tyoup le 10 avril 2014 à 23:05. Évalué à 2.
        
        Ceux qui utilisent GNU Bison…
        
        YYSTYPE peut être défini comme étant une struct…
        
        [^] # Re: Rust vs Go
        
        Posté par barmic le 10 avril 2014 à 23:46. Évalué à 6.
        
        Oui, et ce code plus ancien, a priori, il doit bien marcher et ne pas faire trop de connerie, sinon ça serait corrigé.
        
        Il n'y a aucun bug dans tout ce qui a était écris il y a plus de 3 ans ?
        
        brk(2) est un appel POSIX, il n'est pas dans la norme C++.
        
        Oui mais il permet de s'en servir comme on le souhaite donc le langage n'est pas sûr. Un langage sûr ce n'est pas un langage qui te permet d'écrire des programmes sûres, mais un langage qui t'empêche d'écrire un programme non-sûre.
        
        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 le 11 avril 2014 à 12:39. Évalué à 7.
        
        Tu aurais un bon bouquin qui décrit le sous-ensemble de C++ moderne qui est safe, histoire que je sache de quoi tu parles ? :)
        
        [^] # Re: Rust vs Go
        
        Posté par Trollgouin le 11 avril 2014 à 11:09. Évalué à 5.
        
        Tu peut utiliser le dernier icc, g++, clang++ en appliquant la dernière version de la norme, tu pourra toujours faire un brk(2) des familles.
        
        Il me semble que tu es d'une magnifique mauvaise foi sur le choix de ton exemple:
        
        error: invalid conversion from ‘int’ to ‘void*’ [-fpermissive] brk(2);
        
        C++ s'est débarrassé depuis longtemps du transtypage automatique d'entier vers pointeur (exemple testé avec une norme vieille de 16 ans!!). Quand au choix de brk pour illustrer ce point, c'est maladroit au vu de sa suppression de posix.1 en 2001…
        
        Le langage+compilateur a l'épreuve des cons n'existe pas et n'existera pas (ça doit pouvoir se dériver sans trop de problème du second théorème d'incomplétude de Gödel).
        
        Pour mettre en valeur la meilleure sûreté de rust, tu devrais nous donner des exemples où la meilleure analyse statique de rust permet d'éviter des erreurs subtiles et plausibles (Thom le fait un peu plus bas).
        
        [^] # Re: Rust vs Go
        
        Posté par barmic le 11 avril 2014 à 11:25. Évalué à 1.
        
        Peut être un mauvais choix. Des problèmes existent dans C++, il y en a d'autres des manipulations de mémoire risquées comme strcpy(3) (à moins qu'il ai lui aussi était retiré ?). Tu peut toujours faire un newnon protégé. Que le langage apporte aujourd'hui des outils pour faire du code de très grande qualité c'est une évidence, mais il ne déprécie pas tous les anciens usages dangereux. Est-ce que C++14 va déprécier les mots-clef new et delete, le fait qu'il existe d'autres manière de faire n'en fait pas un langage sûr ça permet au développeur de créer des programmes sûre (un peu comme en C quand les développeurs d'OpenBSD je crois s'interdisent l'utilisation de malloc(3) et de quelques autres méthodes pour les remplacer par les leur plus sûre).
        
        Si on considère que le C++ n'était pas fiable et qu'il l'ai maintenant, il ne faut pas parler des nouveautés, mais de ce qui y a était retiré.
        
        Pour mettre en valeur la meilleure sûreté de rust, tu devrais nous donner des exemples où la meilleure analyse statique de rust permet d'éviter des erreurs subtiles et plausibles (Thom le fait un peu plus bas).
        
        Le problème c'est que je ne parlais pas de rust (que je ne connais pas), mais répondais uniquement à ce paragraphe que je citais :
        
        Dire que la gestion manuelle de la mémoire est «unsafe», c'est vraiment un truc à la mode ces dernières années. Surtout qu'avec C++11, on n'a quasiment plus aucun besoin de gérer la mémoire. En C++14, on n'aura même plus besoin de faire des new et delete, ils seront masqués complètement. Qu'est-ce qu'on reproche encore à C++ à ce niveau ? Des fantasmes sans doute.
        
        qui ne parle que de C++.
        
        Mais grosso modo, pour que C++ soit plus sûr il faudrait qu'en plus d'avoir ajouté les pointeurs géré, ils ai interdit l'utilisation des pointeurs nus. Ce n'est pas le cas.
        
        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 khivapia le 11 avril 2014 à 11:54. Évalué à 5.
        
        ils ai interdit l'utilisation des pointeurs nus.
        
        Non : garder les pointeurs nus peut permettre un gain en performances dans des cas extrêmement particuliers (type HPC). Du coup pourquoi les retirer ?
        Par contre ils ne devraient pas être utilisés dans un bout de code chargé de faire de la sécurité. D'une il n'y en a pas besoin dans ce cas, de deux, les utiliser se verra et aucun développeur ne pourra trouver de bonne raison de le faire dans ce cas là.
        C++ permet donc de faire de la merde, comme tout langage, mais il faut vraiment faire exprès d'utiliser les mécanismes bas niveau quand le langage propose des solutions simples et sûres (à l'inverse du C qui nécessite une bonne dose de discipline personnelle).
        
        [^] # Re: Rust vs Go
        
        Posté par barmic le 11 avril 2014 à 12:59. Évalué à 8.
        
        Non : garder les pointeurs nus peut permettre un gain en performances dans des cas extrêmement particuliers (type HPC). Du coup pourquoi les retirer ?
        
        J'ai pas dis qu'il fallait les retirer ou qu'ils étaient inutile, j'ai dis que ça fait partis de ce qui empêche de dire que le C++ est un langage sûre.
        
        Par contre ils ne devraient pas être utilisés dans un bout de code chargé de faire de la sécurité. D'une il n'y en a pas besoin dans ce cas, de deux, les utiliser se verra et aucun développeur ne pourra trouver de bonne raison de le faire dans ce cas là.
        
        Je ne parle pas de la qualité des programmes en C++. Un langage sûre apporte des garanties et t'oblige à retirer des sécurités pour pouvoir faire n'importe quoi. Affirmer que le C++ est un langage sûr quand il est utilisé par des développeurs sûr ça n'a pas de sens. L'assembleur, le shell POSIX et PHP sont très sûr quand ils sont utilisés par des développeurs qui savent y faire.
        
        C++ permet donc de faire de la merde, comme tout langage[…]
        
        Non certains langage accepte par défaut que tu fasse de la merde et d'autres te permettent de faire de la merde si tu lui dis « ok je sais que je suis entrain de faire de la merde ». Bien sûr la limite entre les 2 est floue, mais le C++ est clairement plus dans la première partie que dans la seconde.
        
        il faut vraiment faire exprès d'utiliser les mécanismes bas niveau quand le langage propose des solutions simples et sûres
        
        Mais pour garantir que ces mécanismes ne sont pas utilisés il va falloir que tu utilise un analyseur statique en dehors du standard qui définira lui même la partie sûre et la partie non sûre du C++, ça c'est de base dans les langages sûres c'est pour ça qu'ils sont sûres.
        
        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 lolop (site web personnel) le 11 avril 2014 à 13:03. Évalué à 6.
        
        quand ils sont utilisés par des développeurs qui savent y faire.
        
        Et encore… "Errare humanum est…"
        
        Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
        
        [^] # Re: Rust vs Go
        
        Posté par khivapia le 11 avril 2014 à 13:17. Évalué à 2.
        
        Affirmer que le C++ est un langage sûr quand il est utilisé par des développeurs sûr ça n'a pas de sens.
        
        Ce n'est pas ce que je disais. Je disais qu'il est facile d'éviter les constructions subtiles qui peuvent mener à des failles de sécurité en C++ (en particuliers les pointeurs nus).
        Après comme partout un langage est aussi sûr que ses développeurs en ont l'expérience, pas plus, pas moins.
        
        [^] # Re: Rust vs Go
        
        Posté par rewind (Mastodon) le 12 avril 2014 à 00:32. Évalué à 1.
        
        Non certains langage accepte par défaut que tu fasse de la merde et d'autres te permettent de faire de la merde si tu lui dis « ok je sais que je suis entrain de faire de la merde ». Bien sûr la limite entre les 2 est floue, mais le C++ est clairement plus dans la première partie que dans la seconde.
        
        Donc, tu es en train de dire que mettre un préfixe «unsafe» devant tous les trucs gorets, ça change absolument tout ? S'il y a un «unsafe», c'est bien que ça doit servir à un moment, non, sinon ça ne serait pas là ? Et bien moi, je préfère qu'on ne mette pas un «unsafe» et qu'on apprenne à l'utilisateur ce qu'il ne faut pas faire et pourquoi, plutôt que d'avoir un préfixe «unsafe» inutile parce que du coup, on se demande bien ce que ça peut faire là. Et puis si les gars qui codent l'utilisent, c'est qu'on doit pouvoir l'utiliser, donc c'est pas si unsafe. Donc de toute façon, dans tous les cas, tu trouveras toujours un couillon qui utilisera mal le langage (préfixe «unsafe» ou pas) et qui fera de la merde.
        
        [^] # Re: Rust vs Go
        
        Posté par barmic le 12 avril 2014 à 01:12. Évalué à 10.
        
        Tu change la question et fais ta réponse. La question philosophique de savoir si les langages doivent apporter des sécurités ou est-ce qu'on doit simplement prendre de haut d'un air indigné ceux qui commentent des erreurs est un tout autre débat (j'ai l'impression que tu veux surtout défendre C++ bec et ongle contre toute critique).
        
        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 rewind (Mastodon) le 12 avril 2014 à 07:48. Évalué à 1.
        
        Ce que je te dis, c'est que, certes, Rust apporte quelques sécurités mais ne t'empêche nullement de faire de la merde parce que tu peux passer par unsafe. Et le fait que ce soit marqué unsafe, ça ne va pas gêner ceux qui font de la merde. Le problème, il n'est pas technique, il est humain. Et C++, là dedans, il permet lui aussi d'avoir quelques sécurité (pas les mêmes que celles de Rust) mais il permet aussi de faire de la merde (sans préfixe unsafe). Comme le problème est humain, l'un n'est pas mieux que l'autre.
        
        [^] # Re: Rust vs Go
        
        Posté par ariasuni le 12 avril 2014 à 12:00. Évalué à 6. Dernière modification le 12 avril 2014 à 12:05.
        
        Dans 99% des cas tu m'as pas besoin d'unsafe. Et quand on l'utilise, on s'arrange pour avoir un bloc le plus petit possible, comme ça on ne fait que de la merde dans la fonction actuelle et la zone non-sûre à vérifier est beaucoup plus réduite en cas de bug inhabituel.
        
        C'est un peu comme du Python ou du Java avec un bout de C pour les trucs nécessitant de la vitesse. En cas de segfault, il n'y a que le petit bout de C à vérifier. Sauf que Rust est plus sûr que Python ou Java et surtout suffisant rapide pour n'avoir que très rarement besoin de pointeurs nus.
        
        Rust sera (attendons quand même la 1.0 tout de même!) un langage très intéressant pour remplacer le C++: au lieu de devoir être un super-développeur et de devoir utiliser des outils externes pour trouver les bugs, passer sa vie sur StackOverflow à cause de deux parenthèses en trop (histoire vraie., il suffit de comprendre le système de durée de vie et de corriger les erreurs indiquées par le compilateur. Il permet également de corriger des erreurs plus subtiles, puisqu'il y a zéro conversion de type implicite (même de int à double).
        
        Enfin, c'est plus agréable pour plein de trucs (pas exempleuint au lieu de unsigned int, le filtrage par motif c'est la vie, possible de faire la déclaration d'une fonction en haut du fichier et la définir après mais pas obligatoire et surtout pas besoin de fichiers d'en-têtes (le truc que je trouve le plus chiant avec C++ quand tu débutes un projet), etc), c'est plus facile à parser/grepperfonction (let, variable: let — en C/C++ les deux déclarations commencent par le type ou const, des fois le «type» est deux parties — unsigned int, etc).
        
        Le C++14 c'est cool, mais ça fait longtemps que j'attends le système de module pour me passer des fichiers d'en-têtes et ça n'arrive pas. Et les mots d'erreurs sont trop souvent imbitables, même si ça c'est clairement amélioré. La dette technique du C++ fait que certains défauts resteront à tout jamais, et que les améliorationt arrivent lentement, au prix d'une complexité qui décourage le portable des fonctionnalités C++11 par exemple beaucoup de plateformes.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Rust vs Go
        
        Posté par Lutin le 13 avril 2014 à 18:55. Évalué à 3.
        
        Pourquoi n'aimes tu pas les fichiers d'entête ? Oui c'est agaçant à mettre en place, mais quand on est nouveau sur un projet ça aide bien à comprendre le code, à voir ce que fait en gros une classe donnée, sans avoir à scroller le gros .cpp.
        
        [^] # Re: Rust vs Go
        
        Posté par ariasuni le 13 avril 2014 à 21:15. Évalué à 1.
        
        C'est chiant à faire et compliqué (quand j'ai débuté, j'ai eu du mal à me souvenir quoi mettre où)
        
        Faut penser à le modifier… sans se tromper!
        
        En Rust on peut mettre les déclarations au début du fichier, là où elle devraient être au départ.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Rust vs Go
        
        Posté par zul (site web personnel) le 14 avril 2014 à 09:28. Évalué à 2.
        
        Les fichiers de déclarations ne sont pas un problème en soit je pense. Le problème c'est qu'en C, C++, #include, c'est vraiment juste une inclusion textuelle, et donc que le compilateur doit reparser tous les fichiers tout le temps, ce qui rend les temps de compilation assez horrible. Un simple Hello world après subsitution de #include fait, chez moi, 18K lignes.
        
        [^] # Re: Rust vs Go
        
        Posté par ariasuni le 14 avril 2014 à 11:15. Évalué à 3.
        
        Tu viens de mettre le doigt sur un détail intéressant: en fait ça n’est ni intéressant pour le développeur, ni pour le compilateur.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Rust vs Go
        
        Posté par barmic le 14 avril 2014 à 13:32. Évalué à 5.
        
        gcc fait de la précompilation des .h, non ?
        
        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 reno le 14 avril 2014 à 10:34. Évalué à 6.
        
        Bof, vu que tu peux générer un fichier d'entête automatiquement, c'est un "pour" très faible..
        
        [^] # Re: Rust vs Go
        
        Posté par ariasuni le 14 avril 2014 à 11:14. Évalué à 1.
        
        Ça rajoute un outil dans la chaine de compilation qui peut potentiellement être bogué, ou ne pas fonctionner avec une nouvelle fonctionnalité du langage. C’est plus un bidouillage qu’autre chose.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Rust vs Go
        
        Posté par reno le 14 avril 2014 à 13:31. Évalué à 5.
        
        Oui, enfin quand on conçoit un langage, ce sont surtout les header eux-même qui sont un bidouillage: si tu remarques bien, aucun des nouveaux langages n'impose des fichiers de header.
        
        Tu es habitué aux headers, OK, mais bon l’intérêt d'une violation aussi manifeste du DRY maintenant que les ordinateurs sont suffisamment puissant pour s'en passer, bof..
        
        [^] # Re: Rust vs Go
        
        Posté par rewind (Mastodon) le 14 avril 2014 à 15:05. Évalué à 2.
        
        Non mais faudrait arrêter de faire croire que C++ date d'hier hein. C++ a une compatibilité très large avec le C, lui-même ayant été créé dans les années 70 ! Oui, on a toujours des headers en C++, et alors ? Ça empêche le monde de tourner ? Non, ça marche très bien. Oui, ça viole le DRY et alors ? Ça permet aussi d'avoir une documentation des fonctions sans se traîner le corps de la fonction. Ce n'est pas un drame.
        
        [^] # Re: Rust vs Go
        
        Posté par barmic le 14 avril 2014 à 16:13. Évalué à 1.
        
        Non mais faudrait arrêter de faire croire que C++ date d'hier hein.
        
        C'est marrant, un coup il faut regarder que les nouveautés et s'appliquer à oublier tout le reste, un coup il faut bien garder en tête qu'il est super vieux.
        
        C'est pas imaginable de ne plus les rendre obligatoire ? Un peu comme les pointeurs nus par exemple.
        
        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 rewind (Mastodon) le 14 avril 2014 à 16:27. Évalué à 5.
        
        C'est marrant, un coup il faut regarder que les nouveautés et s'appliquer à oublier tout le reste, un coup il faut bien garder en tête qu'il est super vieux.
        
        C'est pourtant pas difficile : C++ est un langage qui évolue mais qui garde une compatibilité avec les version antérieures et avec le C. Il n'y a aucune contradiction à vouloir utiliser les trucs nouveaux quand ils sont là et à utiliser les trucs plus anciens quand ils n'ont pas (encore) de remplaçants. Si vous voulez vous amusez à pointer tous ces vieux trucs inutiles voire parfois encombrants de C++, vous n'avez pas fini, mais ça n'apportera pas grand chose au débat.
        
        [^] # Re: Rust vs Go
        
        Posté par barmic le 14 avril 2014 à 17:06. Évalué à 4.
        
        Tu semble palpiter d'impatience pour le C++14 pour ne plus utiliser de new/delete, d'autres, pleins d'autres, crève d'avoir des concepts pourquoi certains ne pourraient pas affirmer qu'ils aimeraient avoir une notion de modules ?
        
        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 rewind (Mastodon) le 14 avril 2014 à 17:15. Évalué à 1.
        
        Ce n'est pas la question. reno fait semblant que C++ est un langage récent mais se traîne des headers. C'est complètement à côté de la plaque de comparer C++ avec des langages conçus récemment. On peut affirmer qu'on aimerait bien une notion de module, sans oublier que les headers de C++, ça ne date pas d'hier non plus.
        
        [^] # Re: Rust vs Go
        
        Posté par barmic le 14 avril 2014 à 23:15. Évalué à 8.
        
        Tout comme tu faisais comme si le C++ était un langage jeune affirmant qu'il était sûr parce qu'on a plus à faire de new/delete…
        
        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 Meku (site web personnel) le 15 avril 2014 à 21:36. Évalué à 3.
        
        Ça permet aussi d'avoir une documentation des fonctions sans se traîner le corps de la fonction.
        
        Sauf qu'on peut aussi avoir le corps des fonctions dans le header… Tantôt on l'a, tantôt on l'a pas. On trouve souvent l'implémentation des petites fonctions dans le header, mais sans trop de règle bien précise (en général c'est pour que ça puisse être inliné, donc plus par contrainte technique…). Ça donne un peu une impression de désordre. En Ada il y a aussi des headers, mais au moins on n'y trouve jamais l'implémentation de fonctions dedans. Il y a une séparation plus nette.
        
        [^] # Re: Rust vs Go
        
        Posté par Zylabon le 12 avril 2014 à 16:23. Évalué à 7.
        
        Personnellement je n'attends pas du langage que j'utilise qu'il m'interdise de faire de la merde, c'est ridicule, JE me l'interdis. En revanche, quand par mégarde ou ignorance j'utilise une construction douteuse, j'aime qu'il me le dise, un programme qui compile pas c'est plus vite déboguer qu'un programme qui foire au bout de 10h, et s'il est compilé sans mode debug. Un compilateur parfait ne compilerait que des programmes corrects… Et un compilateur C++ compile à peu près n'importe quoi.
        
        Please do not feed the trolls
        
        [^] # Re: Rust vs Go
        
        Posté par reno le 12 avril 2014 à 02:12. Évalué à 6.
        
        Bof, ton argument est faiblard: dans un projet il est facile d'avoir comme règle de codage: pas de unsafe a moins qu'il y ait une justification.
        La règle "éviter toute les constructions foireuse du C++" est beaucoup plus compliquée a appliqué!
        
        [^] # Re: Rust vs Go
        
        Posté par rewind (Mastodon) le 12 avril 2014 à 08:01. Évalué à 3.
        
        Pourquoi ce serait «facile» d'avoir comme règle de codage «pas de unsafe a moins qu'il y ait une justification» et que ce serait difficile d'avoir le même genre de règle pour C++ ? La règle est juste un poil plus longue mais pas tant que ça (pas d'exceptions, de RTTI, d'héritage multiple ; et pour C++14, pas de new/delete). Si tu es obligé de mettre une règle pour Rust, c'est qu'il n'est pas si sûr que ça. Et dans ces cas là, C++ est tout aussi sûr. Parce que mettre des règles, ce n'est pas pour les compilateurs, c'est pour les humains.
        
        [^] # Re: Rust vs Go
        
        Posté par Moonz le 12 avril 2014 à 09:39. Évalué à 8. Dernière modification le 12 avril 2014 à 09:40.
        
        Tu oublies : pas de pointeurs nus, pas de références, pas de passage par référence/adresse/smart pointer d’objets sur la pile.
        
        Et là ça va déjà compliquer un poil les choses, à la fois au codage et à la vérification des règles.
        
        [^] # Re: Rust vs Go
        
        Posté par ariasuni le 10 avril 2014 à 22:37. Évalué à 8.
        
        Qu'est-ce qui le différenciera de Rust ? Plus grand chose à mon sens.
        
        Si tu dis ça sincèrement, c’est du foutage de gueule. Je suis d’accord que le C++ devient de mieux en mieux, mais il y a toujours plein de trucs qui le rendent casse-gueule, verbeux et compliqué. Les durées de vie sont le cœur du système de gestion de mémoire de Rust et à ce titre donne bien plus de garantie de sûreté que le C++. Il ne faut pas oublier d’autres points ultra-importants comme l’absence de pointeurs nuls.
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Rust vs Go
        
        Posté par tyoup le 10 avril 2014 à 23:28. Évalué à 1.
        
        En C++14, on n'aura même plus besoin de faire des new et delete, ils seront masqués complètement. Qu'est-ce qu'on reproche encore à C++ à ce niveau ?
        
        On utilise allocate et destroy ? Wait…
        
        [^] # Re: Rust vs Go
        
        Posté par rewind (Mastodon) le 10 avril 2014 à 23:47. Évalué à 4.
        
        On utilisera std::make_shared (déjà dispo en C++11) et std::make_unique (en C++14)
        
        [^] # Re: Rust vs Go
        
        Posté par tyoup le 12 avril 2014 à 01:06. Évalué à 2.
        
        et std::make_shared et std::make_unique ont été implémentés avec l'opérateur de schtroumpf :-)
        
        [^] # Re: Rust vs Go
        
        Posté par rewind (Mastodon) le 12 avril 2014 à 07:43. Évalué à 2.
        
        Oui, comme en Rust. Et tout le monde s'en fout la manière dont c'est implémenté, l'important c'est que ça marche comme c'est spécifié. Le fait que ce soit dans la bibliothèque standard ou dans le langage lui-même ne change pas grand chose à l'affaire.
        
        [^] # Re: Rust vs Go
        
        Posté par Moonz le 12 avril 2014 à 10:01. Évalué à 7. Dernière modification le 12 avril 2014 à 10:02.
        
        Sauf que du fait qu’il soit implémenté par le compilateur, le owned pointer de Rust est bien plus riche (tout en étant plus sûr) que le unique_ptr de C++.
        
        Plus riche : en Rust je peux passer un owned pointer en argument d’une fonction (par exemple pour passer l’ownership à un objet qui le mettra dans ses attributs). En C++ c’est une erreur de compilation (unique_ptr(const unique_ptr&) = delete;).
        
        Plus sûr : en C++ je peux faire une référence sur un owned pointer (int& j = *i) sans que le compilateur trouve quoi que ce soit à redire (donc tu peux même pas dire : unique_pointer et shared_ptr safe, il faut regarder méthode par méthode… une erreur est vite arrivée). En Rust aussi je peux faire une référence sur un owner pointer, mais le compilateur (vu que c’est implémenté dans le compilo et non dans la stdlib, c’est possible et c’est fait) vérifie que la référence ne vit pas plus longtemps que l’objet référencé et balance une erreur si c’est le cas.
        
        Pire : ceci est syntaxiquement valide en C++, mais trivialement faux :
        
        #include <memory> #include <iostream> void do_something(std::unique_ptr<int> i) { } int main() { std::unique_ptr<int> i(new int(1)); do_something(std::move(i)); std::cout << *i << std::endl; return 0; }
        
        Après, je n’ai pas fait de C++ « moderne », la seule connaissance que j’en ai ce sont les discussions sur ce fil :). Mais l’important reste qu’en utilisant uniquement des constructions soit-disant safe du langage (ou alors est-ce que std::move est considéré comme unsafe ? si oui ça limite quand même vachement l’intérêt de la chose), j’arrive à faire des constructions unsafe, ce que Rust m’empêche de faire.
        
        [^] # Re: Rust vs Go
        
        Posté par ariasuni le 12 avril 2014 à 12:16. Évalué à 2.
        
        Plus riche : en Rust je peux passer un owned pointer en argument d’une fonction (par exemple pour passer l’ownership à un objet qui le mettra dans ses attributs). >En C++ c’est une erreur de compilation (unique_ptr(const unique_ptr&) = delete;)
        
        Si j'ai bien compris, avec les traits Deref et DerefMut tu peux aussi le faire avec les pointeurs dans les bibliothèques (bien que ça soit quand même légèrement plus moche). L'exemple de la dépêche semble indiquer qu'il faudrait mettre comme argument &*pointeur (adresse de la valeur contenu dans pointeur). Les règles d'emprunts sont toujours valides (pas possible d'avoir plus de deux emprunts à la fois), donc les pointeurs des bibliothèques bénéficient des mêmes avantages (avec légèrement moins de sucre syntaxique, peut-être qu'on en rajoutera après la 1.0).
        
        Écrit en Bépo selon l’orthographe de 1990
        
        [^] # Re: Rust vs Go
        
        Posté par TeXitoi (site web personnel) le 11 avril 2014 à 17:05. Évalué à 10.
        
        Dire que la gestion manuelle de la mémoire est «unsafe», c'est vraiment un truc à la mode ces dernières années. […] Qu'est-ce qu'on reproche encore à C++ à ce niveau ? Des fantasmes sans doute. Le C++ n'est pas du C !
        
        #include <memory> #include <iostream> int const &get_one() { std::unique_ptr<int> i(new int(1)); return *i; } int main() { std::cout << get_one() << std::endl; return 0; }
        
        Ça a l'air par mal, compilons voir avec tous pleins de warning
        
        $ clang++ --std=c++11 -Weverything -Wno-c++98-compat -Wno-missing-prototypes test.cpp -o test $
        
        cool ça a l'air memory safe ! On teste ?
        
        $ valgrind ./test ==8446== Memcheck, a memory error detector ==8446== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==8446== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==8446== Command: ./test ==8446== ==8446== Invalid read of size 4 ==8446== at 0x400BAC: main (in /.../test) ==8446== Address 0x59f8040 is 0 bytes inside a block of size 4 free'd ==8446== at 0x4C28BDC: operator delete(void*) (vg_replace_malloc.c:502) ==8446== by 0x400DC0: std::default_delete<int>::operator()(int*) const (in /.../test) ==8446== by 0x400D25: std::unique_ptr<int, std::default_delete<int> >::~unique_ptr() (in /.../test) ==8446== by 0x400C44: std::unique_ptr<int, std::default_delete<int> >::~unique_ptr() (in /.../test) ==8446== by 0x400B69: get_one() (in /.../test) ==8446== by 0x400BA3: main (in /.../test) ==8446== 1 ==8446== ==8446== HEAP SUMMARY: ==8446== in use at exit: 0 bytes in 0 blocks ==8446== total heap usage: 1 allocs, 1 frees, 4 bytes allocated ==8446== ==8446== All heap blocks were freed -- no leaks are possible ==8446== ==8446== For counts of detected and suppressed errors, rerun with: -v ==8446== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) $
        
        Oups !
        
        La même chose en rust
        
        fn get_one() -> &int { return &*~1; } fn main() { println!("{}", *get_one()); }
        
        On compile :
        
        $ rustc test.rs -o test test.rs:2:12: 2:16 error: borrowed value does not live long enough test.rs:2 return &*~1; ^~~~ test.rs:1:22: 3:2 note: reference must be valid for the anonymous lifetime #1 defined on the block at 1:21... test.rs:1 fn get_one() -> &int { test.rs:2 return &*~1; test.rs:3 } test.rs:2:5: 2:16 note: ...but borrowed value is only valid for the statement at 2:4 test.rs:2 return &*~1; ^~~~~~~~~~~ error: aborting due to previous error $
        
        Ha, ça compile pas, en effet.
        
        [^] # Re: Rust vs Go
        
        Posté par Anthony Jaguenaud le 11 avril 2014 à 23:01. Évalué à 3.
        
        Ton exemple est drôle. En le relisant, j’avais repéré le bug potentiel. Même si sans valgrind, je pense que ça passe sans bug dû à la façon dont c’est implémenté.
        
        Si on prend une analogie merveilleuse : (toute analogie est forcément foireuse, mais il ne faut rien me dire)
        Pour une voiture on a :
        
        un conducteur,
        
        un mécano,
        
        un ingénieur motoriste.
        
        Personnellement, je ne m’attends pas à ce que le conducteur me dise ce qui ne va pas dans mon moteur.
        Le mécano pourra réparer, bricoler parce qu’il a l’expérience, il sait ce qui casse. Il pourra conseiller pour éviter la casse.
        L’ingénieur lui pourra ré+aléser les soupapes…
        
        Ici, vous chercher un langage de mécano pour faire de l’ingénierie moteur. Je pense qu’on se trompe de débat. Un bon mécano, en achetant les pièces fera un bon moteur, mais pour faire encore mieux, il faudra un ingénieur motoriste pour imaginer et faire les pièces.
        
        Je pense que ce n’est ni le même niveau de compétence, ni le même niveau d’exigence. Arrêtez de crier sur les ingénieurs motoristes parce que vous n’êtes que mécano… pfff, heureusement on est encore vendredi. ;-)
        
        [^] # Re: Rust vs Go
        
        Posté par TeXitoi (site web personnel) le 11 avril 2014 à 23:25. Évalué à 5. Dernière modification le 11 avril 2014 à 23:27.
        
        Personnellement, je ne m’attends pas à ce que le conducteur me dise ce qui ne va pas dans mon moteur.
        
        Le problème, c'est qu'en C++, le réglage de l'injection est plus accessible que l'accélérateur.
        
        [^] # Re: Rust vs Go
        
        Posté par Meku (site web personnel) le 12 avril 2014 à 12:00. Évalué à 7.
        
        fn get_one() -> &int { return &*~1; }
- [^] # Re: Rust vs Go
  
  Posté par barmic le 09 avril 2014 à 09:11. Évalué à 4.
  
  Mais au prix d'un apprentissage bien plus élevé.
  
  J'ai l'impression que c'est carrément un vrai concurrent au C++ à ce niveau là aussi complexe l'un que l'autre :)
  
  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 Firwen (site web personnel) le 09 avril 2014 à 10:51. Évalué à 9. Dernière modification le 09 avril 2014 à 10:52.
    J'ai l'impression que c'est carrément un vrai concurrent au C++ à ce niveau là aussi complexe l'un que l'autre :)
    
    C'est clairement un concurrent à C++ dans le domaine de la prog système, des services lourds ou du HPC.
    
    Ceci dit, je n'irai pas jusqu'a dire qu'il est aussi complexe que C++ : Rust est plus jeune et ça se voit.
    Il ne souffre pas de 20 ans de compatibilité avec le C et de problème de design ( throw ? ahah )
    - il y a un système de modules et non une ABI dégueulasse qui casse à chaque changement dans la vtable.
    - Le système de macro de Rust ne te crache pas 5 pages d'erreurs à la première erreur de typage dans ton template contrairement à C++
    - Le memory management par ref counter est intégré au language… et non intégré au template si Dieu le veut en version cx11…
    - la librairie standard te fournit autre chose que ton bash et ton couteau.
    - un système d'IO correcte qui ne t'oblige pas à redescendre à des appels posix ou à te pendre avec Boost:Asio.
    Il y a une belle évolution et sincèrement j'en salive presque.
    - [^] # Re: Rust vs Go
      
      Posté par ariasuni le 09 avril 2014 à 13:54. Évalué à 2.
      
      Rust est infiniment moins complexe que le C++, non seulement parce que c'est inutile, mais aussi parce que ça prendrais des années. Le nombre de fonctionnalités de Rust est peu élevé par rapport à ce qu'il permet de faire.
      
      Le but pour la 1.0 c'est d'avoir un truc propre sur lequel on puisse greffer des fonctionnalités de manière rétrocompatible.
      
      Écrit en Bépo selon l’orthographe de 1990
    - [^] # Re: Rust vs Go
      
      Posté par barmic le 09 avril 2014 à 14:01. Évalué à 5.
      C'est grosso modo ce que voulait dire le smiley.
      
      la ~~librairie~~ bibliothèque standard te fournit autre chose que ton bash et ton couteau.
      
      J'aime bien reprendre cette erreur non pas parce que c'est une faute de traduction, mais parce que la bibliothèque véhicule une notion de partage plus forte que la librairie que tu dois payer pour une location.
      
      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 Trollgouin le 09 avril 2014 à 17:10. Évalué à 1.
      la librairie standard te fournit autre chose que ton bash et ton couteau.
      
      Mouais. Je ne suis pas un fan des grosses bibliothèques standard qui font tout et n'importe quoi. Je trouve que ça renforce la difficulté à faire évoluer le langage tout en maintenant un bonne rétro-compatibilité. (On finit par des piles de trucs deprecated, ou des redondances dans les fonctionnalités de ladite bibliothèque standard -je pense à java en écrivant ces lignes).
      
      À bien y réfléchir, je ne vois pas de problème à vivre avec un langage et sa bibliothèque de base, plus une ou plusieurs autres bibliothèques externes qui vivront leur vie indépendamment, et pourront même être remplacées par d'autres bibliothèques plus intéressante qui pourraient émerger.
      
      Le memory management par ref counter est intégré au language
      
      Le bonheur! Je rêve d'un pointeur à la refcounter en C++ aussi simple à déclarer que le pointeur natif.
      Un truc avec un symbole alternatif à l'étoile du genre:
      
      Lapin $l = new Lapin; // Vive le sucre syntaxique
      
      et non intégré au template si Dieu le veut en version cx11…
      
      Il y a des compilos c++11 qui n'intègrent pas les shared pointer?
      - [^] # Re: Rust vs Go
        
        Posté par Shuba le 09 avril 2014 à 17:24. Évalué à 8.
        
        auto l = std::make_shared<Lapin>();
        
        Je trouve pas ça trop long à écrire.
        
        [^] # Re: Rust vs Go
        
        Posté par Trollgouin le 10 avril 2014 à 18:49. Évalué à 3. Dernière modification le 10 avril 2014 à 18:53.
        
        auto l = std::make_shared();
        
        Je trouve ça long, et inutilement verbeux pour un truc aussi courant.
        
        Deux exemples du même prototype, avec et sans pointeur managé:
        
        shared_ptr<Ragout> OrganiserFestin( shared_ptr<Loup>, shared_ptr<Lapin>, shared_ptr<Carotte>) Ragout* OrganiserFestin( Loup*, Lapin*, Carotte* );
        
        J'ai la faiblesse de trouver le second plus lisible. Autant, quand c'était du pur boost, je trouvais la notation smart pointer template adéquate (ajout d'une fonctionnalité sans modifier le core language), autant je me dis que pour une nouvelle norme, on pourrait avoir un peu de sucre syntaxique sympathique.
        
        Je remercie d'ailleurs mosfet de sa suggestion de lecture microsoftienne.
        
        Ragout^ OrganiserFestin( Loup^, Lapin^, Carotte^);
      - [^] # Re: Rust vs Go
        
        Posté par mosfet le 10 avril 2014 à 08:56. Évalué à 2.
        
        Le bonheur! Je rêve d'un pointeur à la refcounter en C++ aussi simple à déclarer que le pointeur natif.
        
        Chez Crosoft ils appellent ca le C++/Cx et la syntaxe est la suivante :
        
        Lapin^ l = ref new Lapin;
        
        J'avoue que j'aimerais bien avoir çà dans gcc/clang.
        
        [^] # Re: Rust vs Go
        
        Posté par Moonz le 10 avril 2014 à 09:13. Évalué à 9.
        
        Ils auraient dû appeler ça Perlish C++
      - [^] # Re: Rust vs Go
        
        Posté par tyoup le 10 avril 2014 à 23:17. Évalué à 1.
        
        On finit par des piles de trucs deprecated, ou des redondances dans les fonctionnalités de ladite bibliothèque standard -je pense à java en écrivant ces lignes
        
        Youpi réinventons la roue carrée.
        
        Lapin $l = new Lapin; // Vive le sucre syntaxique
        
        C'est, je crois :
        
        Lapin ^l = new Lapin;
  - [^] # Re: Rust vs Go
    
    Posté par Thom (site web personnel) le 09 avril 2014 à 13:00. Évalué à 4.
    
    Disons que Rust est vraiment peu permissif. Le moindre truc un peu louche et c'est une erreur de compilation.
    
    La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
    - [^] # Re: Rust vs Go
      
      Posté par ariasuni le 09 avril 2014 à 14:06. Évalué à 3.
      
      Les problèmes de durée de vie peuvent être ennuyeux, c'est sûr. Ça demande un peu de pratique pour bien cerner le problème, mais après on comprends mieux ce qu'il se passe, et ça empêche de nombreuses erreurs.
      
      Écrit en Bépo selon l’orthographe de 1990
- [^] # Re: Rust vs Go
  
  Posté par ariasuni le 09 avril 2014 à 14:13. Évalué à 4.
  
  De plus il n'apporte aucun concept qui le rendrait attirant aux yeux des dev C++ (on se gave pas de 10 de C++ pour ensuite changer).
  
  C'est faux, pourquoi les gens font du Java/Python/C#/Go/etc? Parce que c'est plus simple.
  
  Juste que j'ai toujours une grosse crainte de la part de Mozilla qui gèrent ses projets comme des barbouzes.
  
  Pourquoi tu dis ça? Dans tous les cas, ce projet est géré un peu différemment des autres, par exemple il ne s'appuie pas du tout sur l'infrastructure de Mozilla mais utilise les réseaux où tout le monde etc: Github, Reddit, StackOverflow…
  
  Et il y a une grosse communauté derrière.
  
  Écrit en Bépo selon l’orthographe de 1990
# Android

Posté par 🚲 Tanguy Ortolo (site web personnel) le 09 avril 2014 à 10:13. Évalué à -4.

Plateformes prises en charge

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

Correction, Rust fonctionne sous Linux (diverses distribution) notamment Android, puisque ce système d'exploitation est une distribution Linux.
- [^] # Re: Android
  
  Posté par Letho le 09 avril 2014 à 13:30. Évalué à 10.
  
  Pas d'accord, « Linux » est ici une métonymie pour parler des distributions GNU/Linux.
  On ne parle pas pour les autres systèmes de noyau NT ou de XNU, mais bien de Windows et OS X.
  
  Dans cette optique, séparer Android de « Linux » est tout à fait pertinent.
  - [^] # Re: Android
    
    Posté par 🚲 Tanguy Ortolo (site web personnel) le 09 avril 2014 à 14:36. Évalué à -1.
    
    GNU/Linux est un terme approprié pour désigner les distributions GNU/Linux, en revanche le terme Linux tout court ne porte aucune ambiguïté : il désigne le noyau Linux, utilisé par bon nombre de distributions, par exemple Android.
    
    Si on veut séparer Android, il faut parler de GNU/Linux, parce qu'Android est un système qui utilise Linux.
    - [^] # Re: Android
      
      Posté par Letho le 09 avril 2014 à 19:05. Évalué à 10.
      
      Non, le terme Linux n'est (malheureusement) pas dénué d’ambiguïté.
      
      Dans la phrase « Rust fonctionne désormais sous Windows (7, Server 2008 R2) seulement x86, Linux (diverses distributions) ARM, x86 et x86-64, OSX 10.6 ("Snow Leopard") et ultérieurs x86 et x86-64, ainsi que Android. », on parle de toute évidence de systèmes d'exploitation, pas de noyaux.
      
      Et en terme de système d'exploitation, ce n'est pas parce qu'un programme tourne sur « Linux » en tant que distribution GNU/Linux qu'il tournera sur Android, de la même façon qu'une application OSX ne tournera pas sur iOS, qui partage pourtant le même noyau.
      
      Donc oui, faire la différence est à mon sens utile. Le tout, c'est de se mettre d'accord sur ce qui se cache derrière la métonymie « Linux ». Et comme en matière de facilité de langage, c'est l'usage courant qui l'emporte, je pencherai pour GNU/Linux.
      - [^] # Re: Android
        
        Posté par gUI (Mastodon) le 10 avril 2014 à 09:02. Évalué à 4.
        
        Faudrait peut-être aussi ressortir l'oublié "POSIX". Parce que dire GNU/Linux, ça sous-entend que seule l'implémentation du GNU permet de faire du Rust, ce dont je doute très fort.
        En même temps, on peut objecter que GNU/Linux n'est pas strictement POSIX (en général il l'englobe et fait plus). Donc on pourrait dire "POSIX based" ou en bon Français : "système d'exploitation qui ressemble de près ou de loin à POSIX, mais quand même assez pour faire que ça marche aussi".
        
        Ou alors on reste sur "Linux" et on se dit que tout le monde a compris :)
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Android
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 10 avril 2014 à 11:24. Évalué à 2.
        
        Au contraire, tout le monde n'a visiblement pas compris. C'est simple : pour les gens précis, Linux désigne un noyau de système d'exploitation. Après, pour des locuteurs un peu vagues mais cohérents, ça peut désigner les systèmes basés sur ce noyau. Et pour des gens imprécis, ça peut pas abus de langage désigner des systèmes basés sur Linux et GNU, excluant ainsi sans raison sensée le système Android pourtant basé sur Linux.
        
        Dans le doute, on va voir Wikipédia : dans la version française comme dans la version anglaise, la page Linux tout court parle de systèmes basés sur le noyau Linux, incluant évidemment Android comme exemple.
        
        [^] # Re: Android
        
        Posté par barmic le 10 avril 2014 à 13:36. Évalué à 1.
        
        Et pour des gens imprécis, ça peut pas abus de langage désigner des systèmes basés sur Linux et GNU […]
        
        Les gens précis (dont tu semble vouloir faire parti) font donc un gros fuck aux projets Apache, *BSD et autre totalement indépendant ?
        
        Dans le doute, on va voir Wikipédia
        
        Les gens qui pensent comme une encyclopédie sont généralement inapte à la communication en société (un peu comme Sheldon Cooper dans Big bang theory si tu regarde). Tout simplement parce qu'ils placent la vérité scientifique avant l'humain et ses défauts. Ayons des défauts ! Moi, mon ordinateur est sous linux alors que mon téléphone est sous android.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Android
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 10 avril 2014 à 16:16. Évalué à 1.
        
        Les gens précis (dont tu semble vouloir faire parti) font donc un gros fuck aux projets Apache, *BSD et autre totalement indépendant ?
        
        Je ne comprends pas, peux-tu préciser en quoi je serais insultant envers ces projets ?
        
        Les gens qui pensent comme une encyclopédie sont généralement inapte à la communication en société (un peu comme Sheldon Cooper dans Big bang theory si tu regarde). Tout simplement parce qu'ils placent la vérité scientifique avant l'humain et ses défauts. Ayons des défauts ! Moi, mon ordinateur est sous linux alors que mon téléphone est sous android.
        
        Ton ordinateur est sous Linux et ton téléphone aussi, avec une distribution très différente. Si tu veux être exact, tu peux aussi préciser que ton ordinateur tourne sous GNU/Linux et ton téléphone sous Android.
        
        [^] # Re: Android
        
        Posté par barmic le 10 avril 2014 à 16:29. Évalué à 4.
        
        Je ne comprends pas, peux-tu préciser en quoi je serais insultant envers ces projets ?
        
        Les ignorer c'est forme insulte assez importante. Ta distribution autour de linux est loin d'utiliser uniquement des logiciels GNU et je veux bien une preuve qu'elle utilise majoritairement du GNU par exemple. Mettre en avant GNU par rapport aux autres c'est à peu prêt la même chose que de dire linux et pas GNU/Linux.
        
        Si tu veux être exact […]
        
        Je m'en fou d'être exact. Il m'arrive d'être imprécis ou de me tromper et j'ai pas envie d'être une encyclopédie ambulante. wikipedia est là pour ça.
        
        Tu es du genre à faire répéter 40 fois le même mot aux touristes que tu croise parce qu'on ne dis pas « bonwourr » mais « bonjour » ? (hé ho faut pas déconner avec la langue français, faut se battre pour la défendre)
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: Android
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 10 avril 2014 à 16:51. Évalué à 3.
        
        Les ignorer c'est forme insulte assez importante. Ta distribution autour de linux est loin d'utiliser uniquement des logiciels GNU et je veux bien une preuve qu'elle utilise majoritairement du GNU par exemple. Mettre en avant GNU par rapport aux autres c'est à peu prêt la même chose que de dire linux et pas GNU/Linux.
        
        GNU fournit la libc, qui est le second composant essentiel d'un système. X.Org fournit le système de fenêtrage X11, sur lequel beaucoup de logiciels comptent. Le reste est important pour l'utilisation du système, mais beaucoup moins pour le travail de portage de logiciels, qui est ce dont il s'agit lorsqu'on parle de logiciels disponibles pour GNU/Linux.
        
        Tu es du genre à faire répéter 40 fois le même mot aux touristes que tu croise parce qu'on ne dis pas « bonwourr » mais « bonjour » ? (hé ho faut pas déconner avec la langue français, faut se battre pour la défendre)
        
        Si j'entends quelqu'un se tromper dans une discussion, généralement je le corrige en effet. Heureusement, sinon comment pourrait-il progresser ?
# [rust-dev] Reminder: ~[T] is not going away

Posté par potate le 09 avril 2014 à 20:52. Évalué à 4.

… et ~[T] a disparu.
https://mail.mozilla.org/pipermail/rust-dev/2014-April/009352.html
- [^] # Re: [rust-dev] Reminder: ~[T] is not going away
  
  Posté par ariasuni le 09 avril 2014 à 23:38. Évalué à 2.
  
  Je l’avais lu mais j’ai pas pensé à modifier la dépêche, c’est assez chronophage de suivre toutes les modifications du langage, sachant qu’en plus des modifications qui intéressent les développeurs Rust, il y a aussi les changements internes à surveiller…
  
  Merci pour ce lien.
  
  Écrit en Bépo selon l’orthographe de 1990
# Evénements en Rust ?

Posté par ziliss le 09 avril 2014 à 22:47. Évalué à 3.

D'après ce que j'ai compris, Rust et la programmation événementielle ne font pas bon ménage.

D'après ce que j'ai compris, le problème serait l'enregistrement des listeners, car le compilateur ne peut pas déterminer la durée de vie des pointeurs vers les listeners, ni vérifier qui y a accès. Cela obligeant à utiliser le garbage collector.

Du coup j'imagine que c'est le même problème pour les callback et la programmation asynchrone… Je connais pas Rust, mais si quelqu'un a plus d'infos ou des explications plus précises, ça m'intéresse.
# On dirait une pub pour un marabout !

Posté par dinomasque le 09 avril 2014 à 22:51. Évalué à 7.

"Rust est un langage de programmation système qui est extrêmement rapide, empêche presque tous les plantages et élimine les accès concurrent."

Et niveau retour de l'être aimé et chance aux jeux et aux examens, il faut attendre le patch ?

Plus sérieusement, avec une formule choc aussi rigolotte, je m'attendais à une justification de ces propriétés miraculeuses du langage dans le corps de la dépêche, mais rien :(

BeOS le faisait il y a 20 ans !
- [^] # Re: On dirait une pub pour un marabout !
  
  Posté par Thom (site web personnel) le 09 avril 2014 à 23:33. Évalué à 3.
  
  L'un des principaux intérêts revient sans doute au fait que si tu essayes d'écrire une variable de manière non sécurisée : plus ou moins en même temps, tu as le droit à une belle erreur de compilation (accès concurrents).
  
  Bref, il ne les élimine pas par magie, mais il ne les permet pas à ton programme de compiler s'il y a ce risque.
  
  La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
- [^] # Re: On dirait une pub pour un marabout !
  
  Posté par Thom (site web personnel) le 09 avril 2014 à 23:40. Évalué à 4.
  Un petit exemple :
```
fn main() {
    let mut n = 10;
    spawn(proc() { count("A", n); });
```
  Erreur de compilation (error: mutable variables cannot be implicitly captured) car la variable ne peut être partagé.
  
  La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
- [^] # Re: On dirait une pub pour un marabout !
  
  Posté par ariasuni le 09 avril 2014 à 23:48. Évalué à 3.
  
  Et pourtant c’est bien ce qu’il fait. :p Bon bien sûr, cette phrase reflète ce que devrait être Rust en 1.0, vu que côté vitesse il y a encore pas mal de trucs qui méritent des optimisations, quelques bugs qui permettent encore à quelques erreurs de segmentation de passer, etc.
  
  Après regarde ce qui se dit sur le site de Go:
  
  Go est un langage de programmation open source qui rend facile la construction de logiciel simple, fiable et efficace.
  
  Et sur le site de D:
  
  D est un langage avec une syntaxe proche du C et un typage statique. Il combine de façon pragmatique l’efficacité, le contrôle, et la flexibilité dans la conception avec la sûreté et la productivité.
  
  Écrit en Bépo selon l’orthographe de 1990
# Humour

Posté par ariasuni le 10 avril 2014 à 00:54. Évalué à 6. Dernière modification le 10 avril 2014 à 00:55.

Le nom du sous-Reddit consacré à Rust a encore changé! L’autre jour c’était «The Rust programming lagrange», aujourd’hui c’est «The Rust programming Fromage».

Avec comme description, l’autre jour:

Anything whatsoever related to the Rust programming Lagrange: an open-source systems programming language from Mozilla, emphasizing safety, concurrency, speed, and establishing positions in space where the combined gravitational pull of two large celestial bodies provides precisely the centripetal force required to orbit with them in relative stasis.

Et aujourd’hui:

Anything whatsoever related to the Rust programming fromage: an open-source systems programming language from Mozilla, emphasizing safety, concurrency, speed, and, how you say, je ne sai quoi.

On peut remarquer le «6. Genndy Tartakovsky is infallible».

Rappelons que le sous-Reddit est complètement géré par la communauté… qui a le sens de l’humour apparemment. :p

P.-S.: je trouve ça étonnant que personne n’ai fait de réflexion sur le logo de Rust, je le trouve vraiment classe.

Écrit en Bépo selon l’orthographe de 1990
- [^] # Re: Humour
  
  Posté par Psychofox (Mastodon) le 10 avril 2014 à 13:23. Évalué à 5.
  
  P.-S.: je trouve ça étonnant que personne n’ai fait de réflexion sur le logo de Rust, je le trouve vraiment classe.
  
  Moi j'aime bien parce que je suis cyclitse.
  - [^] # Re: Humour
    
    Posté par tyoup le 10 avril 2014 à 23:33. Évalué à 2.
    
    C'est clair ça dérouille.