Uther Lightbringer a écrit 57 commentaires

Je le répète encore, les benchmark inter-langages sont toujours a prendre avec des pincettes. Il est très facile de produire involontairement(ou non) un code qui avantage un langage ou l'autre.
Ceci dit, en moyenne sur les divers benchmarks que j'ai vu Rust était sensiblement plus rapide. Je n'arrive pas a retrouver le lien vers les benchmarks les plus précis, mais les premiers résultats que me donne google sur une recherche 'rust go benchmark' semblent confirmer cela en gros.

Les benchmarks ou Rust est en retrait par rapport aux autres langages, sont en général ceux qui font beaucoup d'opérations d'entrée/sortie. Sur ce point là en effet Rust est encore en gros travaux, le module std::io devrait être complètement revu d'ici la sortie de la version 1.0. Il devrait être remplacé par le module std::rt::io (encore expérimental pour le moment) qui s'appuie sur le nouveau runtime.

C'est là ou on voit bien que Rust est un langage à typage statique bien que l'inférence de type peut donner l'impression inverse.

Pour info le dans le message d'erreur indique un type que le compilateur n'a pas encore été totalement déterminé par inférence. Ils auraient pu trouver une notation plus parlante mais on s'y fait vite.

Tout dépend ce qu'on appelle rapide.
Si c'est de vitesse de compilation dont tu parle, en effet Go est excellent et très loin devant Rust et C++.
Si tu parles de la vitesse du code généré, Rust est en moyenne(bien sur c'est forcément variable d'un benchmark à l'autre) meilleur que Go.

Pour le coup je comprend un peu les réactions. C'est vrai que c'est un peu plus compliqué de raisonner avec les différent types de pointeurs ~, ~, et & et plus particulièrement avec les région. Mais il faut bien comprendre que c'est ce qui fait une grosse partie de l’intérêt de Rust : il vous oblige a bien réfléchir au la durée de vie des variables et ne compile pas tant que ce n'est pas fait.

C'est vrai que ça peut paraître plus facile dans d'autre langages, mais cette facilité à un coût :
- La prédictibilité des performances pour les langages full GC comme Java, Go, …
- La sécurité et la stabilité en cas d'erreur pour les langages comme C/C++ avec lesquels ça peut très facilement provoquer des erreurs.

A voir si on est prêt à le payer le coût. Je ne pense pas que Rust soit le meilleur langage pour tout, mais il a clairement un intérêt si on veut une langage au performance prédictibles à la C++, D, …

Je pense au contraire que le jeu vidéo est un des domaines ou Rust me parait le plus à ça place.
Parmi les avantage qui me viennent en tête je vois :

• Il est assez proche de C++ au niveau des performances (se baser sur l'infrastructure LLVM ça aide).
• Il ambitionne une gestion plutôt poussée de la concurrence, ce qui est clairement le voie pour profiter de meilleures performances avec les machines modernes.
• Il reste orienté bas niveau et laisse le choix a l'utilisateur de la façon dont il souhaite gérer chaque élément en mémoire (pile, tas, gc,…)
• L'utilisation de la mémoire est très surveillée, ce qui permet d'éviter dès la compilation la plupart des erreur liées à la gestion mémoire, ce qui est clairement une des principale sources de bugs dans ce genre programmes.
• Il y a la possibilité d'utiliser des bloc "unsafe" pour bypasser sporadiquement les contrôles quand on sait ce que l'on fait
• Possibilité d'utiliser un GC uniquement pour les tache non critique qui ne bloquera pas les autres.
• Il s'interface assez simplement avec le C, ce qui permet de profiter d'une grande partie des bibliothèques existantes.

Bref je dirais que Rust offre a la fois la puissance et la finesse d'action de C tout en étant bien plus surveillé par défaut. Mais cette surveillance ce faisant principalement à la compilation, ça n'affecte presque pas les performances finales.

Je pense que son affirmation est un peu trop dure. Go tient compte de certaines choses qui a été fait ces dernières années, le système d'interface par exemple est inspiré de Java.

Pour les principales fonctionnalités qui à mon sens manquent à Go je dirais:
- Les génériques/template
- Mémoire isolée entre les taches
- Les nombreux petits points qui permettent d’éviter de faire du code erroné (immutabilité par défaut, absence de pointeurs null, …)
- Garbage Collector optionnel

Bref Go est a mon avis plus une alternative à Java alors que Rust serait plutôt une alternative à C++. A prendre cette affirmation avec des pincettes bien sur. Faire un parallèle entre deux langages est toujours forcément approximatif.

En fait l'ancien runtime a été remplacé par défaut l'ancien, il y a une ou deux version déjà. Mais le nouveau runtime en Rust n'a pas encore toute les fonctionnalités définitives et il en manque encore par rapport à l'ancien, notamment les piles segmentées.

Pour les I/O si elles sont en chantier, c'est en grande partie parce qu'elles attendaient le nouveau runtime qui devrait leur permettre d'être plus efficace. Dans Rust 0.8, le module "rt::io" qui repose sur le nouveau runtime a été introduit. Il est encore considéré expérimental pour le moment.

Ce que je voulais dire c'est que "zero.rs" ne retire pas l'OS comme on pourrait le comprendre en lisant ton article. Il permet de retirer du code le "runtime" : le noyau de code dépendant de l'OS qui permet le déroulement du reste du code. Dans le cas de rust, le Runtime permet de gérer notamment les piles segmentées, les Thread légers(Tasks), les I/O, le collecteur de cycle…

Le fait de ne pas avoir de runtime, permet donc de faire du code de très bas niveau, comme c'est nécessaire pour écrire un driver, un logiciel hors OS, un OS vu que c'est juste un cas particulier d'un logiciel hors OS. C'est donc en effet nécessaire pour tourner sur des microcontroleurs simples utilisés dans les machines embarquées ou du moins ultra-spécifiques.
Ça permet aussi de s'interfacer plus facilement avec d'autre langages vu qu'il on de fortes chance de ne pas aimer les fonctionnalités du runtime rust(c'était le cas des piles segmentées).

D'ailleurs, pour info, une grosse partie de la 0.8 et qui est encore en cours consiste à remplacer l'ancien runtime en C++ par un nouveau écrit en Rust. Il devrait avoir un système de planification des Task plus intelligent et améliorer les I/O.

Attention ne t’emballes pas trop quand même, RusticOS, est très loin d'être un OS loin de la. Pour le moment c'est juste un POC qui montre qu'il est théoriquement possible de faire un OS en Rust. Il se contente d'afficher un message au boot et de boucler. Il y en avait déjà un du même style qui reposait sur zero.rs si ma mémoire et bonne.

D'ailleurs pas mal des projets que tu as cité dans l'article sont intéressant sur le papier, mais la certains sont dans un état bien trop primaire pour être déjà vraiment utilisables. Je pense que détailler l'utilisabilité de chacun, n'aurait pas été inutile.

C'est sympathique de voir qu'il y a pas mal d'activité autour de Rust, mais il ne faut pas non plus laisser croire que tout est déjà opérationnel, on en est encore loin.

En y réfléchissant bien, je pense que ce que la confusion que tu as faite vient du fait que générer du code sans runtime est un prérequis pour faire du code système comme celui d'un OS ou de drivers.

Merci pour l'article très complet. Je suis avec intérêt l'évolution de Rust depuis quelque temps maintenant. J'ai cependant trouvé deux petites erreurs dans l'article, qu'il faudrait corriger :

• Comme tu le dis déjà, les pointeurs managé ne sont actuellement pas gérés par un ramasse-miettes, se sont en effet actuellement des pointeurs intelligents. Mais il y a déjà un "Cycle collector" sur ces pointeurs qui permet de résoudre les références circulaires.
  Un vrai ramasse-miettes devrait cependant permettre d'améliorer les performances a l'avenir.

• "zero.rs" ne permet pas de supprimer l'OS mais le "runtime" du programme (un morceau de code qui gère le déroulement du reste du code). A noter d'ailleurs que "zero.rs" n'est plus nécessaire. Il suffit actuellement de poser une annotation pour produire un programme sans runtime.

Pour avoir un article de bonne qualité et objectif entre D et Rust: http://versusit.org/rust-vs-d
Désolé pour l'anglais mais au moins la conclusion est courte (commencer par là)

L'article en question est certainement un des plus mauvais que j'aie pu lire sur le sujet de D et Rust réunis:
- Il fait une comparaison très superficielle sur la syntaxe, pas de la moindre fonctionnalité.
- Il utilise une notation inutilement verbeuse pour Rust.
- Il utilise des syntaxes qui ont disparu il y a longtemps de Rust(a la limite ok) voire qui n'ont jamais existé(traitement d'erreur)

