Mozilla publie la version finale de son langage de développement Rust

Khalev a écrit :



Un benchmark datant des alentours du 24 avril (donc ça a pu s’amélioré depuis):

http://www.viva64.com/media/images/content/b/0324_Criticizing-Rust-Language-Why-…





A terme il n’y a aucune raison pour que Rust soit plus lent que le C++ : ses abstractions ont un coût nul par rapport à ce qu’écrirait un dév C++ : toute la question de la gestion mémoire est résolue à la compilation.



Bon, pour l’instant cela dit le compilateur conserve certains sécurités à l’exécution (boundaries checks par exemple), du fait de l’orientation sécurité de ce langage, mais on trouvera bien des compilateurs pour les désactiver à l’avenir.









brokensoul a écrit :



intéressé, un peu curieux de voir à quel point c’est rapide et sûr. C++ c’est quand même bien amélioré question rapidité de codage avec les derniers /11 et /14, mais j’imagine bien qu’il est possible de faire mieux. Un peu surpris qu’il soit possible de faire aussi rapide que c++ sans jouer avec les pointeurs, j’attends des benchmarks :) (quelqu’un a testé ?)





Le principe sous-jacent du système de types de Rust est de générer un code de gestion de la mémoire aussi efficace que celui que tu aurais pu écrire manuellement.









TexMex a écrit :



C’est quand même utile pour un compilateur de savoir si tu traite du nombre et / ou autre chose.

Mais tant qu’on aura pas de vrais solution d’accompagnement (Tu sélectionnes tes 10 lignes et tu les tagges “integer”) et pas seulement un editeur de texte, bin voila.





Les types sont inférés à la compilation. Le compilateur sait parfaitement qu’il traite des entiers parce qu’à un moment tu lui as fourni une entrée qui, elle, était typée comme entier, et tout le reste a été inféré correctement.









Oryzon a écrit :



ça ressemble fortement à ce qu’à présenter MS il y a quelques temps…





Au niveau système MS travaille sur deux approches, l’une ressemblant un peu à Rust pour la sécurité de la concurrence (mais avec de grosses différences quand même, chercher Joe Duffy et M#), l’autre basée sur des spécifications (spec#).









brazomyna a écrit :



Et ce problème de perf en est de moins en moins un:

 - l'impact de ce genre de pratique sur la charge CPU est constant       


 - la puissance dispo des CPU augmente régulièrement

La puissance séquentielle des CPU n’augmente plus ou quasiment plus depuis dix ans, et le ralentissement s’accélère.



Quant à la taxe elle a toujours était proportionnellement constant : n% hier, n% demain. Elle restera toujours inacceptable pour de nombreux usages et elle va le devenir de plus en plus dans un monde à la puissance CPU finie.









brice.wernet a écrit :



Les langages managés ont l’avantage énorme de permettre des choses comme le déploiement sur architectures hétérogènes, la génération de code à la volée, l’envoi de données et de morceaux de programme à d’autres process/ordis.

Il leur manque en général les SIMD/la vectorisation, ce qui est dommage.





Question de priorités. Mais le nouveau compilo C# supporte la vectorisation et JS va bientôt gagner ça dans ses standards.

lysbleu a écrit :



Une gestion mémoire semi-automatisée ? Avec les shared_ptr, elle est totalement automatique.





Bien sûr que non :

Tu dois écrire shared_ptr partout au lieu de Actor (ou Actor en D).



* Si jamais tu as un cycle dans ton graphe, ton shared_ptr va créer une fuite mémoire. Or le compilateur est incapable de détecter pour toi cette fuite et rien n’est fait pour t’aider à la détecter.



* Tu ne vas pas écrire partout shared_ptr pour des raisons de perfs, tu vas continuer à considérer systématiquement comment ta variable sera utilisée et choisir un unique_ptr, un shared_ptr, un weak_ptr, un pointeur, une référence ou une allocation in-situ. Puis tu vas décider de définir ou non la constante de compilation spécifiant l’utilisation d’un compteur non-atomique, sachant que ça a toutes les chances de te rentrer dedans à l’avenir. Autant de choses que le compilateur pourraient faire pour toi.



Ce n’est pas ce que j’appelle complètement automatisé !





Des itérateurs de 50 caractères ? “auto” : 4 lettres.



Et personne n’utilise auto. Pourquoi ? Tout simplement parce que le putain de modèle de compilation de C++ rend extrêmement difficile son analyse, ce qui fait que tous les putains d’outils sont pourris et qu’aucun putain d’IDE n’est foutu de t’afficher correctement une putain de tooltip par-dessus “auto” pour te dire quel est le vrai type de cette putain de variable. En 2015 !



Quand je code dans un langage moderne avec un IDE fonctionnel j’utilise l’inférence de types a tout bout de champ. Quand je code en C++ je n’utilise jamais “auto” parce que sur les dix plus gros IDE du marché il n’y en a aucun qui soit bon avec le C++ (seul celui de QT fait un bon boulot décent sur l’analyse).





Pour le reste, ce n’est pas très clair de quoi tu veux parler, mais je suis sûr que le C++ le fait très bien. Bref, tu ne sais pas de quoi tu parles.



" />

white_tentacle a écrit :



Rust est fait pour être un compromis entre sûreté, performance, facilité d’écrire du code. Donc quelque soit un aspect, tu trouveras à critiquer : c’est le principe d’un compromis.





Et personne ne veut de compromis, c’est bien là le problème. L’industrie du JV et d’autres ne veulent pas d’un langage deux fois plus lent et MS et d’autres ne veulent pas d’un langage un peu plus sûr pour leurs OS.



Quant au C++ il ne fait pas de compromis : il ne s’encombre pas de la sécurité, il lui crache au visage. Ce qui est une démarche acceptable dans bien des cas. Son seul problème c’est qu’il est vieux et improductif, et qu’on peut quand même faire plus vérifiable sans empiéter sur les perfs.





C’est nettement mieux que tout ce qu’on nous a vendu comme alternatives à C++ pour l’instant…



Je suis bien d’accord. Mais pour l’heure ça ne suffit pas encore. Mais comme je l’ai dit plus tôt, ce langage a le potentiel pour devenir un remplaçant au C++ avec un autre compilateur. Malheureusement cet avenir n’est pas compatible avec les objectifs actuels de Mozilla pour ce langage, qui font passer la sécurité d’abord.

white_tentacle a écrit :



C’est tout le problème de faire face à un standard établi. Si Rust et C++ avaient le même niveau de maturité / développement, en ce qui me concerne le choix serait vite fait et en faveur de Rust : les quelques avantages de C++ ne se justifient pas face à la sûreté de Rust.





C’est vite dit mais par exemple dans le JV un rapport de performances du simple au double ça veut dire laisser ton super modèle d’illumination de côté et rester sur les technos de la génération PS2-PS3.

lysbleu a écrit :



substitutions de chaîne, le pattern matching : Présent en C++ de manière standard, donc je ne vois pas de quoi il parle lorsqu’il sous-entend que c’est inexistant en C++.

Type algébrique : je ne vois pas ce qui empêche de le faire en C++.





Voici un exemple de type algébrique couplé à du pattern matching (qui, non, n’est pas présent en C++).



enum expr = Number | Addition(x, y) | Mutliplication (x,y)



def factoriseEquation(expr) match expr

 case Addition(Multiplication(a, x), Multiplication(b, x)) => Multiplication(x, Addition(a, b))   


 case \_ => expr   

Amuse-toi à écrire ça en C++. Et pas seulement un pauvre bidouillage, quelque chose qui pourrait comme ici servir de fondation à quelque chose de plus vaste. ;)



