Le point sur les avancées de Google Go

Posté par (page perso) . Modéré par Xavier Teyssier.
19
29
mar.
2010
Golang
Le langage Go (sous une licence de type BSD) est issu d'une discussion entre Ken Thompson (un des auteurs d'Unix et d'UTF8) et Rob Pike (un des auteurs de Plan9 et d'UTF8). Rob Pike a pu monter une équipe chez Google pour travailler dessus, et en novembre 2009, une première version a été dévoilée au reste du monde.

Depuis, le développement continue d'avancer à un bon rythme. Des versions sont publiées tous les 10 à 15 jours.

Dernièrement, une proposition pour un mécanisme similaire aux exceptions a été discuté sur la liste de diffusion. C'est un exemple très révélateur de la manière d'avancer de l'équipe en charge de Go : ils ne se précipitent pas pour ajouter des fonctionnalités présentes dans d'autres langages parce qu'elles sont très demandées. Ils prennent le temps de réfléchir à chaque problème, et quand ils ont trouvé une piste qui semble pouvoir répondre à leurs exigences, ils publient une proposition sur la liste de diffusion. Il s'en suit des discussions qui permettent de raffiner la proposition et, sauf surprise, la proposition est intégrée dans la version suivante.

Côté communication, l'essentiel se passe sur le canal IRC #go-nuts sur freenode et sur la liste de diffusion Go-nuts. Un wiki a récemment été mis en place pour regrouper des informations sur l'écosystème de Go. Quelques jours plus tard, un blog officiel a suivi. Enfin, un dashboard permet de voir l'état des compilations sur les différentes architectures supportées.

