Rust 1.7 : le langage de Mozilla renforce encore ses bibliothèques

Rust 1.7 : le langage de Mozilla renforce encore ses bibliothèques

Sta-bi-li-sa-tion

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

07/03/2016 2 minutes
38

Rust 1.7 : le langage de Mozilla renforce encore ses bibliothèques

Mozilla a publié la version 1.7 de Rust. Depuis sa mouture finale lancée en mai dernier, le langage a beaucoup évolué et ses bibliothèques en particulier ont été étoffées. Le travail continu sur ce point, avec un accent particulier sur les fonctionnalités.

Rust est un langage développé par Mozilla pour répondre avant tout à ses propres besoins. L’idée de départ est d’obtenir un résultat proche des performances du C ou du C++, mais avec certains des avantages apportés par les langages de plus haut niveau, comme Java. Rust est l’outil principal de l’éditeur pour travailler sur le remplaçant du moteur de rendu Gecko de Firefox, Servo.

Depuis plusieurs versions, l’accent est mis sur le renforcement des bibliothèques et dans le nombre de fonctionnalités accessibles à travers elles. C’est encore le cas avec la version 1.7, même si Mozilla indique qu’à cause des périodes de vacances, certains apports n’arriveront que dans de futures moutures.

L’une des plus grosses nouveautés est le support stabilisé des algorithmes de hash personnalisés. Jusqu’à présent, Rust ne supportait que SipHash, conçu pour empêcher les attaques par déni de service. Le problème de cette méthode est qu’elle offrait des performances jugées insuffisantes, surtout quand il fallait hacher de petites clés de chiffrement. Désormais, les développeurs pourront se servir d’autres algorithmes à travers le type HashMap.

Parmi les autres nouveautés, signalons une dépréciation de la méthode relative-from, désormais renommée en strip_prefix. Cargo, le gestionnaire de paquets de Rust, évolue également. Il peut ainsi être averti quand des modifications interviennent dans les dépendances, afin de ne relancer les scripts de compilation qu’en ces cas précis. Enfin, et c’est tout aussi important, Rust 1.7 contient environ 1 300 correctifs divers.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Commentaires (38)


Vivement la fin de gecko. Genre, vraiment.


Il va falloir que tu attends quelques années.


En fait, c’est plus compliqué que ça… Il y a déjà des bouts de Servo dans Gecko.


Langage intéressant IMHO, un peu testé, mais la gestion des références est à s’arracher les cheveux (définir le scope des références à la main est très bizarre par exemple).

 Dommage qu’à vouloir faire du ‘safe’ on arrive à quelque chose moins simple à programmer que du Go par exemple, sans être forcément plus fiable (à moins que quelqu’un puisse me contredire, je n’attends que ca).




brokensoul a écrit :

 Dommage qu’à vouloir faire du ‘safe’ on arrive à quelque chose moins simple à programmer que du Go par exemple, sans être forcément plus fiable (à moins que quelqu’un puisse me contredire, je n’attends que ca).



 

Si quelqu’un a une réponse à ça, je veux bien. J’aimerai me faire la main sur un digne successeur du C, plus moderne, avec des fonctionnalités qu’on est en droit d’attendre : gestion de la mémoire moins abrupte voire directement gérée par le compilateur, simplicité du langage (pas totalement bloated façon C++), gestion clean des dépendances, compilable avec des perfs proches du C (voire 2 ou 3 fois plus lent, c’est pas un problème), qu’il soit stable et pas qui bouge tous les 6 mois…



Oh, et Haskell ça poutre. Mais il me faut un langage complémentaire compréhensible par les humains dans mes bagages.


A propos de ces langages modernes “bifaces” (ie. ergonomiques et performants) comme go, rust ou D, qu’en est-il de celui de l’équipe de microsoft qu’on a un temps appelé M# ?

Je trouve peu d’infos récentes à son sujet.

Quelqu’un sait ?


La dernière fois que j’avais regardé, rust c’était pas ça niveau stabilité (le langage est jeune et peu mature donc les api évoluent encore). Pour les autres je ne sais pas, mais ça fait un certain temps que go me fait de l’œil.








brokensoul a écrit :