NB : l’indentation a été virée par PCI/NXI, désolé.





Linq : Apparemment c’est spécifique VS / C#, donc effectivement je ne connais pas.



Linq ou les continuations de listes dans bien d’autres langages (list continuations) permettent par exemple d’écrire :



// Parmi les étudiants ayant assisté à 90% des cours on retient les 20 avec la meilleure note moyenne

var étudiantsSélectionnés = étudiants

  where présenceAuCours > 90    


  order by notes.Average()   


  take 20   

Amuse-toi à écrire ça en C++.





types structurels anonymes



Besoin de faire une requête SQL pour ne récupérer que deux pauvres champs de la ligne ? Dans certains langages tu peux écrire :

var rows = select (name, address) from table where age > 50   

Un type anonyme est alors créé avec deux champs name et address. Tout ça est inféré à la compilation et intellisense pourra compléter.



Amuse-toi à écrire ça en C++. Pardon à faire tourner ton outil de génération de code ORM après avoir cliqué sur des boutons pour lui dire que tu as besoin de faire telle requête.





cela consiste à remettre en cause la crédibilité de l’adversaire en ignorant totalement ses arguments, ce que je n’ai pas fait.



“Pour le reste, ce n’est pas très clair de quoi tu veux parler (…) Bref, tu ne sais pas de quoi tu parles.”.

brokensoul a écrit :



avec des lambdas et la std, c’est trivial





C’était déjà trivial avant ça, le problème c’est que c’est verbeux. Moins depuis l’introduction les lambdas, mais c’est toujours verbeux, la faute à la gestion manuelle de la mémoire qui fait obstacle aux modèles fonctionnels et à l’interface des itérateurs.



Aujourd’hui ta solution reposera sur la création d’une liste puis sa mutation. Et elle fera cinq fois plus de caractères. Et pour ces raisons en C++ on optera plutôt pour des boucles. Dommage : un programmeur passe pourtant des heures par semaine à écrire ce genre de boucles.

• compilation > super rapide avec clang, sinon un petit ccache est bien efficace. Pas un problème en pratique
  
  
  
  Déni de réalité. Va dire ça aux grands noms de l’industrie qui exposent à la cppcon les efforts qu’ils doivent déployer pour garder le temps de compilation sous contrôle et le pourquoi des modules.
  
  
  
  
  


• inférence de type > jette un oeil sur c++ d’après 1995, tu as le droit de te renseigner sur ce que tu commentes. “auto”, c’est pour la poubelle ?
  
  
  
  
  
  • gestion mémoire ‘semi automatisée’ : la gestion des pointeurs est quand même super simple maintenant, et ca te donne des gains en perfs dont d’autres langages peuvent encore rêver
    
    
    
    (…)Maintenant si tu dis que tel ou tel langage super exotique fait ‘évidemment’ beaucoup mieux, reste :
    
  
  
  • à le prouver
    
    
    
    J’ai déjà répondu à cela dans ce fil, je t’invite à cliquer sur mon nom pour voir mes messages récents si cela t’intéresse.
    
    
    
    
    
  
  


• la plupart de tes critiques sur du code trop verbeux concerne les templates. Tu as le droit de ne pas les utiliser..
  
  
  
  Le problème ne réside pas dans les templates, le problème réside dans le fait de devoir avoir recours à des templates pour émuler des comportements qui sont bien mieux pris en charge autrement par d’autres langages. Ces langages ont pourtant des équivalents aux templates.
  
  
  
  
  
  (reste) à avoir un écosystème qui le rend utilisable (l’inconvénient de partir de zéro, on ne gagne pas à tous les coups)
  
  
  
  J’ai moi-même dénoncé les limites de la solution Rust à l’heure actuelle.