Journal Go 1

Posté par .
Tags :
21
29
mar.
2012

Hier est sorti la première version de Go, le langage de Google destiné à faire du système. Cette première version est l'aboutissement du developpement de Go depuis le début. Plusieurs packages ont migré dans la hiérarchie pour plus de cohérence. Les programmes qui seront écrits pour cette version 1 auront l'assurance de fonctionner avec les futures versions 1.X qui viendront.

Plus d'informations sur cette version 1 :
http://blog.golang.org/2012/03/go-version-1-is-released.html

Le site web de Go :
http://golang.org/

Un jour quand j'aurai le temps, je ferai une jolie critique négative de ce langage. J'en suis l'évolution, mais je crois que je ne coderai jamais en Go tellement il y a de choses que je n'aime pas, notamment dans la syntaxe. Il y a cependant de bonnes idées dont, à mon sens, les interfaces.

  • # Interface graphique

    Posté par . Évalué à  4 .

    Est-ce qu'il y a un genre de toolkit graphique livré avec (genre awt ou swing avec Java) ?
    Et si non (parce que j'en ai pas trouvé sur leur site) ça peut utiliser quoi d'existant (GTK ? Qt ? genre).

    • [^] # Re: Interface graphique

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

      D'après http://go-lang.cat-v.org/library-bindings :

      • go-gtk - Bindings for GTK. By Yasuhiro Matsumoto (aka mattn).
      • wxGo - SWIG-based wrapper for the wxWidgets toolkit. By Jeroen Dirks.
      • go-webkit - A webkit widget for go-gtk. By Yasuhiro Matsumoto (aka mattn).
      • x-go-binding Port of XCB to generate Go bindings for X11 Window System protocol. Originally by Tor Andersson (when the project was known as 'xgb'), now maintained by the Go core team at Google.
      • goosurface - An interface to Cairo via GTK by LisbonAcid.
      • termbox - A minimalist alternative to ncurses to build terminal-based user interfaces. By nsf.
      • go-fltk - Simple bindings for the FLTK2 GUI toolkit. By Bill Burdick.
      • go-iup - Bindings for the IUP cross-platform widget toolkiet. By Jeremy Cowgar.
  • # Quel avenir?

    Posté par . Évalué à  3 . Dernière modification : le 29/03/12 à 17:46

    mais je crois que je ne coderai jamais en Go tellement il y a de choses que je n'aime pas, notamment dans la syntaxe.

    Moi c'est exactement l'inverse, il y a pas mal de chose que j'aime, notamment au niveau de la syntaxe.

    Enfin un descendant de C qui se départit des maladresses de son aïeul, notamment la notation des types "à l'envers" qui a introduit tout un tas d’ambiguïtés dès que les types se sont un peu compliqués. L'omission des parenthèses pour les if et consorts clarifie aussi le code, même s'il demande un petit temps d'adaptation.

    En fait, la seule chose qui me retient de coder en Go, c'est que j'ai beaucoup de mal à croire en son avenir… Peut-être trouvera-t-il sa place dans quelques domaines, mais je le vois mal remplacer C comme langage bas niveau universel.

    • [^] # Re: Quel avenir?

      Posté par . Évalué à  1 .

      C'est quoi que tu appelles la notation des types à l'envers ?

      • [^] # Re: Quel avenir?

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

        Comme ça

        ʇuı
        
        

        « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: Quel avenir?

        Posté par . Évalué à  5 .

        a_type a_variable; au lieu de a_variable: A_TYPE

      • [^] # Re: Quel avenir?

        Posté par (page perso) . Évalué à  7 . Dernière modification : le 29/03/12 à 18:31

        J'imagine que c'est le fait de déclarer le type avant la variable (int x) alors que dans Go c'est l'inverse (x int). Ce qui apparemment peut avoir des intérêts quand c'est des types compliqués : http://golang.org/doc/articles/gos_declaration_syntax.html

        Même si bon, après avoir fait du C ou d'autres langages qui s'en sont plus ou moins inspirées pour la syntaxe, perso c'est plutôt en lisant les exemples de Go que je me suis dit «ah tiens, c'est à l'envers» :) La force de l'habitude…

        (Edit : [:grillai])

        • [^] # Re: Quel avenir?

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

          Ou un retour aux sources pour ceux qui ont appris à programmer à la fac avec Pascal.

          Je me souviens que les pointeurs en Pascal ne me posaient aucun problème, ce qui n'a pas été le cas quand on a ensuite vu le C.

        • [^] # Re: Quel avenir?

          Posté par . Évalué à  4 . Dernière modification : le 29/03/12 à 19:49

          Oui, c'est bien de la position du type par rapport à la variable dont je parle.

          Il est clair qu'on a (presque) tous l'habitude de lire les types C, mais qui n'a jamais froncé les sourcils devant un mélange de pointeurs/références savamment imbriqués à l'aide de parenthèses? Les pointeurs de fonctions, notamment, sont la plupart du temps complexes à lire.

    • [^] # Re: Quel avenir?

      Posté par . Évalué à  7 .

      Bon, puisque tu insistes, voilà tout ce qui ne me plaît pas dans la syntaxe (http://golang.org/ref/spec) :

      • la présence optionnelle des ; : c'est con, soit on les rend obligatoire, soit on les enlève complètement, là on est le cul entre deux chaises
      • les identifiants unicode : sur quel clavier peut-on facilement taper α (à part un clavier grec) ? Aucun, du coup, ça rend plus difficile la mise en commun de code
      • les tailles de tableaux situés avant le type et non après : ça rend extrêmement désagréable la lecture, je trouve
      • la notation inversé des déclarations : vu l'archi-prédominance des langages qui utilise la convention inverse, c'est suicidaire
      • la précédence complètement délirante des opérateurs : elle implique d'ajouter des parenthèses supplémentaires par rapport à un code C (et tous ses dérivés qui utilisent la même convention)
      • l'absence de parenthèse pour les if, for, etc : je préfère mettre une seule parenthèse autour de l'expression plutôt qu'à l'intérieur à cause d'une précédence débile…
      • les goto : ça met Go au niveau de PHP, qui a également introduit goto alors qu'il est parfaitement inutile et serait avantageusement remplacé par des structures adéquates pour les très rares cas où goto a une utilité (traitement d'erreur, chemin complexe).

      et ça, c'est juste pour la syntaxe…

      Après, je dis pas, C et ses suivants ne sont pas parfait, très loin de là, mais avec Go, pour moi, on a une régression.

      • [^] # Re: Quel avenir?

        Posté par . Évalué à  2 . Dernière modification : le 29/03/12 à 20:56

        En ce qui concerne les goto, ils ont toujours été présents dans le C, et le sont encore. Et comme tu le dis, ils ont leur utilité.

      • [^] # Re: Quel avenir?

        Posté par . Évalué à  1 .

        les goto : ça met Go au niveau de PHP, qui a également introduit goto alors qu'il est parfaitement inutile et serait avantageusement remplacé par des structures adéquates pour les très rares cas où goto a une utilité (traitement d'erreur, chemin complexe).

        Ya des goto dans PHP dis-donc… Je pratique PHP depuis plusieurs années, je ne les ai jamais utilisés ! Je croyais que ça n'existait que dans les langages de la famille BASIC.

        Je comprends que goto puisse avoir une utilité dans certains (très rares) cas. Mais pour le traitement d'erreur il y a les exceptions (try, catch), c'est plus propre.

        les identifiants unicode : sur quel clavier peut-on facilement taper α (à part un clavier grec) ? Aucun, du coup, ça rend plus difficile la mise en commun de code

        C'est marrant, l'autre jour je me demandais si un langage de programmation qui aurait des caractères unicode (genre flèches et symbole mathématiques) pour les opérateurs aurait une quelconque utilité… Ok, pas facile à saisir mais ça ferait un code visuellement attrayant.

        • [^] # Re: Quel avenir?

          Posté par . Évalué à  2 .

          C'est marrant, l'autre jour je me demandais si un langage de programmation qui aurait des caractères unicode (genre flèches et symbole mathématiques)

          Généralement seul un sous-ensemble de unicode est accepté (par exemple les lettres mais pas les symboles).

        • [^] # Re: Quel avenir?

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

          C'est marrant, l'autre jour je me demandais si un langage de programmation qui aurait des caractères unicode (genre flèches et symbole mathématiques) pour les opérateurs aurait une quelconque utilité… Ok, pas facile à saisir mais ça ferait un code visuellement attrayant.

          Genre APL, un vrai langage d'homme.

      • [^] # Re: Quel avenir?

        Posté par . Évalué à  2 .

        Je suis d'accord en ce qui concerne les tableaux et les identifiants unicode, ce ne sont pas des choix très heureux.

        Par contre, pour avoir codé un peu en Lua, je suis fan de l'absence de parenthèses dans les if, et de l'absence de point virgule en fin de ligne. Ça rend le code beaucoup moins chargé, on peut se concentrer sur l'essentiel plutôt que d'avoir à filtrer mentalement tous les caractères superflus.

        Je ne vois pas du tout quel est le problème avec la précédence tes opérateurs? Elle me semble parfaitement saine et classique:

            5             *  /  %  <<  >>  &  &^
            4             +  -  |  ^
            3             ==  !=  <  <=  >  >=
            2             &&
            1             ||
        
        

        Après, je n'ai pas essayé de coder en Go, peut-être ai-je loupé quelque chose?

        • [^] # Re: Quel avenir?

          Posté par . Évalué à  3 .

          Un petit exemple :

          1 + 2 | 3
          // vaut (1 + 2) | 3 en C et en Go
          
          

          n'est pas égal en Go (mais égal en C) à

          3 | 2 + 1
          // vaut 3 | (2 + 1) en C
          // vaut (3 | 2) + 1 en Go
          
          

          parce qu'en C, | et + ont une précédence différente en C, alors qu'en Go, c'est la même. Que + et - ait une précédence identique, ça se comprend tout à fait. Mais là, c'est mis au même niveau que d'autres opérateurs qui n'ont strictement rien à voir et qui ne devrait pas avoir la même précédence.

          • [^] # Re: Quel avenir?

            Posté par . Évalué à  10 .

            Personnellement je déteste ces précédences stupides (je parle du C ET de Go): les seules précédences qui ont un sens c'est celle qu'on a appris en math (+ - * /),
            le reste ça devrait échouer a la compilation pour forcer a mettre des parenthèses!

            3 | 2 + 1 --> erreur de compilation: le programmeur doit mettre '(3 | 2) + 1' ou '3 | (2 + 1)'.

            • [^] # Re: Quel avenir?

              Posté par . Évalué à  4 .

              En logique (qui est une branche des maths) il y a aussi des opérateurs, et ils ont aussi une précédence, qui est la même qu'en C et en Go pour le ET et le OU par exemple, si on les considèrent comme && et ||.

              • [^] # Re: Quel avenir?

                Posté par . Évalué à  0 .

                Oui mais on parle ici de précédence entre des opérateurs logiques et des opérateurs arithmétiques. Autant mettre de parenthèses ça évite de retenir des règles pas vraiment utiles et souvent différentes entre les langages.

            • [^] # Re: Quel avenir?

              Posté par . Évalué à  8 .

              Je te suis complètement la dessus. Je mets toujours les parenthèses même quand elles pourraient être absentes. Du code c'est fait pour être lu et pour être facile à débugger. C'est tellement plus rapide de comprendre une ligne quand le découpage est déjà fait, et ça évite les bugs cons en forçant le développeur à expliciter ce qu'il a en tête.

              Bref c'est pas par ce qu'on peut s'en passer qu'il faut s'en passer. Du coup les règles de précédence on s'en tape un peu non ?

              • [^] # Re: Quel avenir?

                Posté par . Évalué à  2 .

                Du coup les règles de précédence on s'en tape un peu non ?

                Si tous le monde respectait ces règles oui..
                Mais alors dans ce cas pourquoi ne pas avoir un langage qui force a respecter ces regles?

            • [^] # Re: Quel avenir?

              Posté par . Évalué à  3 .

              Sauf que tu oublies une précédence que tu utilises sans t'en rendre compte, celle de l'affectation =, car oui, = est un opérateur en C et dans la plupart de ses descendants, avec une précédence qui lui permet d'être exécuté en dernier. Donc, si je suis ton raisonnement, on devrait par exemple écrire :

              a = (3 + 4)
              
              

              Mais personne ne le fait, parce que ça semble naturel à tout le monde que = est en haut de l'arbre d'expression. Donc, pour moi, c'est la même chose avec le reste, il y a des ordres naturels. Si par exemple j'écris l'expression suivante :

              2 + 3 * 4 < 10 && 3 >= 3 / 3 - 4 || 5 % 3 == 3
              
              

              Tout le monde va la parenthéser de la même manière, à savoir :

              (((2 + (3 * 4)) < 10) && ((3 >= (3 / 3) - 4) || ((5 % 3) == 3)))
              
              

              Et honnêtement, je préfère la première version à celle-ci. Surtout quand dans le même temps, certains font l'apologie de l'absence de parenthèses après le if.

              Le seul problème de précédence en C (connu depuis très longtemps) est la précédence de & et |, qui était utilisé pour && et || avant que ces derniers n'apparaissent dans le langage, et qui du coup, ont gardé leur précédence. Ce qui pose problème de nos jours parce qu'on aimerait écrire :

              a & mask == b
              
              

              Mais on ne peut pas, on est obligé de parenthéser l'expression à gauche du ==. Cette erreur n'a jamais été corrigée dans les langages qui descendent du C, comme Java ou PHP.

              • [^] # Re: Quel avenir?

                Posté par . Évalué à  4 .

                entre
                2 + 3 * 4 < 10 && 3 >= 3 / 3 - 4 || 5 % 3 == 3

                et
                (((2 + (3 * 4)) < 10) && ((3 >= (3 / 3) - 4) || ((5 % 3) == 3)))

                je préfère
                ((2 + 3 * 4) < 10) && ((3 >= (3 / 3 - 4)) || (5 % 3 == 3))

          • [^] # Re: Quel avenir?

            Posté par . Évalué à  5 .

            Le problème c'est que lorsqu'il y a des règles de précédences plus complexes que celles de Go, d'après mon expérience chaque programmeur en retient une partie différente, et relire le code d'autrui peut devenir problématique.

            Je me suis souvent retrouvé à rajouter des parenthèses que je savais inutiles dans mon code, parce que je savais que telle ou telle précédence n'est généralement pas connue (l’opérateur ternaire me vient à l'esprit, notamment).

            Si tu connais par cœur l'ensemble des règles de précédence de C, alors crois-moi, tu es une exception. Je préfère de très loin avoir des règles moins fournies mais faciles à retenir.

        • [^] # Re: Quel avenir?

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

          Les identifiants unicode ça ouvre un tout nouveau monde d'obfuscation de code. On va pouvoir faire le "International Go Obfuscated Code Contest".

      • [^] # Re: Quel avenir?

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

        la présence optionnelle des ; : c'est con, soit on les rend obligatoire, soit on les enlève complètement, là on est le cul entre deux chaises

        Pour moi, l'intérêt de l'optionnalité c'est de ne pas les utliser normalement mais de pouvoir quand même mettre plusieurs instructions sur une ligne (ce n'est pas toujours utile mais parfois ça présent mieux).

        « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: Quel avenir?

        Posté par . Évalué à  3 .

        la présence optionnelle des ; : c'est con, soit on les rend obligatoire, soit on les enlève complètement, là on est le cul entre deux chaises

        Même choix que Ruby, Lua, Python, CoffeeScript. À ton avis, pourquoi tous ces langages ont fait ce choix ?

        1. Tous les concepteurs de langage de la terre sont des abrutis
        2. Il y a une bonne raison derrière

        les tailles de tableaux situés avant le type et non après : ça rend extrêmement désagréable la lecture, je trouve

        Ça permet de clarifier grandement char *foo[3] (tableau de 3 char* ou pointeur sur un tableau de 3 char ?).

        • [^] # Re: Quel avenir?

          Posté par . Évalué à  2 .

          Même choix que Ruby, Lua, Python, CoffeeScript. À ton avis, pourquoi tous ces langages ont fait ce choix ?

          1. Tous les concepteurs de langage de la terre sont des abrutis
          2. Il y a une bonne raison derrière

          Il y a des goto en C, PHP, Go, etc, ce n'est pas pour ça que l'idée est brillante hein.

          Je ne dis pas que ce sont des abrutis, je comprend parfaitement la raison, mais, pour moi, c'est une erreur, ça complexifie le langage inutilement. Et d'ailleurs, dans la spec de Go, ils précisent bien qu'aucun exemple dans la spec n'utilisera de ;, que c'est plus "idiomatique", autre manière de dire que normalement, ça sert à rien. Donc ça ne sert à rien mais on le met quand même…

          • [^] # Re: Quel avenir?

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

            Donc ça ne sert à rien mais on le met quand même…

            Dans java, la convention, c'est les noms de classes débutant par une majuscule, tu ne trouveras aucun exemple dans la doc avec un nom de classe en minuscule. Donc, les noms de classes entièrement en majuscules ne servent à rien mais on les met quand même. Et ça ne choque pas plus que ça. Si quelqu'un veut coder avec des noms de variables débutants par une majuscules et des noms de classes débutant par une minuscule, c'est son problème, ce n'est pas au langage de l'en empêcher.

            « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

            • [^] # Re: Quel avenir?

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

              Mouais enfin c'est très différent : ce n'est qu'une convention qui n'a rien à voir avec la grammaire du langage, tout comme l'indentation du code. Je préfère la justification disant que ça permet tout de même d'écrire plusieurs instructions sur la même ligne si on en a envie.

      • [^] # Re: Quel avenir?

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

        c'est vrai qu'un truc comme ça :

        *[4]int
        
        

        ça fait super envie :D

        • [^] # Re: Quel avenir?

          Posté par . Évalué à  8 .

          C'est moche mais ça se lit très bien: un pointeur vers un tableau de 4 entiers.
          Beaucoup plus simple a comprendre que la version en C!

          • [^] # Re: Quel avenir?

            Posté par . Évalué à  1 .

            En français oui, on lit dans cet ordre, "pointeur vers un tableau de 4 entiers". Il n'y aurait pas d'autres langues où ça se lirait à l'envers ? (un peu comme le possessif "'s" en anglais qui est à l'inverse du français)

            • [^] # Re: Quel avenir?

              Posté par . Évalué à  2 .

              Le possessif n'est pas obligatoire en Anglais: a pointer to an array of 4 int.

              Il y a probablement des langues où ce n'est pas le bon ordre, mais l'Anglais est la langue de l'informatique..

        • [^] # Re: Quel avenir?

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

          Faudrait moinsser aussi le commentaire qui répond à mon commentaire, sinon c'est pas crédible et on ne comprend plus rien.
          Ceci dit avec deux commentaires moinsés sur 2, on dirait que le fait que je n'aime pas trop Go soit mal vu… Ca doit être parce que c'est vendredi ;)

    • [^] # Re: Quel avenir?

      Posté par . Évalué à  1 .

      Enfin un descendant de C qui se départit des maladresses de son aïeul,

      Bof, tu ne peux toujours pas supposer que 'x Pas terrible pour un "descendant de C qui se départit des maladresses de son aïeul".

      • [^] # Deuxième essai

        Posté par . Évalué à  2 .

        Enfin un descendant de C qui se départit des maladresses de son aïeul,

        Bof, tu ne peux toujours pas supposer que x est inférieur à x + 1 est vrai, ni que abs(x) retourne un entier positif (enfin je pense, je n'ai pas trouvé la version pour un entier).
        Pas terrible pour un "descendant de C qui se départit des maladresses de son aïeul"!

  • # GIR

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

    Y'a-t-il une initiative pour utiliser GIR dans Go ? Ça ouvrirait beaucoup de possibilités !!

  • # En même temps...

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

    C'est sûr que côté avenir, à en croire les deux index, Tiobe et lang-index que je consulte régulièrement, ça va être tranquille.
    Bon, on pourra me dire que c'est comme les sondages en période électorale, ça vaut pas grand chose :)

Suivre le flux des commentaires

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