Langage intéressant IMHO, un peu testé, mais la gestion des références est à s’arracher les cheveux (définir le scope des références à la main est très bizarre par exemple).

 Dommage qu’à vouloir faire du ‘safe’ on arrive à quelque chose moins simple à programmer que du Go par exemple, sans être forcément plus fiable (à moins que quelqu’un puisse me contredire, je n’attends que ca).





La gestion des références en Rust n’est pas plus compliquée que la gestion de la mémoire en C++ : ce sont les mêmes questions qui se posent. La différence est qu’avec Rust la question du cycle de vie est explicitée dans le système de types, ce qui est une excellente chose par rapport au C++, notamment pour la libisilité et la maintenabilité.



Maintenant soit tu as besoin d’un langage où la mémoire est gérée manuellement et dans ce cas il te faut C, C++, Rust, Ada ou autre, soit ce n’est pas le cas et ces langages sont complètement inadaptés et il te faut leur préférer un langage avec ramasse-miettes. Ces derniers conviennent à la très grande majorité des besoins mais pas à tous. Notamment lorsque la latence est problématique voire inacceptable et soumise à une exigence de preuves, ou sur les plateformes matérielles rudimentaires ou en mode kernel.



La comparaison avec le Go est dénuée de sens. Peut-être as-tu été intoxiqué par le marketing de Google qui le présentait comme un “langage système”, ce qui a toujours été une absurdité.







kane13 a écrit :



Oh, et Haskell ça poutre. Mais il me faut un langage complémentaire compréhensible par les humains dans mes bagages.





Non, ça ne poutre pas, sauf si tu estimes que les effets secondaires sont un tel problème pour toi qu’il justifie d’ajouter des couches et des couches d’abstraction (complexité accidentelle++++).



En revanche il y a de bonnes idées, comme le fait de laisser le compilo décider de l’ordre d’exécution et que tout soit expression. Mais ne te laisse pas intoxiquer par la propagande Haskell.



Si la question de la complexité t’intéresse, out of the tar pit est l’un des meilleurs papiers jamais écrits dans notre domaine.









brokensoul a écrit :



Langage intéressant IMHO, un peu testé, mais la gestion des références est à s’arracher les cheveux (définir le scope des références à la main est très bizarre par exemple).



C’est en effet bizarre mais c’est ce qui permet d’avoir à la fois la sécurité et des performances de très bas niveau. Il y une phase qui je trouve résume bien le problème de la

gestion mémoire en Rust: “On est obligé d’y réfléchir, mais on n’a pas a

s’en inquiéter”.

 

 Ça permet d’éliminer toute une catégorie d’erreur typiques de la gestion mémoire du C++ ( utilisation après libération, invalidation d’itérateur, data race, …) sans avoir recours a des solutions qui retirent le contrôle précis de ce qui ce passe à bas niveau comme avec Go(garbage collector, …)





brokensoul a écrit :



 Dommage qu’à vouloir faire du ‘safe’ on arrive à quelque chose moins simple à programmer que du Go par exemple, sans être forcément plus fiable (à moins que quelqu’un puisse me contredire, je n’attends que ca).



Le Garbage Collector de Go va en effet apporter la sécurité de l’allocation mémoire au prix du contrôle des performances. Rust est forcément moins simple a programmer que Go, mais le système de contrôle des référence permet quand même d’interdire à la compilation certains type d’erreur comme les data race ou les invalidation d’itérateurs





kane13 a écrit :



  Si quelqu’un a une réponse à ça, je veux bien. J’aimerai me faire la main sur un digne successeur du C, plus moderne, avec des fonctionnalités qu’on est en droit d’attendre : gestion de la mémoire moins abrupte voire directement gérée par le compilateur, simplicité du langage (pas totalement bloated façon C++), gestion clean des dépendances, compilable avec des perfs proches du C (voire 2 ou 3 fois plus lent, c’est pas un problème), qu’il soit stable et pas qui bouge tous les 6 mois…



Go semble plutôt bien répondre a tes attentes, le GC permet d’avoir une mise en place simple sans prise de tête. Et si les performances ne seront pas au niveau d’un vrai langage système, elle restent généralement dans ta marge.



 Rust est sensiblement plus complexe a utiliser, mais répond à tes autres points.

 









pangolin a écrit :



A propos de ces langages modernes “bifaces” (ie. ergonomiques et performants) comme go, rust ou D, qu’en est-il de celui de l’équipe de microsoft qu’on a un temps appelé M# ?

Je trouve peu d’infos récentes à son sujet.

