La société de développement Ready At Dawn éditrice des jeux Daxter, God of War ou encore Ōkami, a décidé de passer tout ses futures projets au langage Rust parce que C/C++ <3 Rust.
It's finally happening - after >30 years of pro use, 20 of which quite reluctantly, I am officially DONE with C/C++. Only maintenance from now on, everything new will be in @rustlang. THANKS Rust team for refining modern concepts into such a practical, elegant system. I love it.
Cela arrive enfin - après plus de 30 ans d'usage professionnel, dont 20 clairement de façon réticente, j'en ai FINI avec C/C++. Seule la maintenance sera assurée à partir de maintenant, tout ce qui est nouveau sera en Rust. MERCI à l'équipe Rust d'avoir affiné des concepts modernes dans un système si pratique et élégant. Je l'adore.
L'annonce suscite en tout cas de l’intérêt. Affaire à suivre.
# All hail to Rust
Posté par Boiethios (site web personnel) . Évalué à 4. Dernière modification le 26 juillet 2018 à 14:46.
J'avais déjà vu cette info, et en tant que fan de Rust, j'en suis ravi. J'espère que ce genre d'annonces va se multiplier dans les années qui suivent.
Et aussi, en tant qu'ancien fan de C++, le seul conseil que je peux donner à ceux qui aiment le C++ : testez le Rust avec honnêteté, et vous ne serez pas déçus ! Ce langage est ce que le C++ aurait dû être mais n'a pas pu être, faute de recul et à cause du manque de certaines idées techniques à l'époque.
[^] # Re: All hail to Rust
Posté par gUI (Mastodon) . Évalué à 5. Dernière modification le 26 juillet 2018 à 14:49.
Tu veux dire que moi qui suit resté au C tout court, me mettre au Rust est une bonne idée ?
En tous cas ça peut me faire un petit projet pour cet été.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: All hail to Rust
Posté par Boiethios (site web personnel) . Évalué à 6.
Très honnêtement, passer du C au Rust est (relativemen) facile. On peut traduire du C en Rust (hors constructions "unsafe") facilement.
Après, je ne veux pas cacher que le Rust est un langage assez compliqué à maîtriser. Le côté "memory safety" est garanti à la compilation, mais du coup ça nécessite d'avoir une idée assez précise de ce qu'est une pile, et pourquoi on n'a pas le droit de faire certaines choses (comme retourner une référence sur une variable locale ou faire un cycle de références). Mais c'est un langage qui ne permet pas de se tirer une balle dans le pied aussi facilement qu'en C++, et je pense qu'il est plus proche du C sur ce point : pas de mauvaises surprises.
[^] # Re: All hail to Rust
Posté par HL . Évalué à 1.
Si j'ai bien compris, une liste circulaire est interdite en Rust ?
[^] # Re: All hail to Rust
Posté par GuieA_7 (site web personnel) . Évalué à 3. Dernière modification le 28 juillet 2018 à 18:43.
Oui, c'est interdit de base, mais c'est faisable avec un peu de
unsafe. En pratique c'est fait par la bibliothèque standard qui fournit moult collections/algorithmes (là où par exemple celle de Go va plutôt fournir des outils haut niveau pour web, mail etc…) qui vont se charger de ça (à savoir faire le très peu deunsafenécessaires pour avoir de bonnes performances) et du code classique sera bien souvent avec 0 blocunsafe.[^] # Re: All hail to Rust
Posté par reno . Évalué à 10.
Mouai, c'est un peu court pourquoi Rust plutôt qu'Ada ou D?
Franchement la maturité d'Ada par rapport à celle de Rust..
Et D est probablement beaucoup + facile comme transition depuis le C++ que Rust, il y a même un mode DasBetterC qui évite d'utiliser le GC (mais qui diminue la sécurité comme le C++ et empèche l'utilisation de certaines librairies).
[^] # Re: All hail to Rust
Posté par Jean Gabes (site web personnel) . Évalué à 7.
Je voterai sur la taille de la communauté et crédibilité du sponsor de Rust? C'est largement supérieur en matière de poids de décision que quelques intérêts techniques entre des langages qui sont chacun déjà de grosses avancées par rapport à ce qu'on utilise en terme de ROI sur le temps de dev (et surtout de debug je crois ).
Après Ada est vieux et utilisé dans l'industrie non? Donc côté crédibilité ça doit tenir la route. Faudrait poser la question directement je pense.
[^] # Re: All hail to Rust
Posté par Boiethios (site web personnel) . Évalué à 4.
De plus, je tiens à ajouter que le Rust est utilisé par un certain nombre de grosses boites, dont Samsung, Microsoft, OVH, NPM, Dropbox, etc. C'est une grosse victoire pour un langage dont la version 1 est sortie il y a 3 ans.
[^] # Re: All hail to Rust
Posté par Maclag . Évalué à 9.
Je ne sais pas si de telles grosses boites sont une bonne référence sauf si elles mettent l'outil en avant dans un gros projet avec de la visibilité:
A partir d'une certaine taille critique, tu peux supposer que quel que soit le langage auquel tu penses, quelqu'un quelque part fait quelque chose avec et du coup "XXX utilise ce langage!".
[^] # Re: All hail to Rust
Posté par Boiethios (site web personnel) . Évalué à 5.
Honnêtement, j'ai plus tendance à taper sur le C++ qui est devenu une énorme usine à gaz sans cohérence ; mais je respecte tout à fait le D et l'Ada.
Pourquoi le Rust plutôt que le D ? Le Rust est plus bas niveau et ne nécessite pas de ramasse-miettes pour sa bibliothèque standard, donc dans certains cas (comme l'embarqué ou le code haute performance), il peut être plus efficace. De plus, contrairement au D, il ne peut pas avoir de
NullPointerExceptionou d'autres problèmes du même genre : il est safe par design, y compris pour le code multi-threadé.Pourquoi plutôt que l'Ada ? Ces arguments s'appliquent aussi au D : il a un système d'abstraction beaucoup plus riche, avec des "sum types", un système de traits, tout est expression, etc. En gros, il reprend beaucoup de concepts des langages fonctionnels. Le ressenti général est un langage plus élégant et avec des abstractions plus agréables à utiliser.
[^] # Re: All hail to Rust
Posté par Renault (site web personnel) . Évalué à 7.
Je ne suis pas un amoureux du C++, je suis plutôt un puriste du C. Mais je pense que le C++ va malgré tout dans la bonne voie, C++11 et C++14 ont apporté pas mal de choses pour corriger les erreurs de jeunesses.
Le C++ est en effet un langage très gros et incohérent avec le temps, tu as pas mal de paradigmes qui se baladent, des héritages parfois malvenus du C et de son histoire, etc.
Mais je pense qu'en fait il ne faudrait plus jamais évaluer le C++ dans son ensemble qui pour des raisons de compatibilités est en vrai une chose infâme. Si tu utilises le C++11 / C++14 en évitant les vieilleries (ce qui est largement possible, si tu n'utilises pas Qt du moins) tu gagnes largement en cohérence et en puissance. Si un projet mélange les vieilles structures avec les nouvelles, c'est en effet hideux, mais c'est à éviter en réalité.
[^] # Re: All hail to Rust
Posté par barmic . Évalué à 1.
Il existe _une manière de s'en assurer ? Parce que tant que l'on ne peux pas garantir qu'une base de code ne le fais pas il faudra pour moi évaluer le langage dans son ensemble.
Tous les langages ont des fonctionnalités bizarre et tu peux trouver un sous ensemble à tous les langages qui est propre, mais pour que ça ai du sens il faut pouvoir l'évaluer. De la même manière que ce demander si on peut en rust s'interdire tout unsafe.
[^] # Re: All hail to Rust
Posté par Firwen (site web personnel) . Évalué à 3.
Avec de bonnes guidelines et des code review… sans problèmes oui…
Le coté pragmatic de C++ est autant une force qu'une faiblesse. C'est un language qui a survécu à toutes les "fashion d'un temps" de ses 20 dernières années.
[^] # Re: All hail to Rust
Posté par Boiethios (site web personnel) . Évalué à 1.
Oui, je suis tout à fait d'accord. Comme dirait l'autre, il n'y a pas un mais des C++ ; et le C++11/14 est un bien meilleur langage que le 98.
Mais bon, toutes les dernières bonnes innovations qui arrivent sur le C++ (sémantique move, concepts, modules, etc.) sont "obligatoires" en Rust (je veux dire qu'il n'y a rien d'autre). Tant qu'à faire, autant utiliser le Rust, surtout que son côté fonctionnel (entre autres) rend les choses encore plus agréables (sum types, orienté expression, etc.).
[^] # Re: All hail to Rust
Posté par Renault (site web personnel) . Évalué à 7. Dernière modification le 27 juillet 2018 à 14:23.
On peut construire un type SUM en C++ assez facilement, ce n'est absolument pas un soucis, les "Variant" existent un peu partout.
Mais outre cela, il faut je pense arrêter de considérer le choix d'un langage uniquement sur ses qualités techniques. Car bon le C++ c'est aussi :
C'est ainsi pour tout langage, même le C a aussi son intérêt. Tout comme Python ou Ocaml. Aucun langage n'est parfait, même si certains sont d'un point de vue strictement technique meilleur, le reste compte aussi pour faire un choix.
Le culte du compromis en somme.
[^] # Re: All hail to Rust
Posté par Renault (site web personnel) . Évalué à 3.
Je voulais dire coder en Rust depuis CentOS 6.
[^] # Re: All hail to Rust
Posté par barmic . Évalué à 1.
Alors qu'en C++17 c'est facile ?
[^] # Re: All hail to Rust
Posté par Renault (site web personnel) . Évalué à 5.
C++17 n'est pas très répandu encore, et alors ?
C++11 et C++14 sont disponibles maintenant presque partout, les compilateurs concernés sont suffisamment à jour. Car sinon on peut aussi parler de la vitesse d'évolution de Rust que tout le monde ne parvient pas à suivre.
[^] # Re: All hail to Rust
Posté par barmic . Évalué à 0.
Rust comme C ou C++ ont une grande intrication avec le système. C'est un enfer dès que tu sors des chantiers défini par ta distribution. Avoir plusieurs versions utilisables du compilateur et/ou plusieurs versions de bibliothèques n'est pas quelque chose de simple et AMHA la meilleure solution reste d'utiliser un container docker qui va avoir ton outillage.
[^] # Re: All hail to Rust
Posté par Letho . Évalué à 7.
Ben justement… Non ;)
Je ne sais pas pour C ou C++, mais c'est au contraire très facile d'avoir plusieurs versions de Rust. Il est officiellement recommandé d'installer Rust via RustUp qui te permet justement de gérer tes toolchains. Tu détermine ensuite par projet celle que tu souhaites utiliser.
https://www.rust-lang.org/fr-FR/install.html
https://rustup.rs/
Idem pour les bibliothèques, tout est géré au niveau du projet, via le fichier Cargo.toml.
Je ne sais pas si c'est la question que tu posais, mais il n'y a aucun souci à avoir deux projets différents qui utilisent deux versions distinctes d'une même bibliothèque.
[^] # Re: All hail to Rust
Posté par barmic . Évalué à -5.
Et malgré ça personne n'a trouvé le moyen de builder un Firefox pour la précédente version de Debian à cause de rust. Tri-vial
[^] # Re: All hail to Rust
Posté par claudex . Évalué à 10. Dernière modification le 28 juillet 2018 à 08:29.
Il ne faudrait pas confondre non plus. Debian veut utiliser la version de rust qui est dans ses paquets (ce qu je comprends) pour builder Firefox et c'est ça le problème. Parce que je n'ai aucun problème à utiliser un rust récent ou un firefox récent sur Debian.
« 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
[^] # Re: All hail to Rust
Posté par reno . Évalué à 5.
Toi tu as lu, mon message un peu vite: fait une recherche sur DasBetterC, mais bien sûr si tu utilise D sans le ramasse miette tu as les mêmes problèmes que le C/C++ au niveau gestion mémoire.
Hum, quelle est la différence entre un "sum type" et un "Variant record" en Ada?
Pour les abstractions plus agréable a utiliser, je n'en suis pas si sûr: visiblement faire un GUI en Rust ça a l'air bien pénible.
Et je pense quand même que Rust a un ramp-up important: quand je regarde un programme Ada j'ai l'impression de comprendre tout, quand je regarde un programme Rust ça fait "soupe de caractères" bon pas autant que le Perl mais pas loin..
[^] # Re: All hail to Rust
Posté par Boiethios (site web personnel) . Évalué à 2.
Oui, donc pour le D c'est soit l'un soit l'autre. Seul le Rust permet la sécurité de la mémoire sans GC, et c'est grâce à une quantité de recherches phénoménale fournie par l'équipe qui le développe. L'aspect innovant de ce point n'est pas remis en cause, je pense.
Effectivement, je me suis trompé sur ce point… Mais de façon générale, l'Ada n'a pas tout ce qui rend le code concis et agréable à lire dans les langages fonctionnels. Il lui manque aussi le côté moderne du Rust avec le gestionnaire de paquet, de build, de tests intégré, etc.
C'est une question d'habitude, mais le reproche est injuste je trouve. Ose me dire que ce code, par exemple, fait soupe de caractères : https://gitlab.com/Boiethios/tempotap/blob/master/src/main.rs
Bon ok, je dois reconnaître que certains codes génériques peuvent être ardus (un peu comme les templates en C++) surtout si les types lifetime s'y mettent. Mais tous les codes ne sont pas comme ça, loin s'en faut, et c'est comme tout, avec un peu d'habitude on rentre facilement dedans.
[^] # Re: All hail to Rust
Posté par reno . Évalué à 3.
Non, mais l'utilisabilité de la chose est par contre encore en question, j'attends de voir une API de GUI en Rust..
[^] # Re: All hail to Rust
Posté par Boiethios (site web personnel) . Évalué à 2.
Gtk-rs. Bon, ok, ce n'est pas écrit en Rust, mais c'est parfaitement utilisable en Rust.
Mais sinon, la tendance n'est pas trop aux applications de bureau. En général, pour celles-ci, les gens codent en JS avec des frameworks genre electron.
[^] # Re: All hail to Rust
Posté par GuieA_7 (site web personnel) . Évalué à 5.
J'aimerai aussi voir un ToolKit de GUI native écrit en Rust ; peut-être pourrait-il utiliser une approche différente de ce qu'on trouve en Qt/GTK. Non pas parce que ce sont de mauvais projets, mais parce que si c'est pour avoir la même approche, autant juste avoir des bindings.
Je ne sais pas quel est l'état du binding GTK pour Rust, mais en l'occurrence quand je m'y intéressais au final pour une GUI en Ada, le mieux était aussi son binding GTK ; ce qui ne remet pas en cause l'utilisabilité de Ada pour autant.
En revanche depuis le temps, mis à part l'IDE libre pour Ada (Gnat), je n'ai jamais croisé de programme de bureau en Ada ; là encore ça ne remet pas en cause les grandes qualités du langage. Mais vu son âge, il y a peu de chance que cela change ; parce qu'il a largement eu le temps de devenir populaire, et que ça n'est pas arrivé (que ce soit pour de bonnes ou de mauvaises raisons).
[^] # Re: All hail to Rust
Posté par Guillawme (site web personnel, Mastodon) . Évalué à 2.
Ça existe, ça s’appelle Orbital. Voir ici : https://www.redox-os.org
[^] # Re: All hail to Rust
Posté par GuieA_7 (site web personnel) . Évalué à 3.
J'ai hésité à en parler car c'est, il me semble, pour le moment uniquement pour Redox, donc très confidentiel, et donc difficile d'avoir des retours sur sa qualité.
Mais au final c'est bien que tu l'aies cité.
[^] # Re: All hail to Rust
Posté par Gabbro . Évalué à 2.
Je suis tombé sur Conrod qui semble être une gui en Rust. C'est pas forcément joli, je ne sais pas ce qui ça donne d'un point de vue utilisabilité, mais ça semble exister.
[^] # Re: All hail to Rust
Posté par GuieA_7 (site web personnel) . Évalué à 4.
Il me semble que c'est plutôt pour faire des interfaces de jeux vidéos (donc plutôt à l'intérieur d'un contexte OpenGL par exemple) plutôt que des interfaces classiques de bureau.
Ceci dit les TK classiques (Qt/GTK/…), le Web (où l'IHM est un document qu'on va manipuler par JS) et les jeux vidéos se sont beaucoup inspirés les uns des autres. Par exemple, dans les TK on a vu apparaître des scene graphes inspirés directement du jeu vidéo.
Du coup, on peut imaginer un TK qui permette à la fois de faire des applications classiques de bureau et faire son rendu dans un contexte 3D (en fait ça c'est déjà possible), et qui soit suffisamment puissant pour faire des applications de bureau complexes (ex: LibreOffice) tout en permettant de faire des Widgets avec des rendus très fantaisistes et des animations poussées. Et là pour le coup ça n'existe pas à ma connaissance, et ce n'est peut-être pas possible de faire un tel grand écart de manière satisfaisante. L'avenir nous le dira peut-être.
[^] # Re: All hail to Rust
Posté par David Demelier (site web personnel) . Évalué à 2. Dernière modification le 27 juillet 2018 à 09:02.
Sauf que D est mort né et il sert à rien. Il n'offre rien de nouveau (pattern matching de Rust <3). En plus il a un GC et plusieurs bibliothèques standard car les développeurs ne se sont pas mis d'accord.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: All hail to Rust
Posté par reno . Évalué à 3.
Tu retardes l'affaire des bibliothèque standard est morte depuis longtemps.
[^] # Re: All hail to Rust
Posté par rewind (Mastodon) . Évalué à 2.
Dire qu'on va faire qqch et dire qu'on l'a déjà fait, ce n'est pas pareil. J'attends de voir un jeu complet et fini avec Rust et avoir le retour d'expérience.
Dans beaucoup de jeu, la gestion de la mémoire est un composant critique qui est optimisé pour différents usages. Avec Rust, je pense qu'on n'a pas le choix, le modèle mémoire va venir se mettre en travers des développeurs à un moment donné et là, il n'y aura aucune solution.
[^] # Re: All hail to Rust
Posté par Boiethios (site web personnel) . Évalué à 3.
Il y a http://sharonos.com/ par exemple. Je ne sais pas s'il est fini, mais il est déjà jouable. Chucklefish développe ses jeux en Rust aussi. Sinon, pour Ready at Dawn, ils travaillent avec Rust depuis un certain temps déjà : ils n'ont pas fait ce choix à l'aveuglette, sans avoir des preuves solides que ça leur convient.
Sinon, que veut dire le modèle mémoire va venir se mettre en travers des développeurs ? C'est le même qu'en C++ : heap/stack. Ce n'est pas très original de ce point de vue :P
[^] # Re: All hail to Rust
Posté par rewind (Mastodon) . Évalué à 5.
Qu'il y ait des petits studios qui utilisent Rust, oui, pourquoi pas. On peut aussi en trouver qui le font en D, en Go, ou en Pascal je suis sûr. Ça n'est pas vraiment un indicateur. Tous les gros studios restent encore en C++, ça c'est un indicateur.
Qu'on ne peut pas faire de trucs «sales» en Rust. Je mets «sale» entre guillemet parce que ce n'est pas vraiment le bon terme. Je dirais plutôt qu'en dehors de ce qui est prévu par le langage (avec toutes les vérifications), on ne peut rien faire (sinon il ne peut plus vérifier et on perd l'intérêt du langage). Par exemple, dans certains jeux, il existe des allocateurs qui permettent d'allouer de la mémoire qui sera utilisée uniquement dans la construction de la frame courante, donc on peut désallouer tout d'un seul coup à la fin de la construction (voir ici pour les explications). L'avantage, c'est que l'allocation et surtout la désallocation sont très rapides. Faire ça en Rust, je demande à voir.
[^] # Re: All hail to Rust
Posté par Boiethios (site web personnel) . Évalué à 5.
Le premier jeu dont j'ai envoyé le lien (SHAR) est un fps en 3D dans un monde destructible avec une physique réaliste. Je suppose que si on peut faire ça, rien n'empêche de faire autre chose. Le fait que les studios utilisent le C++ est un indicateur que le langage est plus mature et qu'il a un outillage plus conséquent, pas que le Rust n'est pas adapté pour le développement de jeu.
Tout ce qui peut se faire au niveau de la mémoire en C ou C++ peut se faire en Rust, au besoin avec des blocs
unsafe. Dans ton exemple, je suppose que tu faisais allusion au pattern arena qui existe en Rust : https://crates.io/search?q=arena Sinon, le fait d'utiliser un allocateur personnalisé est une fonctionnalité présente dans les versions "nightly", mais ce sera stabilisé un jour ou l'autre (ils préfèrent travailler lentement mais ne pas faire d'erreur dans l'API de la bibliothèque standard).[^] # Re: All hail to Rust
Posté par lockidor . Évalué à 1.
Je ne m'y connais pas assez en allocateurs custom pour juger de la pertinence à ta question, mais il y a ce chapitre dans la doc officielle.
[^] # Re: All hail to Rust
Posté par Gof (site web personnel) . Évalué à 8.
Bien sûr que si, on peut. Il suffit d'écrire
unsafe { ... }, et tu peux faire tout les truc « sales » que tu veux. C'est bien ça la force de rust: par défaut le compilateur vérifie, mais quand tu es sur de ce que tu fait, tu peux utiliserunsafe.On ne perd pas l'intérêt du langage car on peut limiter les zones unsafe à quelques primitives de base (par exemple
CurrentFrameAllocator,CurrentFrameBox<T>) qui est reviewé avec plus d'attention, alors que la plupart du code reste en safe.# C++ -> Python -> Go -> Rust
Posté par Ririsoft . Évalué à 6.
J'ai commencé à coder en C++ il y a 18 ans, puis j'ai basculé en Python pendant de longues années chaque fois que je pouvais me passer du C++, puis Go a remplacé Python pour tous mes projets (backend, web, ligne de commande …).
Depuis quelques mois je me suis mis au Rust. Plus le temps passe plus je m'approche de la productivité que j'avais en Go. Je n'ai même plus envie d'écrire une seule ligne en Go tellement je le trouve ennuyeux.
La safety de Rust sans garbage collector est génial bien que difficile à maitriser au début. Les macros sont au top. Le "trait system" est brillant: j'en avais déjà terminé avec la programmation objet de papa (héritage notamment) avec le Go, mais Rust apporte de la généricité en plus.
Pour ce qui est de l'écosystème de Rust (librairies standards, outils de développement), je trouve que ce n'est pas encore tout à fait mature, un cran en dessous de ce que j'avais en Go, bien qu'il y ait des projets vraiment brillant comme Serde, Diesel et Actix. Mais les choses bougent vite, je sens un vrai intérêt pour Rust de la part des développeurs (c'est ma perception, je peux me tromper).
Enfin Rust n'est pas au niveau de Go pour ce qui est des "green threads" (Goroutines), mais c'est entrain d'être comblé avec l'arrivée prochaine de async/await.
Un dernier mot : Le support natif du Web Assembly. Je me prend à rêver que je vais pouvoir tout coder du backend au frontend, en passant par mes petits outils en ligne de commande, en Rust, sans une seule ligne de Javascript.
Bref, Rust c'est à essayer si vous ne l'avez pas déjà fait.
[^] # Re: C++ -> Python -> Go -> Rust
Posté par ff9097 . Évalué à 2. Dernière modification le 26 juillet 2018 à 17:36.
Que veux-tu dire ?
[^] # Re: C++ -> Python -> Go -> Rust
Posté par Nicolas Boulay (site web personnel) . Évalué à 8. Dernière modification le 26 juillet 2018 à 17:48.
Que go est simple et donc peut devenir très verbeux, que si on a les type sum et la généricité sous la main, je comprends que l'on a pas envie de revenir à Golang.
"La première sécurité est la liberté"
[^] # Re: C++ -> Python -> Go -> Rust
Posté par Boiethios (site web personnel) . Évalué à 4.
C'est exactement ce que j'ai ressenti avec Go. Je le trouvais trop limité, trop verbeux. Néanmoins, j'aime l'utiliser pour ses goroutines, notamment quand on utilise les websockets. Je trouve que les 2 se marient particulièrement bien.
[^] # Re: C++ -> Python -> Go -> Rust
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
J'ai adoré le coté, "je fais un serveur web applicatif en 10 lignes, qui tient la charge". Mais bon, j'ai ensuite vu tout ce qu'il fallait écrire pour utiliser un truc comme go-kit. C'est tellement verbeux, que certains ont essayé d'écrire des générateurs de code. Mais aucun n'est vraiment finalisé.
"La première sécurité est la liberté"
[^] # Re: C++ -> Python -> Go -> Rust
Posté par Ririsoft . Évalué à 7. Dernière modification le 26 juillet 2018 à 23:34.
Go est ennuyeux et c'est totalement assumé par Google: un langage simple, facile à prendre en main, avec juste l'essentiel. On pourrait dire KISS. C'est un gros point fort. Mais le manque de générique et de macro pèse un peu à la longue, même si go generate existe. On passe beaucoup de temps à convertir des slices d'un type à un autre, par exemple, ou a copier du code.
A la longue je trouvais que mon code était plat, sans saveur. Je n'avais aucun plaisir à le lire, comme on peut avoir du plaisir à lire un très beau code C++. J'ai retrouvé ce plaisir avec Rust.
[^] # Re: C++ -> Python -> Go -> Rust
Posté par anaseto (site web personnel) . Évalué à 3. Dernière modification le 28 juillet 2018 à 14:24.
Je suppose que c'est un point de vue courant. Je comprends que ça puisse ne pas être super excitant lorsque ce qui nous intéresse, c'est le code en soi et qu'on a envie de s'émerveiller sur la façon avec laquelle on a résolu un problème. Ceci dit, lorsque c'est le résultat et non le comment qui m'importe vraiment, je trouve Go très agréable et sans prises de tête.
Pour le coup, la version 1.11 de Go aura ça, j'ai testé et c'est vraiment pratique :
GOOS=js GOARCH=wasm go ...le reste comme d'habitude...et hop, le tour est joué :)[^] # Re: C++ -> Python -> Go -> Rust
Posté par Bruno Michel (site web personnel) . Évalué à 4.
Pour wasm, il me semblait avoir lu que les fichiers Go compilés vers wasm étaient très gros (plus de 1 Mo pour un hello world) à cause de la nécessité d'inclure un gros runtime (notamment le garbage collector), alors que Rust a un runtime beaucoup plus petit et génère des fichiers wasm beaucoup plus petits (quelques dizaines de ko pour un hello world).
[^] # Re: C++ -> Python -> Go -> Rust
Posté par anaseto (site web personnel) . Évalué à 4.
Oui, sur ce point ça laisse à désirer pour les petits programmes. Encore que dans les serveurs qui font un gzip du fichier wasm (sans doute pas la plupart encore), c'est beaucoup plus raisonnable (le wasm se compresse très bien).
[^] # Re: C++ -> Python -> Go -> Rust
Posté par anaseto (site web personnel) . Évalué à 7.
Je viens de faire le test : un hello world sans compression me donne 1.3M et, avec compression, ça me donne 290K, donc un peu mieux que quatre fois moins.
# Orienté objet vs fonctionnel ?
Posté par nokomprendo (site web personnel) . Évalué à 3. Dernière modification le 27 juillet 2018 à 18:50.
Quand on connait un peu des langages comme OCaml/Haskell et qu'on découvre Rust, leur influence saute aux yeux : types algébriques, traits, inférence, pattern matching… (https://doc.rust-lang.org/reference/influences.html).
Donc à mon avis, ce n'est pas tant un changement de langage mais plutôt de paradigme : de l'orienté objet au fonctionnel.
[^] # Re: Orienté objet vs fonctionnel ?
Posté par GuieA_7 (site web personnel) . Évalué à 6. Dernière modification le 28 juillet 2018 à 12:33.
C'est la force de Rust d'avoir réussi à faire collaborer l'approche fonctionnelle de OCaml/Haskell (pour le typage entre autres) avec une gestion fine des ressources (potentiellement bas niveau). Cette dernière va venir d'autre langage comme Cyclone (l'emprunt de référence notamment) ou C++ (les réflexions sur les closures dans les dernières versions ont été suivies de près par la communauté Rust ; principalement sur la politique de capture de l'environnement—copie contre référence). On trouve d'autres inspirations, et c'est une bonne chose que d'être aller chercher les qualités un peu partout ; par exemple python a inspiré certain élément de syntaxe. Donc le changement de paradigme n'est pas la seule chose importante ; sinon Ocaml avait déjà réussi à unifier impératif et fonctionnel.
À noter que l'inspiration va dans les 2 sens ; par exemple ce papier sur une possible gestion des ressources dans les langages fonctionnels (ici testée dans Ocaml) :
http://lambda-the-ultimate.org/node/5511
j'ajouterai que pour certains Rustafariens, la principale intérêt de faire du Rust ne vient même pas du langage lui-même mais de son environnement, avec
cargoetcrates.io.Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.