Journal Ready At Dawn passe à Rust

Posté par . Licence CC by-sa.
31
26
juil.
2018

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 (page perso) . Évalué à 4. Dernière modification le 26/07/18 à 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 . Évalué à 5. Dernière modification le 26/07/18 à 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 (page perso) . É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 . Évalué à 1.

          Pourquoi on n'a pas le droit de faire certaines choses (comme […] faire un cycle de références)

          Si j'ai bien compris, une liste circulaire est interdite en Rust ?

          • [^] # Re: All hail to Rust

            Posté par (page perso) . Évalué à 3. Dernière modification le 28/07/18 à 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 de unsafe nécessaires pour avoir de bonnes performances) et du code classique sera bien souvent avec 0 bloc unsafe.

    • [^] # Re: All hail to Rust

      Posté par . É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 (page perso) . É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 (page perso) . É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 . É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 (page perso) . É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 NullPointerException ou 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 (page perso) . Évalué à 7.

          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.

          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 . Évalué à 1.

            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é.

            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 (page perso) . Évalué à 3.

              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.

              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 (page perso) . É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 (page perso) . Évalué à 7. Dernière modification le 27/07/18 à 14:23.

              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.).

              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 :

              • Une base de code existante énorme, qu'il faut maintenir et faire évoluer (la réécriture ça demande du temps) ;
              • C++ a beaucoup d'ingénieurs formés pour en écrire et en lire, Rust beaucoup moins (je ne me vois pas imposer en entreprise un langage qui n'est connu que de moi) ;
              • C++ a beaucoup de bibliothèques, que ce soit des trucs maisons ou de l'extérieur comme Qt ou Boost ;
              • C++ de par son âge a un écosystème d'outils pour le manipuler qui est assez large et ancien. Coder en C++ depuis CentOS 6 ne devrait pas être simple…
              • Le C++ est de mémoire disponible sur plus d'architectures matérielles (pour l'embarqué donc).

              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 (page perso) . Évalué à 3.

                C++ de par son âge a un écosystème d'outils pour le manipuler qui est assez large et ancien. Coder en C++ depuis CentOS 6 ne devrait pas être simple…

                Je voulais dire coder en Rust depuis CentOS 6.

                • [^] # Re: All hail to Rust

                  Posté par . Évalué à 1.

                  Alors qu'en C++17 c'est facile ?

                  • [^] # Re: All hail to Rust

                    Posté par (page perso) . É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 . É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 . É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.

                        # Installer la toolchain nightly
                        rustup install nightly
                        # Aller dans le répertoire du projet
                        cd mon_super_projet
                        # Le projet utilise maintenant Rust nightly
                        rust override set nightly

                        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 . É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 (page perso) . Évalué à 10. Dernière modification le 28/07/18 à 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 . Évalué à 5.

          Pourquoi le Rust plutôt que le D ? Le Rust est plus bas niveau et ne nécessite pas de ramasse-miettes

          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.

          il a un système d'abstraction beaucoup plus riche, avec des "sum types", […] avec des abstractions plus agréables à utiliser.

          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 (page perso) . É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.

            Hum, quelle est la différence entre un "sum type" et un "Variant record" en Ada?

            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.

            quand je regarde un programme Rust ça fait "soupe de caractères"

            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 . Évalué à 3.

              L'aspect innovant de ce point n'est pas remis en cause, je pense.

              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 (page perso) . É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 (page perso) . É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 (page perso) . Évalué à 2.

                  J'aimerai aussi voir un ToolKit de GUI native écrit en Rust

                  Ça existe, ça s’appelle Orbital. Voir ici : https://www.redox-os.org

                  • [^] # Re: All hail to Rust

                    Posté par (page perso) . É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 . Évalué à 2.

                  J'aimerai aussi voir un ToolKit de GUI native écrit en Rust

                  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 (page perso) . É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 (page perso) . Évalué à 2. Dernière modification le 27/07/18 à 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.

        vanilla, ma distribution radicalement différente : http://projects.malikania.fr/vanilla

        • [^] # Re: All hail to Rust

          Posté par . Évalué à 3.

          Tu retardes l'affaire des bibliothèque standard est morte depuis longtemps.

    • [^] # Re: All hail to Rust

      Posté par . É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 (page perso) . É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 . É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.

          Sinon, que veut dire le modèle mémoire va venir se mettre en travers des développeurs ?

          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 (page perso) . É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 . É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 (page perso) . Évalué à 8.

            Qu'on ne peut pas faire de trucs «sales» en Rust.

            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 utiliser unsafe.

            il ne peut plus vérifier et on perd l'intérêt du langage

            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 . É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 . Évalué à 2. Dernière modification le 26/07/18 à 17:36.

      Je n'ai même plus envie d'écrire une seule ligne en Go tellement je le trouve ennuyeux.

      Que veux-tu dire ?

      • [^] # Re: C++ -> Python -> Go -> Rust

        Posté par . Évalué à 8. Dernière modification le 26/07/18 à 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 (page perso) . É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 . É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 . Évalué à 7. Dernière modification le 26/07/18 à 23:34.

        Je n'ai même plus envie d'écrire une seule ligne en Go tellement je le trouve ennuyeux.

        Que veux-tu dire ?

        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 (page perso) . Évalué à 3. Dernière modification le 28/07/18 à 14:24.

      Je n'ai même plus envie d'écrire une seule ligne en Go tellement je le trouve ennuyeux.

      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.

      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.

      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 (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . Évalué à 3. Dernière modification le 27/07/18 à 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 (page perso) . Évalué à 6. Dernière modification le 28/07/18 à 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 cargo et crates.io.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.