Quelqu’un sait ?





Go n’a d’intérêt que pour des programmes à l’échelle d’un centre de données. Et il a pas mal de problèmes. Et Go ou D (qui n’est pas tout jeune) ne sont pas plus rapides qu’un Java ou C# pré-compilés.



Rust en revanche est un langage système. Il est rapide mais il y a un prix. Il est très supérieur au C/C++ sur ce point mais il n’a pas d’intérêt pour des besoins habituels.



SI tu veux un langage moderne qui conjugue productivité et performances, regarde C# ou Scala. Voire Nim ou Groovy.



Huuu, merci pour ces mises au point, mais ça répond pas à la question =D








pangolin a écrit :



A propos de ces langages modernes “bifaces” (ie. ergonomiques et performants) comme go, rust ou D, qu’en est-il de celui de l’équipe de microsoft qu’on a un temps appelé M# ?



Je trouve peu d'infos récentes à son sujet.      

Quelqu'un sait ?







 Midori était un projet de recherche qui a été abandonné par Microsoft. Un ancien développeur du projet poste régulièrement des billet de blog très intéressant dessus, maintenant que le projet n’est plus.

Visiblement Microsoft a préféré capitaliser sur Windows 10 et continuer a faire évoluer NT en douceur plutôt que de repartir sur un OS potentiellement révolutionnaire mais dont la mise en place aurait été risqué.

 





Meewan a écrit :



La dernière fois que j’avais regardé, rust c’était pas ça niveau stabilité (le langage est jeune et peu mature donc les api évoluent encore). Pour les autres je ne sais pas, mais ça fait un certain temps que go me fait de l’œil.





 Depuis la version 1.0 de Rust, la compatibilité ascendante du langage et de sa bibliothèque standard est garantie (sauf sur les nightly builds).

Après pas mal de fonctionnalités habituelle (nombre aléatoire, date, …) ne sont pas encore dans la bibliothèques standard mais dans des bibliothèques séparée. C’est justement parce d’ils ne veulent pas se presser pour introduire en standard des fonction dont ils ne sont encore totalement sur et qu’il faudrait maintenir en l’état, justement pour ne pas casser la compatibilité.

 



 



Oh ok j’avais loupé ça, merci !


Merci, je viens de parcourir vite-fait le papier, il m’a l’air vraiment intéressant et bien écrit. :)




Rust est un langage développé par Mozilla pour répondre avant tout à ses propres besoins.





 Il n’y a pas d’autres projets majeurs qui l’utilise ? Parce qu’à moins d’aider Mozilla, quelle peut être la motivation à apprendre ce langage, s’il n’est pas adopté ailleurs ?


Tout le monde ne fait pas de la pub sur les langages qu’il utilisent. Si on parle prioritairement de Mozilla, c’est que  se sont eux qui ont initié le projet et restent un contributeur majeur, tout comme on parle naturelement de Google quand on parle de Go et de Oracle quand on parle de Java.



Rust est déjà utilisé en interne par plusieurs sociétés dont DropBox.  Le langage peut potentiellement intéresser tout ceux qui veulent faire de la programmation bas niveau et/ou orienté sécurité.








kane13 a écrit :



 

Si quelqu’un a une réponse à ça, je veux bien. J’aimerai me faire la main sur un digne successeur du C, plus moderne, avec des fonctionnalités qu’on est en droit d’attendre : gestion de la mémoire moins abrupte voire directement gérée par le compilateur, simplicité du langage (pas totalement bloated façon C++), gestion clean des dépendances, compilable avec des perfs proches du C (voire 2 ou 3 fois plus lent, c’est pas un problème), qu’il soit stable et pas qui bouge tous les 6 mois…



Oh, et Haskell ça poutre. Mais il me faut un langage complémentaire compréhensible par les humains dans mes bagages.





Le langage D est pas mal :http://dlang.org/



L’un des dev de MS Midori poste surhttp://joeduffyblog.com/



Il espère toujours que le M# deviennent open source mais c’est vrai que ça ne bouge plus trop de ce côté..



Sinon y a le projet Wavefront qui vise à automatiquement convertir du code C++ existant en code plus safe mais ce n’est que le début du projet..


Pour faire du C# avec des performances similaires au C++, il suffit de compiler le C# en natif, non ?

Ça manque de benchmark récent huit ça :p