Le tout pour arriver a une conclusion assez péremptoire, digne d'une cour de récré, et qui ne m'aurait même pas convaincu si je ne connaissait pas le Rust.
Il y a beaucoup de chose que l'on peut vraiment reprocher à Rust même sur la syntaxe (les régions notamment), il n'en site pas une seule. Cet article donne juste l'impression de voir un supporter de D frustré qui a jeté un coup d'oeil en 30 secondes à Rust pour essayer de trouver des arguments pour le descendre, et encore il n'a pas choisi les bons.

Autant on peut reprocher des inexactitudes à l'article publié sur LinuxFr en ce qui concerne la situation du D, autant il ne prétend pas faire un comparatif précis des langages, juste de comparer les débuts de chacun des langages.
L'article que tu cites est complètement partisan, terriblement superficiel et faux de surcroit.

En effet, c'est une coquille de l'équipe de traduction. Ça sera corrigé dans le prochain patch.

Pour information, il s'agit d'une API qui permet a tous les protocoles de messagerie de s'intégrer. Facebook est malheureusement, le seul qui s'y soit intéressé, mais rien n'empêche un protocole ouvert d'en bénéficier.

Pour le JavaScript, je pense que c'est clairement une bonne décision. Cette option n'est utile qu'aux utilisateurs avancés qui ont besoin en général d'un comportement fin et auront a coup sur déjà installé NoScript.
Au contraire, l'utilisateur lambda peut totalement pourrir sa navigation quotidienne s'il l'active l'option par erreur.

