• # Commentaire supprimé

    Posté par  . Évalué à 8.

    Ce commentaire a été supprimé par l’équipe de modération.

  • # 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 décembre 2021 à 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 décembre 2021 à 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 décembre 2021 à 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 décembre 2021 à 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.

  • # 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é à 1. Dernière modification le 09 décembre 2021 à 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 décembre 2021 à 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 !)

  • # Commentaire supprimé

    Posté par  . Évalué à 3.

    Ce commentaire a été supprimé par l’équipe de modération.

Suivre le flux des commentaires

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