sephirostoy a écrit :



Pour faire du C# avec des performances similaires au C++, il suffit de compiler le C# en natif, non ?

Ça manque de benchmark récent huit ça :p



Non, c’est bien plus compliqué que ça. Les VM actuelles compilent d’ailleurs déjà le code en natif à la volé, voire même parfois en AOT.

Le problème c’est que la plupart des langues de haut niveau comme Java, C#, Go ont sacrifié une partie des performances à la facilité d’utilisation. Certains choix de design du langage, comme le GC et de leur bibliothèque standard fait qu’il ne peuvent pas rivaliser avec des langages système dans certains domaines, même s’ils sont compilés.



 Des langages comme le C++ ou le Rust visent par contre a s’approcher autant que possible de l’abstraction sans coût :  les fonctionnalités de haut niveau ne doivent pas rajouter de coût, par rapport à l’équivalent bas niveau.









Baldurien a écrit :



Le langage D est pas mal :http://dlang.org/





En 99 c’était une bonne alternative à Java. De nos jours il n’a pas d’intérêt sauf dans quelques cas marginaux. Autant opter pour C# ou Scala en attendant mieux. D’autant que D a longtemps été délaissé et manque de ressources. Inutile de tenter de ressusciter les pseudo-révolutions avortées des 90’s.







sephirostoy a écrit :



Pour faire du C# avec des performances similaires au C++, il suffit de compiler le C# en natif, non ?





Non, les langages de haut niveau ont des coûts additionnels intrinsèques. La vérification des bornes des tableaux, le ramasse-miettes (ça se discute), les tests de type à l’exécution, l’introspection, les itérateurs virtuels, etc.



En théorie un compilateur poussé pourrait détecter les parties où telle ou telle fonctionnalité ou vérification sont inutiles, et ainsi les omettre. En pratique c’est très difficile et les optimisations compromettent la sécurité et la fiabilité, si bien que de nos jours beaucoup de compilateurs choisissent de rester rudimentaires.



Des avis sur swift ?


C’est un très bon langage. Ses auteurs sont parmi les rares personnes à comprendre la direction dans laquelle les langages de programmation doivent véritablement aller et ils ont fait une synthèse réussie d’horizons très divers (pas de fonctionnalité innovante mais un mélange harmonieux et efficace).



Certains choix sont tout de même regrettables, notamment du fait du passif objective-C : ARC plutôt qu’un vrai GC, accolades, préciosité qui transforme un bête T* en un UnsafeMutablePointer. Parce qu’un vrai programmeur aime les types à rallonge et les accolades.



Cela dit son plus gros point faible c’est qu’en pratique il est exclusif au monde Apple. Dommage, espérons que ça change d’ici quelques années. Mais au moins il fait de la pire plateforme pour développer (Apple) une des meilleures.


Ah c’est sûr que c’est pas des commentaires du même niveau que les news Apple&nbsp;<img data-src=" />



<img data-src=" />

&nbsp;


Il y avait un soucis avec ce langage qui me faisait le rejeter, il me semble que c’était une histoire de licence un peu nulle sur le compilateur je crois, je ne m’en souviens plus. :/








HarmattanBlow a écrit :



La gestion des références en Rust n’est pas plus compliquée que la gestion de la mémoire en C++ : ce sont les mêmes questions qui se posent. La différence est qu’avec Rust la question du cycle de vie est explicitée dans le système de types, ce qui est une excellente chose par rapport au C++, notamment pour la libisilité et la maintenabilité.



Maintenant soit tu as besoin d’un langage où la mémoire est gérée manuellement et dans ce cas il te faut C, C++, Rust, Ada ou autre, soit ce n’est pas le cas et ces langages sont complètement inadaptés et il te faut leur préférer un langage avec ramasse-miettes. Ces derniers conviennent à la très grande majorité des besoins mais pas à tous. Notamment lorsque la latence est problématique voire inacceptable et soumise à une exigence de preuves, ou sur les plateformes matérielles rudimentaires ou en mode kernel.



La comparaison avec le Go est dénuée de sens. Peut-être as-tu été intoxiqué par le marketing de Google qui le présentait comme un “langage système”, ce qui a toujours été une absurdité.





Non, ça ne poutre pas, sauf si tu estimes que les effets secondaires sont un tel problème pour toi qu’il justifie d’ajouter des couches et des couches d’abstraction (complexité accidentelle++++).



