• # re: Rust versus Go : round 1, fight !

    Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†8.

    Les langages de programmation, c'est pas Booba et Kaaris hein. On a C et C++ depuis des décennies. Autant, l'article (déjà vu sur jdh) est une comparatif très pertinent. Autant le titre putaclic me lasse.

    Merci pour le partage :-)

  • # Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.

    Post√©¬†par¬† . √Čvalu√©¬†√†¬†6.

    Les deux sont des véhicules mais pas conçus pour les mêmes objectifs, et ne sont pas interchangeables. Du coup ça ne sert à rien de les comparer.

    De mon avis une comparaison Go/Ada, comme celle qui est plus ou moins passée sur Lnuxfr ces derniers temps a déjà plus de sens, car les deux langages ont des approches parfois différentes pour répondre aux mêmes objectifs, mais ne pas oublier que même dans ce cas, la comparaison n'est pas non plus toujours pertinente, car les deux langages n'ont pas non plus les mêmes raisons d'etre.

    Cela dit … j'aimerais bien que certains concepts Ada soient repris dans Rust. Ce que je trouve intéressant dans Ada par exemple, c'est que chaque type doit être redéfini et dérivé des types de bases avec contraintes (ça fait un bail que j'ai plus fait d'Ada donc je ne me rappelle plus des termes exacts, n'hésitez pas à corriger ou préciser).

    • [^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.

      Post√©¬†par¬† (site web personnel, Mastodon) . √Čvalu√©¬†√†¬†2. Derni√®re modification le 08/12/21 √† 18:56.

      On peut dériver (et faire comme une surcharge) les types …non de base. Les deux ont beaucoup de points commun, sauf que ce n'est pas la même démarche ni façon de faire : c'était l'objet de mon dernier journal ;-)

      Par contre, pas sympa pour Rust de le comparer à 38T mais c'est un suber beau camion :-)

      Au fait, peux-tu me pointer vers les comparaisons Go/Ada ?

      ‚ÄúIt is seldom that liberty of any kind is lost all at once.‚ÄĚ ‚Äē David Hume

      • [^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.

        Post√©¬†par¬† . √Čvalu√©¬†√†¬†2. Derni√®re modification le 09/12/21 √† 09:31.

        Par contre, pas sympa pour Rust de le comparer à 38T mais c'est un suber beau camion :-)

        :) Je ne compare ni Rust ni Go à un 38 tonnes :) Autre illustration: c'est comme comparer A et B sous prétexte que ce sont deux lettres de l'alphabet.

        Au fait, peux-tu me pointer vers les comparaisons Go/Ada ?

        Quel crétin je fais …. Ct pas Go/ada ton journal Rust/Ada :). Est-ce quer l'équipe de modération pourrait corriger SVP (avec le lien en prime ?).

        Merci d'avance.

    • [^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.

      Post√©¬†par¬† . √Čvalu√©¬†√†¬†3.

      Non, je ne suis pas d'accord, pour certains la comparaison Go/Rust ne se pose pas mais ce n'est pas toujours le cas.

      Ce qui m'agace, c'est la phrase de l'article : "tous les langages de programmation offrent un ensemble de compromis" ou "Chaque langage est optimisé pour des choses différentes". C'est faux, il y a des langages qui sont dépassés, il y a des langages qui ont été des tentatives qui n'ont pas abouti… Ce qui est vrai par contre c'est qu'il n'y a pas de langages parfait.

      Et en ce sens Go, comme Rust sont des langages aboutis performants compilés relativement productifs, avec une bonne communauté, un bon ensemble de librairies qui les rendent polyvalents… d'ailleurs, à la base ils étaient concurrents direct pour remplacer C. Aujourd'hui Rust est un bon candidat (le meilleur pour moi) pour remplacer C pas vraiment Go. Pour autant Go peut remplacer C dans un certains nombres de projets un peu moins critiques en performances et ayant un plus grand besoin en facilité de développement/déploiement (Je pense aux applications sur serveurs ou GUI)…

      • [^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.

        Post√©¬†par¬† . √Čvalu√©¬†√†¬†6.

        il y a des langages qui sont dépassés

        Faut faire attention avec √ßa. Parce qu'un langage ne s'√©value pas tout seul. On regarde l'outillage, l'√©cosyst√®me l'existant, la communaut√©, la doc etc. Quand on s'int√©resse aux langages, on a vite fait de trouver tel langage d√©pass√© alors que tel langage qui para√ģt tellement mieux. Mais dans la r√©alit√©, l'√©norme majorit√© de ses langages super ne vont qu'√† peine survivre face √† des langages qui ont une communaut√© folle. On peut s'en plaindre, mais c'est un √©l√©ment qui fait parti du langage.

        Et en ce sens Go, comme Rust sont des langages aboutis performants compilés relativement productifs, avec une bonne communauté, un bon ensemble de librairies qui les rendent polyvalents…

        C'est très subjectif tout ça. Tu as très peu de développeur go ou rust du coup la productivité… Tu as très peu de bibliothèques pour chacun d'eux. Il y a de quoi s'en sortir, mais c'est très faible face au C, javascript, python ou java et ça n'est pas anodin.

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

        • [^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.

          Post√©¬†par¬† . √Čvalu√©¬†√†¬†0.

          Alors site moi un intérêt de développer un logiciel en Basic, en Lisp, Cobol, PL/I. La seul raison que je vois est de maintenir des application existantes pas encore redevelopées. Mais il y a plus ridicule, des langages qui n ont jamais percés.

          Les langages ont tout de même évolué et si certains disparaissent c est pour de bonnes raisons.

          • [^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.

            Post√©¬†par¬† (site web personnel, Mastodon) . √Čvalu√©¬†√†¬†3.

            https://www.bitdegree.org/tutorials/most-used-programming-languages/ par exemple me cite Visual Basic en troisième position… et ne mentionne ni Go ni Rust…

            PL/1 reçoit de l'attention par rapport aux nouveaux truc https://github.com/guija/pl1
            Et y en a encore qui en discutent (un mort bien plus vivant qu'il n'y parait) https://news.ycombinator.com/item?id=29351989
            On nous disait déjà, avant de conclure, que PL/1 et COBOL sont immortels ; et juste avant que Lisp vaut toujours le coup sous sa nouvelle peau Clojure https://insights.dice.com/2014/09/08/unpopular-programming-languages-prove-lucrative/
            Pour la route https://github.com/trending/common-lisp https://github.com/trending/clojure?since=daily https://github.com/trending/cobol?since=daily

            En fait, c'est comme Ada et d'autre ici https://www.quora.com/What-are-some-truly-dead-programming-languages : des gens qui n'utilisent pas, ou ne sont pas dans un milieu o√Ļ on leur en parle, pensent que c'est mort. √áa me rappelle une personne de mes connaissances qui me soutenait mordicus que Linux √©tait mort et qu'il n'y a pas d'entreprise s√©rieuse qui l'utilise.

            ‚ÄúIt is seldom that liberty of any kind is lost all at once.‚ÄĚ ‚Äē David Hume

            • [^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.

              Post√©¬†par¬† . √Čvalu√©¬†√†¬†2. Derni√®re modification le 09/12/21 √† 22:35.

              Moi ça me fait penser également à la mort annoncée des mainframes depuis plus de 20 ans …

              Pourtant ça vit encore, et même bien. On y fait même tourner du Linux et du kube via Openshift …

              • [^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.

                Post√©¬†par¬† . √Čvalu√©¬†√†¬†0. Derni√®re modification le 22/12/21 √† 17:09.

                La vérité c'est que c'est mort, ceux qui tournent sont pour faire tourner des vieux système ou parce qu'il y a des gens qui y croient encore, parce que l'on essaye de le moderniser… Mais fondamentalement, le système Mainframe est mort. Après cela ne veut pas dire qu'il ne peut pas y avoir de la place pour un gros serveur sous Linux…

                C'est comme tout, il y a toujours une certaine utilisation résiduelle pour des questions historique (voire juste par passion historique juste pour le fun). Il n'empêche ça meurt. Ca peut aussi revenir, tout peut arriver. C'est comme dans le monde réel, le cheval de trait, la lampe à pétrole ne sont pas mort, des gens l'utilisent… (Ca représente 0.01% des utilisateurs et 0.0001% du travail)

          • [^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.

            Post√©¬†par¬† . √Čvalu√©¬†√†¬†2.

            Pour moi tu as juste oublié le seul langage à ma connaissance qui serait pertinent de citer dans ta liste : forth.

            Je trouve √ßa dommage car c'est un langage que je trouve int√©ressant. Cela dit aujourd'hui je ne suis pas s√Ľr que ce soit une bonne id√©e de l'utiliser pour un nouveau projet.

          • [^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.

            Post√©¬†par¬† . √Čvalu√©¬†√†¬†4.

            Des languages qui sont l√† pour tuer leur p√®re on en voit arriver 3 par jour. L'√©norme majorit√© tu n'en entendra jamais parler. Parmi ceux dont on entend parler tu en as une part importante qui n'arriveront pas √† cr√©er la dynamique pour v√©ritablement cro√ģtre et les quelques uns qui restent vivront d'une petite communaut√©. Et ceux qui d√©passent leur pr√©d√©cesseur¬†? C'est statistiquement inexistant.

            On dit des fois qu'il faut être 10 ou 100 fois meilleur pour créer une conversion.

            Je crois aussi qu'on a pas idée de la masse que représente les langages installés. Regarde l'almanach du web pour t'en convaincre. Le hype driven développement c'est rien par rapport à la la masse de logiciels produit.

            Les langages ont tout de même évolué et si certains disparaissent c est pour de bonnes raisons.

            D'un point de vue purement logique. C a vu passer des dizaines d'ann√©es de langages con√ßu pour le tuer, il ne va pas dispara√ģtre parce que Marco a sorti un nouveau langage qu'il est beau. Aucun des langages dont tu parles n'est mort et n'importe quel nouveau langage a statistiquement bien plus de chances de mourir.

            https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

            • [^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.

              Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†2.

              On dit des fois qu'il faut être 10 ou 100 fois meilleur pour créer une conversion.

              Ou alors 100x plus mauvais comme PHP !

              Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

            • [^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.

              Post√©¬†par¬† . √Čvalu√©¬†√†¬†2.

              On dit des fois qu'il faut être 10 ou 100 fois meilleur pour créer une conversion.

              De mon avis ‚Ķ Je partazge ton point de vue sur une bonne partie de ce que tu dis. PAr contre pour Rust par rapport au C, je pense qu'il y a un faisceau d'√©l√©m√©nts qui plaident en sa faveur, dont un particulier : le cot√© gestion safe de la m√©moire contr√īl√© √† la compilation, sans (trop) d'impact au runtime. Et √ßa c'est quelque chose qu'on ne trouve pas en C, et qui dans les syst√®mes modernes est de plus en plus probl√©matique. De mon avis ‚Ķ il faudrait que le C √©volue pour permettre nativement une gestion safe de la m√©moire de la m√™me fa√ßon pour ne pas √™tre abandonn√© progressivement.

              Perso ça ne me choque pas, le C malgré ses nombreux défauts est un bon langage, qui a rendu de très bon services. Il n'a pas a rougir de ses défauts, on a su s'adapter …

        • [^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.

          Post√©¬†par¬† . √Čvalu√©¬†√†¬†1.

          C'est très subjectif tout ça.

          Bien s√Ľr mais quand tu regarde en pratique beaucoup de d√©veloppeurs C ont une exp√©rience Rust et beaucoup de d√©veloppeurs Java ou autre ont une exp√©rience Go et les libraires sont tout de m√™me bien pr√©sentes au moins par wrapping d autres langages.

          • [^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.

            Post√©¬†par¬† . √Čvalu√©¬†√†¬†3.

            beaucoup de développeurs C ont une expérience Rust et beaucoup de développeurs Java ou autre ont une expérience Go

            Non. Les développeurs ce n'est pas juste quelques milliers de personnes, hein ? Et beaucoup ne pratique ça qu'au boulot et dans un cadre industriel. Ils arrivent pas le lundi matin en expliquant qu'il faut refaire les choses en ocaml parce que ça corrigerai le dernier bug qu'il a trouvé.

            les libraires sont tout de même bien présentes au moins par wrapping d autres langages.

            Ouai c'est ce que vendent tous les concepteurs de langages, √ßa permet de d√©marrer avec quelque chose. Mais c'est chiant de se maintenir un binding, √ßa ne marche pas toujours tr√®s bien (en rust par exemple c'est compliqu√© de maintenir les propri√©t√©s du langage) et tu as tr√®s peu de bindings. La masse de biblioth√®que c, java, python et js est absolument d√©lirante M√©zi√®res tu trouve ce que tu cherche. √Ä l'√©poque o√Ļ je m'√©tais amus√© avec go faire de l'amqp √ßa ne se faisait pas trop avec la derni√®re version du langage.

            https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

            • [^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.

              Post√©¬†par¬† . √Čvalu√©¬†√†¬†2.

              Ouai c'est ce que vendent tous les concepteurs de langages, ça permet de démarrer avec quelque chose.

              Perso je ne suis pas fan des bindings …. Pour moi c'est un mal nécessaire en attendant de trouver mieux.

              ça ne marche pas toujours très bien (en rust par exemple c'est compliqué de maintenir les propriétés du langage)

              C'est effectivement une des raisons pour lesquelles je n'aime pas le binding … mais d'un autre coté ça permet, comme tu le dis, pour quelqu'un qui veut déjà faire la transition d'un soft écrit dans un langage donné vers un autre de commencer par quelque chose. Mais l'idéal c'est que ça reste transitoire.

              La masse de bibliothèque c, java, python et js est absolument délirante

              Oui, mais peut-être un peu trop pour certains langages (JS). En rust ça commence à venir … mais c'est clair que ça ne se fera pas du jour au lendemain. Cela dit certains gros acteurs du logiciel s'y mettent, j'espère que ça accélerera les choses.

              √Ä l'√©poque o√Ļ je m'√©tais amus√© avec go faire de l'amqp √ßa ne se faisait pas trop avec la derni√®re version du langage.

              La tu mets le doigt sur ce qui est pour moi un besoin des langages bas niveaux tels que C, C++, Ada et rust : une stabilité de la norme, qui permettra d'implémenter des surcouches qui elles se baseront sur un socle stable. Ca vient je pense … Si on regarde deux ou trois ans en arrière (l'époque ou j'ai commencé à m'intéresser à Rust), on sent qu'il y a des choses qui bougent, un certain engouement. Apres, c'est pas impossible que cet engouement ne reste pas.

              Maintenant, juste pour préciser … je ne suis pas un "fanboy" de Rust … Je ne suis pas convaincu qu'il faille convertir en rust tous les programmes écrits en C, et je sais que Rust a ses défauts, mais je suis d'avis que Rust remplacera avantageusement C dans beaucoup de cas d'usage ou le C impose de se creuser la tête et fait prendre des risques sur la sécurité. A l'inverse je crois également que certains bout de code n'aurnt aucun intéret a être réécrits en Rust parce qu'ils sont très bien comme ils sont, font le boulo, avec une mémoire qui a été bien gérée par le développeur.

      • [^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.

        Post√©¬†par¬† . √Čvalu√©¬†√†¬†3.

        Aujourd'hui Rust est un bon candidat (le meilleur pour moi) pour remplacer C

        Va y avoir du boulot pour d√©velopper des compilos pour tous les microcontr√īleurs.

        • [^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.

          Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†5.

          https://tinygo.org/ est bien parti :-)

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: Comparer Go et Rust, c'est comme si on comparait une F1 et un 38 tonnes.

          Post√©¬†par¬† . √Čvalu√©¬†√†¬†1.

          C clair mais perso √ßa ne m'emp√™che pas de penser la m√™me chose (mais en un peu plus nuanc√© par contre. Le C ne dispara√ģtra pas du jour au lendemain, vu la quantit√© de code existant, mais pour moi c'est le seul langage suffisamment cr√©dible pour prendre sa place au fil du temps).

          Mais bon … Il me semble que derrière l'implémentation "officielle" Rust, c'est LLVM, et que LLVM supporte de plus en plus d'architectures et de processeurs. Puis si les compilos C/C++ proprios sont bien faits, les éditeurs ne devraient pas avoir trop de mal à les adapter quand le marché le demandera.

  • # Le choix est simple

    Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†0.

    Tout sauf Go.

    Plus détaillé :

    • aucun int√©r√™t,
    • pas de pattern matching,
    • garbage collector c'est so 2000,
    • pas de vraie g√©n√©ricit√©.

    En fait il y a trop de raisons, j'y suis encore jusqu'à midi. Je vous laisse chercher.

    git is great because linus did it, mercurial is better because he didn't

    • [^] # Re: Le choix est simple

      Post√©¬†par¬† . √Čvalu√©¬†√†¬†5.

      Mais… mais… on est pas encore trolldi :(.

      La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.

    • [^] # Re: Le choix est simple

      Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†6.

      garbage collector c'est so 2000

      Ne craint pas la faucheuse !

      Un ramasse miette :

      • est intuitif et tr√®s simple pour le d√©veloppeur¬†;
      • fonctionne bien dans 99% des cas¬†;
      • m√™me quand on a besoin de faible latence, la plupart des jeux √©crit avec Unity, Godot, Java, Javascript en t√©moigne¬†;
      • ont fait l'objet de beaucoup d'optimisations ses derni√®res ann√©es.

      La mauvaise réputation des GC vient des premières implémentations "stop the world" notamment celles des vieux Java.

      A c√īt√© les smart pointers de C++ et Rust sont int√©ressants, mais plus p√©nibles et ne g√®rent pas tous les cas (√† tel point que l'ajout d'un GC en Rust a √©t√© envisag√©).

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: Le choix est simple

        Post√©¬†par¬† . √Čvalu√©¬†√†¬†2.

        La mauvaise réputation des GC vient des premières implémentations "stop the world" notamment celles des vieux Java.

        Hors mis Azul, qui n'est pas libre, (et noop, mais il compte pas) tous les autres GC de la plateforme font du stop the world c'est juste qu'ils en font moins voir que la durée de la pause n'est pas corrélée à la taille de la heap.

        Je ne dis pas que les gc sont un problème (au contraire), mais que le sujet n'est pas avec/sans gc.

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: Le choix est simple

        Post√©¬†par¬† . √Čvalu√©¬†√†¬†0.

        fonctionne bien dans 99% des cas ;

        Je redescendrais à 90%, voire moins vu que 90% des applications ne sont pas écrites dans un langage avec GC.

        A c√īt√© les smart pointers de C++ et Rust sont int√©ressants, mais plus p√©nibles et ne g√®rent pas tous les cas (√† tel point que l'ajout d'un GC en Rust a √©t√© envisag√©).

        Pourquuoi pas ? Si les deux approches permettent de gérer tous les cas … Cela dit j'ai un peu de mal à comprendre comment gérer un GC dans un langage nativement compilé …

        • [^] # Re: Le choix est simple

          Post√©¬†par¬† . √Čvalu√©¬†√†¬†3.

          Je connais pas la technique, mais cela existe déjà en Objective C :

          https://gcc.gnu.org/onlinedocs/gcc/Garbage-Collection.html

        • [^] # Re: Le choix est simple

          Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†4.

          Je redescendrais à 90%, voire moins vu que 90% des applications ne sont pas écrites dans un langage avec GC.

          Ah ? Vu le nombre d'applications écrites avec Java, Javascript, Python… Le pourcentage doit être élevé. Il y a un historique important d'applications en C, mais elles pourraient (et le sont parfois) être réécrite avec des langages à GC.

          Pourquuoi pas ? Si les deux approches permettent de gérer tous les cas …

          https://manishearth.github.io/blog/2015/09/01/designing-a-gc-in-rust/
          https://github.com/rust-lang/rfcs/issues/415

          Cela dit j'ai un peu de mal à comprendre comment gérer un GC dans un langage nativement compilé …

          Go est nativement compilé et a un GC :-)

          Pour le C il y a https://www.hboehm.info/gc/

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

          • [^] # Re: Le choix est simple

            Post√©¬†par¬† . √Čvalu√©¬†√†¬†1.

            Cela dit j'ai un peu de mal à comprendre comment gérer un GC dans un langage nativement compilé …

            Attention, je crois que certains ont mal compris … je ne dis pas que c'est impossible, je n'ai juste aucune idée de comment on peut faire ça en dehors d'une machine virtuelle style JVM (et ça m'intéresse de savoir)

          • [^] # Re: Le choix est simple

            Post√©¬†par¬† . √Čvalu√©¬†√†¬†1.

            Ah ? Vu le nombre d'applications écrites avec Java, Javascript, Python… Le pourcentage doit être élevé.

            Oui, 90% n'est pas un faible pourcentage … ça reste élevé. Mais je reste convaincu qu'il y a plus de 1% d'applications qui ne pourraient pas fonctionner avec un GC (enfin tel qu'ils sont implémentés aujourd'hui).

        • [^] # Re: Le choix est simple

          Post√©¬†par¬† . √Čvalu√©¬†√†¬†4.

          Je redescendrais à 90%, voire moins vu que 90% des applications ne sont pas écrites dans un langage avec GC.

          Le fait que ça n'utilise pas de langage à gc n'indique pas que ce n'est pas un cas d'usage qui fonctionne avec un gc.

          Cela dit j'ai un peu de mal à comprendre comment gérer un GC dans un langage nativement compilé …

          Parce que ça n'a rien à voir. On amalgame souvent machine virtuelle, compilation jit, garbage collector,… mais ce sont des choses différentes.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

        • [^] # Re: Le choix est simple

          Post√©¬†par¬† . √Čvalu√©¬†√†¬†1.

          90% des applications ne sont pas écrites dans un langage avec GC

          Alors l√† clairement non, la GC, est le 1er √©l√©ment de "virtualisation" possible. Alors tous les langages interpr√®t√©s, tous les langages avec compilation JIT et bien s√Ľr les langages avec JVM l utilisent. En compil√© je vois Go et Ada √† ma connaissance. En fait les seuls langages sans encore utilis√© sont Cobol, Pascal, C, C++‚Ķ bref des langages utilis√© que dans des services tr√®s critiques niveau perfs, pas la majorit√© du code √©crit chaque jour.

    • [^] # Re: Le choix est simple

      Post√©¬†par¬† . √Čvalu√©¬†√†¬†4.

      C'est dommage, pour moi le Go est très bon quand je travaille pour des applications back-end qui font principalement de l'entrée/sortie (exposant/consommant une API, BDD …) et qui tournent dans des pod très contraints en ressources (quelques dizaines de milli-cpu ou centaines de Mo de RAM). Ce qui représente la majorité de mon travail depuis plus de 5 bonnes années.

      Dans ce contexte, Go me permet très facilement d'avoir une application performante et cela sans aucune configuration.

      Rust, pour moi, est plus d√©licat √† mettre en Ňďuvre dans ce contexte. Il faudra n√©cessairement g√©rer les entr√©es/sorties en asynchrones car je ne peux pas bloquer mon thread car il a bien d'autres choses √† faire que d'attendre :)

      • [^] # Re: Le choix est simple

        Post√©¬†par¬† . √Čvalu√©¬†√†¬†2.

        Go a été conçu pour ça. Rust non

    • [^] # Re: Le choix est simple

      Post√©¬†par¬† . √Čvalu√©¬†√†¬†1. Derni√®re modification le 09/12/21 √† 21:29.

      Tout sauf Go

      Oui mais quand tu compare a Java ou il manque toujours une dépendance quand ce n est pas carrément la JVM qui est incompatible…

  • # Ben pour ma part...

    Post√©¬†par¬† . √Čvalu√©¬†√†¬†1. Derni√®re modification le 09/12/21 √† 22:19.

    J'ai un langage qui me va très bien.

    Il a commencé sa vie sous le nom de COOL (C like Object Oriented Language) aujourd'hui entièrement libre et multiplateforme, et avec la compilation native en vue il est encore plus cool.

    "Quand certains r√Ęlent contre systemd, d'autres s'attaquent aux vrais probl√®mes." (merci Sinma !)

  • # re: Rust versus Go : round 1, fight !

    Post√©¬†par¬† (site web personnel) . √Čvalu√©¬†√†¬†3.

    Je résumerai la problématique en : Si tu préfère C à C++, tu préféreras Go à Rust. Et vice-versa.

Suivre le flux des commentaires

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