Globalement, les personnes qui ont essayé Go semblent convaincues que ce langage est promis à un grand avenir.
  • # Extrait de "Effective Go"

    Posté par . Évalué à  10 .

    >One caveat. You should never put the opening brace of a control
    >structure (if, for, switch, or select) on the next line. If you do, a
    >semicolon will be inserted before the brace, which could cause
    >unwanted effects. Write them like this

    >if i < f() {
    > g()
    >}

    >not like this

    >if i < f() // wrong!
    >{ // wrong!
    > g()
    >}

    Wow. J'espère que le compilateur est assez intelligent pour prévenir qu'il y a quelque chose de louche, sinon ça va être sympa pour ceux qui sont multilangages et à qui il arrivera d'oublier une accolade en début de ligne..
  • # grand avenir

    Posté par . Évalué à  4 .

    Globalement, les personnes qui ont essayé Go semblent convaincues que ce langage est promis à un grand avenir.

    Heu, grosso modo on a interviewé trois personnes qui ont dit qu'ils aimaient Go. On ne sait pas comment ils ont été choisis, ni ce qu'auraient dit les (N-3) qui n'ont pas été interviewés.

    À ce que j'en vois, Go semble susciter assez peu d'enthousiasme. Il arrive trop tard à mon avis, et la syntaxe foireuse ne va pas faciliter la tâche de ses supporters.
    • [^] # Re: grand avenir

      Posté par . Évalué à  3 .

      Je croyais que j'étais le seul à trouver ce langage complètement merdique, avec sa syntaxe horrible, pire que le C (et dieu sait que c'était pas facile de faire pire).

      Honnêtement, à part le fait que "c'est fait par Google donc saibien", je ne vois aucune amélioration objective qui me ferait passer à Go.
      • [^] # Re: grand avenir

        Posté par (page perso) . Évalué à  6 .

        sa syntaxe horrible, pire que le C (et dieu sait que c'était pas facile de faire pire)

        Et pourtant, C++ existe.
        • [^] # Re: grand avenir

          Posté par . Évalué à  8 .

          La syntaxe du C est honnêtement très potable. J'ai l'impression que la niche du Go, c'est précisément les gens qui aiment C, qui voudraient un truc un peu plus moderne mais qui ne peuvent pas supporter C++.
          (C++ étant d'ailleurs l'un des langages principaux chez Google)
      • [^] # Re: grand avenir

        Posté par . Évalué à  9 .

        > Honnêtement, à part le fait que "c'est fait par Google donc saibien", je ne vois aucune amélioration objective
        Pour l’avoir utilisé dans deux mini-projets (pour utilisation personnelle, mais qui tournent 100% du temps sur ma machine : un proxy DNS et un proxy HTTP):

        Les plus:
        - Passé quelques surprises, on retrouve finalement rapidement ses marques quand on a fait du C. Et je code plus efficacement qu’en C, au final (grâce, entre autre, aux types de base de bien plus haut niveau)
        - Le système de typage est parfait. Disons plus modestement : c’est celui dont j’avais toujours rêvé
        - Comme Python, "piles inclues" (librairie standard bien fournie)
        - Le couple goroutine + channel, c’est également magique dès lors que tu as du multi-threading ; mon proxy DNS a un cache global dans lequel chaque client a une tâche lectrice et une tâche écrivain dessus. En multitâche classique, c’est le mal de crâne assuré pour synchroniser tout ce joli monde. En go, ça se fait tout seul (pas un seul mutex/sémaphore de tout le programme !)
        - Le truc secondaire sur papier, absolument génialissime (et c’est encore un euphémisme) en pratique : le mot-clé defer.

        Les moins:
        - Le plus gros point, très gênant : le GC laisse passer des fuites de mémoire. Actuellement, mon proxy DNS tourne depuis trois jours, et utilise plus de 100 Mo de mémoire. Si je le redémarre, il n’en utilise plus que 5 Mo (et vu comme il est codé, le redémarrage ne devrait pas influer sur l’utilisation mémoire: le cache est sauvegardé sur disque puis rechargé au lancement)
        - La librairie HTTP de base est… comment dire… totalement merdique. Ça c’est amélioré dans la version en développement, mais il y a encore un peu de boulot
        - Interfaçage avec le C pas toujours trivial (et dès qu’il y a des pointeurs de fonction, ça devient VRAIMENT horrible)
        - Ce que GCC met en "warning: unused xxx", Go en fait une erreur. C’est très énervant lors de la mise au point.

        Pour ma part, il est définitivement adopté pour tout ce qui est "petits serveurs bas niveau" (typiquement : proxy HTTP qui ne touche pas au contenu des pages, proxy DNS, et pour la suite : filtre milter)
        • [^] # Re: grand avenir

          Posté par . Évalué à  6 .

          Erlang est également un bon candidat pour tes besoins, et il fait de la vraie concurrence sans partage de mémoire, donc il permet trivialement de distribuer le travail. Il existe des exemples de serveurs HTTP en Erlang.
          • [^] # Re: grand avenir

            Posté par . Évalué à  2 .

            Je connaissais de nom, mais dans mon « cahier des charges », il y avait « facilité de prise en main », sachant que je fais en grande majorité du Python/C. Erlang est un langage fonctionnel, donc ça n’entre pas dedans.
            (et je fais une allergie aux langages inspirés de Prolog ;))
            • [^] # Re: grand avenir

              Posté par (page perso) . Évalué à  3 .

              >> Erlang est un langage fonctionnel, donc ça n’entre pas dedans.
              >> (et je fais une allergie aux langages inspirés de Prolog ;))

              Et moi, je déteste les choux de Bruxelles, car je n'aime pas faire de la planche à voile.

              Rassure moi, « langage fonctionnel » et « prolog » sont bien indépendants dans ta phrase, là ?
              • [^] # Re: grand avenir

                Posté par . Évalué à  1 .

                > Rassure moi, « langage fonctionnel » et « prolog » sont bien indépendants dans ta phrase, là ?
                Oui, pourquoi ?
        • [^] # Re: grand avenir

          Posté par . Évalué à  1 .

          s/euphémisme/litote/
  • # Python

    Posté par . Évalué à  4 .

    A la faveur d'une exception, je remarque qu'une partie de l'infrastructure Web de Go est écrite en Python:

    (résultat de http://godashboard.appspot.com/benchmarks )

    Traceback (most recent call last):
    File "/base/python_lib/versions/1/google/appengine/ext/webapp/__init__.py", line 510, in __call__
    handler.get(*groups)
    File "/base/data/home/apps/godashboard/3.340308809368074859/gobuild.py", line 363, in get
    page = self.compute(num)
    File "/base/data/home/apps/godashboard/3.340308809368074859/gobuild.py", line 369, in compute
    benchmarks, builders = benchmark_list()
    File "/base/data/home/apps/godashboard/3.340308809368074859/gobuild.py", line 524, in benchmark_list
    benchmarks = [r.benchmark for r in q.fetch(1000)]
    File "/base/python_lib/versions/1/google/appengine/ext/db/__init__.py", line 1626, in fetch
    raw = raw_query.Get(limit, offset, rpc=rpc)
    File "/base/python_lib/versions/1/google/appengine/api/datastore.py", line 1240, in Get
    limit=limit, offset=offset, prefetch_count=limit, **kwargs)._Get(limit)
    File "/base/python_lib/versions/1/google/appengine/api/datastore.py", line 1167, in _Run
    datastore_pb.QueryResult(), rpc)
    File "/base/python_lib/versions/1/google/appengine/api/datastore.py", line 186, in _MakeSyncCall
    rpc.check_success()
    File "/base/python_lib/versions/1/google/appengine/api/apiproxy_stub_map.py", line 474, in check_success
    self.__rpc.CheckSuccess()
    File "/base/python_lib/versions/1/google/appengine/api/apiproxy_rpc.py", line 126, in CheckSuccess
    raise self.exception
    MemoryError
  • # facilité et puissance

    Posté par . Évalué à  2 .

    je ne connais pas tous les langages (loin de là) mais depuis que je me suis mis au python il y a quelques mois, je tire la tronche à chaque fois que je dois coder avec un autre langage.

    Python est multi-plateforme, libre, vraiment bien supporté et surtout on peut tout faire avec ! (web/appli/daemon/script...). Et ce qui fait la différence est sa lisibilité et sa compréhension.

    A chaque fois qu'un nouveau langage sort, je fais systématiquement la comparaison avec python. Au final python winner++.
    • [^] # Re: facilité et puissance

      Posté par (page perso) . Évalué à  10 .

      Paf, en plein dedans.

      Python fait parti des langages "officiels" de Google, avec C++ et Java, ils ont même Mr Python qui bosse chez eux : Guido Von Rossum. Google App Engine est d'abord sorti en python, comme autre exemple.
      Sauf que Python, que j'aime beaucoup a UN problème, il gère les threads comme une bouse. Ca existe, mais il y a un gros lock qui pourri les performances. Tu peux avoir des taches en parallèle, mais pas profiter de la puissance d'une architecture multicore. Antoine Pitrou a proposé des patchs pour corriger ça, mais ça ne semble pas encore être le nirvana.

      L'idée de Go est d'avoir un langage qui ne soit pas chiant à compiler (comme C++), mais qui gère les multicore comme il faut (pas comme Python).
      • [^] # Re: facilité et puissance

        Posté par . Évalué à  10 .

        Sauf que Python, que j'aime beaucoup a UN problème, il gère les threads comme une bouse. Ca existe, mais il y a un gros lock qui pourri les performances. Tu peux avoir des taches en parallèle, mais pas profiter de la puissance d'une architecture multicore. Antoine Pitrou a proposé des patchs pour corriger ça, mais ça ne semble pas encore être le nirvana.

        Ça ne sera le nirvana que si le GIL (gros verrou de l'interpréteur) est supprimé un jour, et ce n'est pas pour demain... car beaucoup de boulot, très complexe surtout si on ne veut pas que les performance mono-thread souffrent au passage.
        Pour info, même PyPy (réimplémentation complète de Python en Python) a un GIL.

        Mes patches ont simplement pour objet d'éliminer les inefficacités au niveau de la gestion du verrou lui-même, pas de le supprimer.
        • [^] # Re: facilité et puissance

          Posté par . Évalué à  2 .

          surtout si on ne veut pas que les performances mono-thread souffrent au passage.

          en meme temps, avec l'ere des multi-cores (et celle des many-cores au tournant), cette contrainte devient de plus en plus archaique.

          ceci etant, jython ou ironpython pourrait arriver a la rescousse (puisqu'ils n'ont pas de GIL)

          [enfin bon, tant que 'multiprocessing' marche et que cython facilite l'ecriture de modules...]
          • [^] # Re: facilité et puissance

            Posté par . Évalué à  4 .

            en meme temps, avec l'ere des multi-cores (et celle des many-cores au tournant), cette contrainte devient de plus en plus archaique.

            Non pas du tout.
            Premièrement parce qu'il y a beaucoup de problèmes qui ne sont pas (ou médiocrement, ou difficilement) parallélisables.
            Deuxièmement parce qu'il y a toujours des situations où tu n'as qu'un ou deux coeurs à disposition. Exemple : virtualisation (notamment, hébergements plus ou moins bon marché). Ou bien : petits appareils portables.
            Troisièmement parce que ce n'est pas parce qu'il y a plein de coeurs que tu veux qu'ils soient accaparés par un programme unique (plutôt qu'affectés à plein de programmes différents).
            • [^] # Re: facilité et puissance

              Posté par . Évalué à  2 .

              moui...

              bon je vois ca depuis ma lunette 'python comme langage pour scientifiques' donc en effet, mon terrain de jeux c'est le bi/quad/octo coeur avec 2Go par coeur.

              je n'ai pas les stats (peut-etre que la PSF les a?) mais il serait sans doute interessant de savoir sur quel type de plateforme python est 'le plus' utilise...
              • [^] # Re: facilité et puissance

                Posté par . Évalué à  2 .

                je n'ai pas les stats (peut-etre que la PSF les a?) mais il serait sans doute interessant de savoir sur quel type de plateforme python est 'le plus' utilise...

                Je ne sais pas. Je pense que l'informatique scientifique est une niche pour Python. Ceci dit les extensions C spécialisées ne relâchent pas déjà le GIL ? Il faudrait qu'elles le fassent.
    • [^] # Re: facilité et puissance

      Posté par . Évalué à  5 .

      Bon je sens qu'on est reparti pour un troll sur les langages de programmation ... je ne vois pas l'intérêt à chaque journal sur un langage de programmation de faire référence à celui que chacun préfère (surtout qu'au niveau langage de script, rien ne vaut Ruby /o\).

      Concernant Go, je pense que l'idée d'inventer un langage avec quelques principes forts pour voir ce que ça donne est intéressante. Par contre j'attendrai que ce langage apporte vraiment quelque choses de nouveau pour m'y intéresser réellement.

      A mon avis, tant qu'on reste dans du développement 'procédural' (comprendre non fonctionnel) qu'importe le langage, normalement un développeur devrait pouvoir se débrouiller correctement assez rapidement.

      J'ai appris à développer sur Java en 99. Ensuite j'ai fait un peu C. J'ai appris la programmation système (socket, IPC, traitement IO) avec Perl. Je me suis ensuite extasié devant Smalltalk, un vrai langage 100% objet (ça fait un choc en venant du monde Java).

      Quand j'ai voulu faire de l'objet en Perl, j'ai commencé à pleurer (depuis je me soigne). J'ai donc commencé à regarder du coté de Python ... puis par miracle (grâce à DLFP) j'ai pris connaissance d'un autre langage de script : Ruby. Je pense que j'ai eu le même 'coup de foudre' avec Ruby qu'avec Smalltalk (avec l'avantage que c'est moins has-been, voir has-never-been).

      Évidemment depuis je bosse dans une SSII ... ça apprend à relativiser ses prétentions techniques. J'ai réussi à éviter le développement Java (bien qu'ayant au départ un CV 95% Java) mais j'ai pas encore réussi à faire du développement Ruby ... je me cantonne à faire du Perl objet (mais c'est déjà bien cool).

      Bref, tout ce passage vieux schnock pour dire que la locution 'Carpe Diem' s'applique aussi très bien en matière de développement.
      • [^] # Re: facilité et puissance

        Posté par (page perso) . Évalué à  3 .

        que nenni, ce n'est point un troll, je suis aussi polyglote, et j'ai plaisir à découvrir de nouveau trucs. Juste que Go a été crée suite a un défaut de conception de Python. C'est donc paradoxal de dire que python lave plus blanc, alors qu'il a déclenché la naissance de Go.
      • [^] # Ruby, c’est fini.

        Posté par . Évalué à  2 .

        Je pense que j'ai eu le même 'coup de foudre' avec Ruby qu'avec Smalltalk

        Moi aussi (pour Ruby, je n’ai jamais essayé Smalltalk).
        Et puis j’ai voulu utiliser un destructeur et l’idylle s’est définitivement terminée aussi rapidement qu’elle avait commencé.

        Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

        • [^] # Re: Ruby, c’est fini.

          Posté par (page perso) . Évalué à  5 .

          Un destructeur dans un langage avec garbage-collector, c'est très dangereux, car tu ne sais jamais quand le destructeur sera appelé. Par exemple, tu ouvres un fichier, tu écris dedans, tu le réouvres (sans conserver de référence vers le premier), tu n'as aucune garantie que le fichier a bien été fermé avant de le ré-ouvrir.

          La méthode Ruby pour traiter ce genre de cas est donc à mon avis assez élégante :

          File.open "youhou" do |f|
          f.write "ceci est un exemple"
          end


          Après le end, tu es sûr que ton fichier est bien fermé.
          • [^] # Re: Ruby, c’est fini.

            Posté par . Évalué à  3 .

            La méthode Ruby pour traiter ce genre de cas est donc à mon avis assez élégante

            Oui c'est très bien quand la durée de vie de ton objet est limitée lexicalement.
            (Python a le mot-clé "with" qui fonctionne sur le même principe)

            Mais il y a des situations où tu veux que ton objet survive à la fonction courante, tout en assurant une déallocation de ressource lorsque plus personne ne le référence.
            (en Python, tu peux aussi jouer avec les weakrefs, mais __del__ est plus simple à utiliser)
            • [^] # Re: Ruby, c’est fini.

              Posté par (page perso) . Évalué à  2 .

              La déallocation ça n'existe pas en ruby, puisque qu'il n'y a pas d'alloc non plus.

              Pourrais-tu donc me donner un exemple concret d'utilisation d'un destructeur, qui ne pose pas de problème avec le garbage collector (c'est-à-dire que ne pas savoir quand le destructeur est appelé n'est pas un problème), et qui ne puissent pas se résoudre simplement avec la méthode Ruby ?
              • [^] # Re: Ruby, c’est fini.

                Posté par . Évalué à  3 .

                qui ne pose pas de problème avec le garbage collector (c'est-à-dire que ne pas savoir quand le destructeur est appelé n'est pas un problème)

                Effectivement c'est une constrainte assez restrictive.
                Ceci dit, une socket par exemple, tu aimerais qu'elle soit fermée lorsque tu n'en as plus besoin, mais s'il s'écoule quelques secondes avant cette fermeture, c'est acceptable.
                (après tout dépend bien sûr de la réactivité du GC... je ne connais pas Ruby)

                et qui ne puissent pas se résoudre simplement avec la méthode Ruby ?

                Comme j'ai dit : toute situation où la ressource (fichier, socket, connexion SGBD...) n'est pas simplement locale à une fonction, mais ouverte pour un certain temps et éventuellement utilisée par plusieurs objets ou modules. C'est pas bien compliqué à imaginer, et assez courant :)
          • [^] # Re: Ruby, c’est fini.

            Posté par . Évalué à  0 .

            Un destructeur dans un langage avec garbage-collector, c'est très dangereux

            Moi aussi, je suis convaincu que le choix d’un garbage collector est une erreur de conception, surtout pour un langage orienté objet.

            Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

            • [^] # Re: Ruby, c’est fini.

              Posté par (page perso) . Évalué à  2 .

              Ouais enfin je fais moins de bugs en n'ayant pas de destructeurs qu'en gérant la mémoire moi-même…
              • [^] # Re: Ruby, c’est fini.

                Posté par (page perso) . Évalué à  2 .

                Sauf que les problèmes de mémoires quand tu la gères toi même, tu peut les corriger. Si tu testes assez ton programme, tu n'as plus vraiment de problèmes à la fin.

                Avec un garbage collector, t'as les inconvénients, tout le temps.

                Envoyé depuis mon lapin.

                • [^] # Re: Ruby, c’est fini.

                  Posté par (page perso) . Évalué à  2 .

                  Avec un garbage collector, t'as les inconvénients, tout le temps.

                  Et c'est quoi les inconvénients ? Parce que si tu parles des destructeurs, ça revient à remplacer une demande de libération de mémoire par un appel manuel à un destructeur, donc il ne peut y avoir que des choses en moins.
                  • [^] # Re: Ruby, c’est fini.

                    Posté par (page perso) . Évalué à  -1 .

                    La consommation mémoire plus élevée en moyenne, pour moi c'es t un inconvénient très important. Pas en temps que développeur, mais en tant qu'utilisateur.

                    Après même si je ne fais pas du temps réel, j'ai lu que le déclenchement du garbage collector pause des problèmes pour le temps réel. Bon je te l'accorde qu'en ruby, on s'en fiche.

                    C'est pas grand chose comme inconvénients, mais ça me gonfle vraiment d'avoir un redmine qui prends un quart de la ram de mon serveur, de devoir relancer firefox régulièrement, d'avoir mon ordi qui swap à chaque fois que je lance eclipse, ou qu'un bébé phoque meurt à chaque fois que le garbage collector de la machine virtuelle de java se déclenche automatiquement (heureusement pour les phoques, ça arrive très rarement).

                    Envoyé depuis mon lapin.

                • [^] # Re: Ruby, c’est fini.

                  Posté par . Évalué à  6 .

                  Sauf que les problèmes de mémoires quand tu la gères toi même, tu peut les corriger. Si tu testes assez ton programme, tu n'as plus vraiment de problèmes à la fin.

                  Il fait combien de lignes, ton programme qui n'a plus vraiment de problèmes à la fin ?
                  Parce que des fuites mémoire dans des programmes C, on en trouve régulièrement, y compris dans des projets vachement mûrs.
                  • [^] # Re: Ruby, c’est fini.

                    Posté par (page perso) . Évalué à  0 .

                    Même si on en trouve, elles sont moins pénibles que les inconvénients d'un ramasse miettes.

                    Si la fuite est trop importante, elle est corrigée.

                    Envoyé depuis mon lapin.

                    • [^] # Re: Ruby, c’est fini.

                      Posté par . Évalué à  3 .

                      C'est pas grave, yakafokon, les bugs sont corrigés automatiquement... Merci, c'est très sérieux tout ça.
                      • [^] # Re: Ruby, c’est fini.

                        Posté par (page perso) . Évalué à  2 .

                        Ce que je ne trouve pas sérieux, c'est de ne pas corriger un tel bug.

                        Puis même si le bug n'est pas corrigé, ça fonctionne aussi bien qu'un truc avec ramasses miettes. C'est pratique.

                        Envoyé depuis mon lapin.

                        • [^] # Re: Ruby, c’est fini.

                          Posté par . Évalué à  2 .

                          Ce que je ne trouve pas sérieux, c'est de ne pas corriger un tel bug.

                          Ce n'est pas la question. Tu as l'air de penser que c'est trivial de corriger de tels bugs et que la charge de travail occasionnée ne serait pas mieux utilisée ailleurs (ce qui serait le cas en utilisant une gestion mémoire automatique intégrée au langage).

                          Au-delà de la charge de travail liée à la correction des bugs, il y a celle, encore plus grande, liée au fait de devoir gérer la mémoire explicitement, ce qui réclame une attention de tous les instants et rend également le code beaucoup plus verbeux. Là encore, beaucoup de temps perdu qui aurait pu être utilisé à des tâches plus productives.

                          Puis même si le bug n'est pas corrigé, ça fonctionne aussi bien qu'un truc avec ramasses miettes.

                          C'est les bisounours qui colmatent les fuites ? Bonne chance en tout cas.
                          • [^] # Re: Ruby, c’est fini.

                            Posté par (page perso) . Évalué à  2 .

                            Comme je l'ai dit plus haut, je me place en tant qu'utilisateur, et pas en tant que développeur. Que ça fasse plus de boulot, j'en ai pas grand chose à faire. C'est le problème de l'équipe qui fait le programme.

                            Envoyé depuis mon lapin.

                            • [^] # Re: Ruby, c’est fini.

                              Posté par . Évalué à  4 .

                              Ben c'est une réaction contradictoire et ignorante, surtout dans le cadre du logiciel libre.
                              Si les développeurs passent plus de temps à traquer les bugs à la noix (fuites de mémoire), ils passeront moins de temps à ajouter des fonctionnalités, etc. Et ça impacte l'utilisateur que tu es.
                              • [^] # Re: Ruby, c’est fini.

                                Posté par (page perso) . Évalué à  2 .

                                Sauf qu'un logiciel de qualité a un bon design, et qu'une fuite de mémoire n'est en général que le résultat d'une bête erreur.

                                Je connais pas grand monde qui part en croisade contre les fuites mémoires sur gnome, et pourtant gnome ne consomme pas énormément de ram. Et on peut pas dire que l'utilisateur en est mécontent.

                                Envoyé depuis mon lapin.

                                • [^] # Re: Ruby, c’est fini.

                                  Posté par . Évalué à  2 .

                                  Sauf qu'un logiciel de qualité a un bon design, et qu'une fuite de mémoire n'est en général que le résultat d'une bête erreur.

                                  On va arrêter là, car la discussion devient circulaire. « Il suffit » de corriger les bugs (« bêtes erreurs »), ok :)
            • [^] # Re: Ruby, c’est fini.

              Posté par . Évalué à  1 .

              Uhm, Bertrand Meyer lui conside (cf OOSC) que pour la modularité tout vrai langage objet devait avoir un GC.

              Comme c'est le concepteur d'Eiffel, il a quelques solide references..
              Tu as quoi comme arguments pour soutenir ton affirmation?
      • [^] # Re: facilité et puissance

        Posté par (page perso) . Évalué à  0 .

        Concernant Go, je pense que l'idée d'inventer un langage avec quelques principes forts pour voir ce que ça donne est intéressante. Par contre j'attendrai que ce langage apporte vraiment quelque choses de nouveau pour m'y intéresser réellement.

        Oui mais bon, autant choisir des principes forts qui n'avaient pas déjà été essayés en 1968…
        http://www.cowlark.com/2009-11-15-go/
        • [^] # Re: facilité et puissance

          Posté par . Évalué à  1 .

          > Oui mais bon, autant choisir des principes forts qui n'avaient pas déjà été essayés en 1968…
          Pourquoi ?
          • [^] # Re: facilité et puissance

            Posté par (page perso) . Évalué à  -1 .

            Tu as lu le lien ?

            Plutôt que de réinventer un langage de zéro, autant adopter Algol 68, qui est déjà spécifié proprement… il aurait suffit de remettre un compilo au gout du jour.

            Enfin bon ce qui me frustre surtout c'est le manque d'inventivité. La plupart des langages qui sortent maintenant sont des resucées de ce qui existe déjà, un peu de ci, un peu de ça, et il n'y a que rarement une nouveauté réelle ou une approche intéressante d'un problème connu : les modules de Newspeak, les séquences en Clojure… éventuellement les goroutines, mais c'est pas bien différents de ce qu'il y a en Erlang…
            • [^] # Re: facilité et puissance

              Posté par . Évalué à  3 .

              > Plutôt que de réinventer un langage de zéro, autant adopter Algol 68
              Ce n’est pas ce que tu as dit. Ce que tu as dit, c’est, je cite « autant choisir des principes forts qui n'avaient pas déjà été essayés en 1968… » Et je ne vois par pourquoi "Algol 68 le faisait avant" devrait interdire Google de reprendre ces concepts.

              Quant à la pertinence de faire un nouveau langage… Je connais pas Algol, mais de cet article, je vois quelques différences :
              - type "map" de base
              - les channels sont typés
              - mot clef "defer"
              - le système de typage basé sur les interfaces est de loin plus riche que le comparatif franchement limité "object orientation" le montre
              Repartir de zéro permet d’avoir les coudées franches sur ce genre de choses

              > Enfin bon ce qui me frustre surtout c'est le manque d'inventivité.
              Je ne pense pas que ce soit le but de ce langage
    • [^] # Re: facilité et puissance

      Posté par (page perso) . Évalué à  10 .

      Au final python winner++.

      Amusant que tu utilises cette syntaxe alors qu'elle n'est pas utilisable en Python ... ;p
  • # Un article sur Go

    Posté par (page perso) . Évalué à  5 .

    Je viens juste de trouver un nouvel article sur Go, intitulé "Broken abstraction in Go" : http://research.swtch.com/2010/03/broken-abstractions-in-go.(...)
  • # Ah ouais, quand même !

    Posté par (page perso) . Évalué à  4 .

    >> Des versions sont publiées tous les 10 à 15 jours.
    >> ils ne se précipitent pas pour ajouter des fonctionnalité
    >> Ils prennent le temps de réfléchir à chaque problème
    >> sauf surprise, la proposition est intégrée dans la version suivante.

    Révolutionnaire !
    Sinon, tu peux tenter de lire les archives des mailing lists du langage Scheme pour voir un peu ce que c'est que « réfléchir à chaque problème. » D'ailleurs, en Scheme, sauf surprise, rarement sont les propositions intégrées dans la version suivante…

Suivre le flux des commentaires

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