En revanche il y a de bonnes idées, comme le fait de laisser le compilo décider de l’ordre d’exécution et que tout soit expression. Mais ne te laisse pas intoxiquer par la propagande Haskell.



Si la question de la complexité t’intéresse, out of the tar pit est l’un des meilleurs papiers jamais écrits dans notre domaine.





Pas besoin de spécifier de temps de vie en c++, c’est plus lisible et plus rapide à programmer, même si ça se fait au prix de la fiabilité. Rust est objectivement plus compliqué de ce point de vue, une simple structure qui stocke des pointeurs est pénible à écrire.

La comparaison avec Go vient de la jeunesse des langages de mon côté, des petits écosystèmes et des usages pas encore bien définis. Je travaille principalement en c++ et python, les deux ont des points forts très clairs, rust n’en est pas là. Les langages n’arrivent pas dans le vide, plein de gens savent faire du python et veulent du plus rapide par exemple, ils vont naturellement considérer java, go, rust ou c++.&nbsp; En quoi est-ce que Rust est vraiment bon, c’est quoi la “killler app ?” Sûr OK, c’est un peu court. Pas vraiment plus concis que c++11, moins naturellement concurrent que Go, c’est une comparaison qui en vaut une autre, utiliser un “language système” est rarement un prérequis.



Je vois que beaucoup de gens comparent Rust et C/C++.



Sauf que comme beaucoup de langages, la philosophie de Rust est de rendre plus facile certaines choses. Cela peut avoir un avantage… mais ce n’est pas la même philosophie.



Quand est ce que les gens comprendront que ce qui fait l’intéret de C/C++, ce n’est pas les aides à la conduite, mais justement la possibilité de s’en passer.








brokensoul a écrit :



Pas besoin de spécifier de temps de vie en c++, c’est plus lisible et plus rapide à programmer, même si ça se fait au prix de la fiabilité. Rust est objectivement plus compliqué de ce point de vue, une simple structure qui stocke des pointeurs est pénible à écrire.

La comparaison avec Go vient de la jeunesse des langages de mon côté, des petits écosystèmes et des usages pas encore bien définis. Je travaille principalement en c++ et python, les deux ont des points forts très clairs, rust n’en est pas là. Les langages n’arrivent pas dans le vide, plein de gens savent faire du python et veulent du plus rapide par exemple, ils vont naturellement considérer java, go, rust ou c++.  En quoi est-ce que Rust est vraiment bon, c’est quoi la “killler app ?” Sûr OK, c’est un peu court. Pas vraiment plus concis que c++11, moins naturellement concurrent que Go, c’est une comparaison qui en vaut une autre, utiliser un “language système” est rarement un prérequis.







Clairement.



Si tu veux mon avis, c’est la mode. Chacun veut sortir son langage.



Mais comme on dit, pendant qu’ils se battront, le vrai roi va continuer de régner.



Parce que c’est pas demain la veille que ceux qui écrivent des systèmes et des gros logiciels vont changer de langage.









brokensoul a écrit :



Pas besoin de spécifier de temps de vie en c++, c’est plus lisible et

plus rapide à programmer, même si ça se fait au prix de la fiabilité.

Rust est objectivement plus compliqué de ce point de vue, une simple

structure qui stocke des pointeurs est pénible à écrire.





&nbsp;Comme je disais plus haut, Rust oblige a réfléchir a ce qu’on fait de la mémoire, mais du coup on a pas plus a s’en inquiéter. Noter les lifetime est il est vrai déroutant au début, mais quand on s’y est fait c’est pas vraiment compliqué. Vu le temps que j’ai passé à débugger des erreurs mémoire louches en C++, je suis convaincu que ça en vaut la peine.

&nbsp;

Un GC apporte une partie de la sécurité de Rust sans avoir a réfléchir à la mémoire, mais on a un runtime qui fait perdre le coté système du langage : le comportement bas niveau est beaucoup moins prédictible, il y a un impact sur les&nbsp; performances et l’intégration avec d’autre langages devient hasardeuse voire impossible.

&nbsp;





brokensoul a écrit :