Autant pour moi, je ne savais pas de c'était faisable avec un serveur de base. A priori, c'est surtout pour permettre de jouer sur une LAN non reliée a l'internet.
Mojang ayant toujours indiqué qu'il considérait illégal les systèmes qui permettent de jouer sans acheter le jeu.

Exact, sauf qu'un serveur normal ne peut pas être configuré pour accepter des joueurs n'ayant pas acheté le jeu.
Les serveurs qui permettent cela sont des serveurs pirates qui enfreignent la licence.

La limite de hauteur dans Minecraft a été changée depuis la version 1.2, elle a été doublée par défaut, et on peut désormais la configurer dans les options du serveur.

Le format des mondes n'est pas documenté par Mojang, mais il est bien connu des développeur de mods. Il y a pas mal d'outils qui servent à le manipuler. Créer un outil de conversion ne devrait pas poser de problèmes techniques

Pour ce qui est de payer, il n'y a pas d'abonnement.

En même temps c'est bien ce que c'est : un gros clone de Minecraft qui va jusqu'à recopier le style graphique et l'interface.

Autant Minecraft, même s'il s'est clairement inspiré d'Infiniminer, ne s'est pas contenté de le cloner.

En l’occurrence dans la phrase "Google rit, Oracle pleure", il s'agit bien du présent de l'indicatif, il faut dont bien ajouter un "t" a "ri"

Il y a clairement moins de contributeurs sur Thunderbird que sur Firefox, mais il n'est pas mort, loin de là. Il y a notamment des modifications de l'interface prévues pour les versions a venir.

Si mes souvenir sont bons, c'est dans la préface du premier livre des robots.

En fait La wii est bien vérouillée contre l'utilisation de programmes non signés, comme la plupart des consoles. Actuellement, pour exécuter du code, il faut passer par une sauvegarde modifiée Zelda appelé Twilight hack. Le nom du cheval de Link a été modifié pour exploiter une faille de buffer overflow. On exécute ainsi un fichier particulier de la carte SD.
On peut ainsi démarrer une application sans rien modifier à l'OS ni même à la mémoire flash interne de la console, si ce n'est l'installation d'une sauvegarde de jeu modifiée. Tout est sur la carte SD.

Cependant pour ne pas avoir à démarrer Zelda et charger la fausse partie sauvegardée à chaque fois, en général, dès la première utilisation on installe généralement une "chaine wii" non officielle. Une chaine wii est une application disponible directement sur l'écran menu de la wii; normalement ces chaine sont téléchargées depuis la boutique ou installées par des jeux. Le "homebrew channel" permet d'afficher un menu des application à démarrer sur la carte SD. xwhiite-linux se présente donc comme une application normale dans le homebrew channel.

C'est une parodie du projet de loin en préparation en France pour que chaque écolier porte la mémoire d'un enfant juif, mort pendant la shoa dont il deviendrait en quelque sorte le parrain.
Ce projet de loi fait énormément polémique sur jusqu'à quel point doit aller la repentance et s'il n'est pas un peu morbide pour des enfants encore jeunes d'être associé à un autre enfant mort.

C'est une spécificité DLFP que faire des news ciné complètement HS de temps en temps Ca permet de ne pas oublier qu'iln'y a pas que Linux dans la vie"

Ca m'étonnerait fortement que les constructeurs portent android vers les téléphone déjà commercialisé, ca serait vraient un enorme boulot pour un retour quasi nul.

A mon avis il faudra guetter les prochaines sorties de téléphones.