Je travaille principalement en c++ et python, les deux ont des points forts très clairs, rust n’en est pas là. Les langages n’arrivent pas dans le vide, plein de gens savent faire du python et veulent du plus rapide par exemple, ils vont naturellement considérer java, go, rust ou c++.&nbsp; En quoi est-ce que Rust est vraiment bon, c’est quoi la “killler app ?” Sûr OK, c’est un peu court. Pas vraiment plus concis que c++11, moins naturellement concurrent que Go, c’est une comparaison qui en vaut une autre, utiliser un “language système” est rarement un prérequis.





&nbsp;C’est difficile de demander une killer App à un langage qui n’a pas encore un an d’existence officielle. Ceci dit même s’il est loin d’être fini, Servo est une belle démonstration que l’on peux faire des applications complexes et performantes.

&nbsp;Le gros point fort de Rust, c’est d’être à la fois un langage système et sur. Si tu n’a pas besoin de ça, bien sur que des langage plus simples comme Go seront plus intéressant pour toi. Rust n’a jamais prétendu être le meilleur langage pour tous les cas, loin de là.

&nbsp;





sr17 a écrit :



&nbsp;Je vois que beaucoup de gens comparent Rust et C/C++.





Sauf que comme beaucoup de langages, la philosophie de Rust est de

rendre plus facile certaines choses. Cela peut avoir un avantage… mais

ce n’est pas la même philosophie.





&nbsp;La comparaison avec le C/C++ est sans doute la comparaison la plus pertinente car c’est dans leur domaine que Rust est le plus à sa place.

Rendre plus simple les choses n’est clairement pas la priorité de Rust, même si il essaie bien sur de le faire autant que possible. Globalement il fait passer les performances et la sécurité avant la simplicité.

&nbsp;





sr17 a écrit :



Quand est ce que les gens

comprendront que ce qui fait l’intéret de C/C++, ce n’est pas les aides à

la conduite, mais justement la possibilité de s’en passer.





Le C n’a pas d’aide à la conduite du tout, et celles du C++ sont partielles et pas intégrées directement.

Rust permet lui aussi de se passer des “aides à la conduite” : c’est indispensable si on veut faire de la programmation système. Mais quand on veut s’en passer, il faut le faire explicitement.

&nbsp;





sr17 a écrit :



Si tu veux mon avis, c’est la mode. Chacun veut sortir son langage.



Mais comme on dit, pendant qu’ils se battront, le vrai roi va continuer de régner.



C’est une drôle de vision du concours du plus fort langage de programmation. Un langage n’a pas besoin de régner sur les autres pour avoir un intérêt.



Mozilla a créé Rust non pas pour avoir le plus beau langage de programmation et avoir l’honneur de tuer le C++, mais parce qu’il ne répondait pas a ses besoins en matière de sécurité et de concurrence tout particulièrement.

&nbsp;









zefling a écrit :



En fait, c’est plus compliqué que ça… Il y a déjà des bouts de Servo dans Gecko.





Plutôt des bouts de Rust, pas de Servo il me semble ?





HarmattanBlow a écrit :



Mais au moins il fait de la pire plateforme pour développer (Apple) une des meilleures.





J’aurais plutôt tendance à dire que la pire plateforme pour dév est Windows perso. OS X, bien que totalement fermé, reste un vrai Unix derrière :)



Actuellement il y a dans les Nightly de Firefox un parseur de fichier mp4 en Rust. Il ne fait pas encore partie de Servo vu que Servo ne gère pas encore la vidéo. Mais il semble que les parseurs d’URL et de CSS de Servo sont en cour d’intégration aussi.

C’est certes une quantité de code marginale pour le moment, mais ça prouve que Mozilla a bien l’intension de “Rustifier” Gecko sur la durée.








Uther a écrit :



&nbsp;Comme je disais plus haut, Rust oblige a réfléchir a ce qu’on fait de la mémoire, mais du coup on a pas plus a s’en inquiéter. Noter les lifetime est il est vrai déroutant au début, mais quand on s’y est fait c’est pas vraiment compliqué. Vu le temps que j’ai passé à débugger des erreurs mémoire louches en C++, je suis convaincu que ça en vaut la peine.

&nbsp;

Un GC apporte une partie de la sécurité de Rust sans avoir a réfléchir à la mémoire, mais on a un runtime qui fait perdre le coté système du langage : le comportement bas niveau est beaucoup moins prédictible, il y a un impact sur les&nbsp; performances et l’intégration avec d’autre langages devient hasardeuse voire impossible.

&nbsp;





Hmm ok, il faudra que j’y consacre un peu plus de temps alors. L’argument de sécurité mémoire ne me convient pas complètement, tous les projets récents en C++ passent par des tests en CI et des vérifications par valgrind ou thread/memory sanitizers par exemple, ce qui doit arriver pas très loin de la sécurité de Rust. Je suis un peu pragmatique là dessus, pourquoi pas un peu plus de sécurité inhérente si ça ne devient pas un calvaire à coder, j’avais un peu testé Rust et le côté calvaire l’avait emporté, sans doute à tort. Une bonne IDE de conseillée ?

&nbsp;









kane13 a écrit :



Si quelqu’un a une réponse à ça, je veux bien. J’aimerai me faire la main sur un digne successeur du C, plus moderne, avec des fonctionnalités qu’on est en droit d’attendre : gestion de la mémoire moins abrupte voire directement gérée par le compilateur, simplicité du langage (pas totalement bloated façon C++), gestion clean des dépendances, compilable avec des perfs proches du C (voire 2 ou 3 fois plus lent, c’est pas un problème), qu’il soit stable et pas qui bouge tous les 6 mois…



Oh, et Haskell ça poutre. Mais il me faut un langage complémentaire compréhensible par les humains dans mes bagages.







Java ? <img data-src=" />



@Brokensoul&gt;

&nbsp;La différence a ce niveau c’est que Rust va empêcher la plupart des erreurs en amont à la compilation en te forçant a réfléchir aux problématiques mémoire plutôt que de te laisser faire n’importe quoi et d’essayer de détecter les erreurs a postériori. L’analyse dynamique c’est bien, mais ça n’attrape pas forcément tout.



&nbsp;Après je ne nie pas que c’est parfois lourd de réussir à faire compiler du Rust surtout au début, mais dans la très grosse majorité des cas, je pense que c’est compensé par le temps économisé en débogage.




Au niveau des IDE par contre c'est pas encore ça. Il y a des plugins pour pas mal d'IDE, mais aucun du niveau de ce qui se fait en Java/C++ pour le moment. Ils travaillent a faire un outil qui fournirait aux IDE les infos nécessaires, mais c'est encore en projet      

Le mieux pour le moment semble être IntelliJ Idea avce le plugin, mais







brokensoul a écrit :



Je travaille principalement en c++ et python, les deux ont des points forts très clairs.&nbsp;

&nbsp;



&nbsp;

&nbsp;J’aime beaucoup Cython pour ça. Ça fait faire des bébé à python et C(++). Ce qui n’a pas besoin de performance ou de contrôle de la mémoire est en python, les fonctions qui ont besoins de plus de performance en C avec la syntaxe Cython.









HarmattanBlow a écrit :



C’est un très bon langage. Ses auteurs sont parmi les rares personnes à comprendre la direction dans laquelle les langages de programmation doivent véritablement aller et ils ont fait une synthèse réussie d’horizons très divers (pas de fonctionnalité innovante mais un mélange harmonieux et efficace).





Merci pour ton avis ;-)

Ce n’est pas étonnant vu que sa création a été dirigée par Chris Lattner, le fondateur de LLVM, qui est tout de même bien placé pour avoir cette vision réaliste…



Ça ne répond absolument pas à la question. :-) Et pour info j’en ai déjà bien mangé, donc merci mais non merci.








HarmattanBlow a écrit :



En 99 c’était une bonne alternative à Java. De nos jours il n’a pas d’intérêt sauf dans quelques cas marginaux. Autant opter pour C# ou Scala en attendant mieux. D’autant que D a longtemps été délaissé et manque de ressources. Inutile de tenter de ressusciter les pseudo-révolutions avortées des 90’s.





&nbsp;





kane13 a écrit :



Il

y avait un soucis avec ce langage qui me faisait le rejeter, il me

semble que c’était une histoire de licence un peu nulle sur le

compilateur je crois, je ne m’en souviens plus. :/





J’en ai fait de manière académique pour ma culture - je ne pourrais pas dire pour la licence du compilateur.



Quant à l’intérêt : j’avoue que j’avais vu ça vers 2007 quand je faisais du C++ et du Java. Certains concepts étaient intéressant, notamment le pseudo-objet (ie: si string toString(int), alors 1.toString() &lt;=&gt; toString(1)).





&nbsp;