Je relate dans ce billet quelques eléments clefs provenant d’une conférence de Stéphane Bortzmeyer organisée par Parinux. Je dois dire que j’étais très enthousiaste à en savoir plus sur ce langage apparu en Novembre 2009* ; pourquoi un nouveau langage ? qu’a-t-il de spécial ? L’exposé a répondu à toutes mes questions, et je l’ai d’ailleurs trouvé fort intéressant et pédagogique, c’est pourquoi j’ai cru bon d’en écrire quelque chose, même si les transparents sont disponibles sur le site de l’auteur.

Let’s go ! (un avantage avec ce langage, c’est que c’est facile )

Pourquoi créer un nouveau langage ?

Dans le créneau de Go, que nous allons préciser dans quelques instants, il existe relativement peu de langages concurrents. Nous verrons aussi que les auteurs ont le soucis de rendre vivable l’écriture du code, là où chez d’autres, c’est tout de suite lourd et complexe à mettre en oeuvre.

Vous savez sans doute que de nombreux langages voient le jour, ne serait-ce que pour la recherche mais aussi parce que certains se lancent des défis personnels. Un bon nombre n’arrive pas à maturité, mais go est sans doute déjà un succès. Bien sûr, il y a google, mais au final celui-ci ne l’utilise pas ! Ce n’est donc pas le langage de google, mais google facilite son émergence. Il faut dire que les auteurs ne sont pas non plus n’importe qui : Robert Griesemer, Rob Pike, Ken Thompson, Ian Taylor.

Quel est le créneau de Go ?

La vocation de Go est la programmation système et réseau. il se doit donc d’avoir la capacité « à parler » bas niveau (c’est à dire, autre chose que perl ou python ). Les langages qui existent pour cela sont le C bien évidemment. Le noyau linux en est la preuve. le C++ est aussi utilisé, mais dans une moindre mesure, et le D qui se veut être le successeur du C, mais sans véritable succès

Il est important de noter que le langage Go évolue encore beaucoup. Il n’y a d’ailleurs pas de version de Go actuellement, autre que celle du gestionnaire de version. Il se peut donc que le code qui compilait hier, ne compile plus avec le compilateur téléchargé ce matin, mais ce langage s’avère pour autant être très stable. De nombreuses bibliothèques font leur apparition (ce qui est aussi un critère clef…). On peut donc se demander légitimement pourquoi il n’y a pas une 1.0, où même une 0.1. Cela tient du fait que les auteurs souhaitent avoir un langage le plus abouti possible, en évitant au maximum des écueils qui rendent d’autres langages invivables. Il y a donc une recherche d’un retour développeur maximum. Ceux-ci ont permis d’affiner certaines marques de fabrique du langage que je vais rapidement commenter.

La marque de fabrique de Go

Mon but ici, n’est pas de recopier les bouts de codes des transparents, je vais juste donner des images simplistes. Je vous renvoie sur le blog de Stéphane Bortzmeyer et la documentation pour plus de détails.

Parallélisme

Paralléliser un code, c’est être capable de faire plusieurs tâches en même temps. Les machines actuelles ayant plusieurs coeurs, c’est très avantageux. Pour ceux qui ont essayé la bibliothèque pthread.h en C, vous savez comment on appréhende (enfin, moi en tout cas). Pour ceux qui utilise un peut la console, c’est comme lorsque vous placez un & à la fin de votre commande, elle vie à sa vie, et d’autres commandes peuvent être exécutées. Ici, c’est à peut près ça, à peu près car on souhaitera dialoguer avec les tâches.

Go a simplifié grandement le parallélisme par ce qu’ils appellent les goroutines. Schématiquement, si un appel de fonction classique se fait comme :

fonction();

la parallélisation se fait par :

go fonction();

La gestion d’accès à la mémoire ne se fait pas à l’aide de mutex, mais à l’aide de canaux typés.

Programmation orientée objet

Le paradigme de la programmation orientée objet (POO) a pour philosophie de mettre en avant les objets physiques que l’on manipule dans un programme. Ces objets ont des relations les uns avec les autres et peuvent communiquer. Ces vingts dernières années ont été dominées par l’apparition de langages orientées objets mais ce n’est pas le cas de Go ! C’est un fait très marquant qui nécessite d’être souligné.

Ce que permet de contourner la POO est la soucis de la redondance des noms de fonctions qui peuvent être gênant en C par ex. En effet, si en C, vous importez stdio.h et monio.h et que le deux comportent la fonction printf(), les soucis commencent. Go possède le même soucis alors ? Non. Il existe un mécanisme de typage des fonctions. un appel se fera lors comme ceci :

toto := MonPaquet.fonction(*variable);

A noter : une fonction en go peut renvoyer plusieurs variables, utiles pour les erreurs :

toto, erreur := MonPaquet.fonction(*variable);

Typage des variables

Les variables sont typées en Go (on distingue un entier d’une chaine de caractères par ex), mais contrairement au C, il n’est pas nécessaire de les déclarer avant de les utiliser. Dans l’exemple ci-dessus, il n’était pas nécessaire d’écrire

Type toto;

car go le déterminera par rapport à ce qui lui est affecté lors de son apparition.

Pas d’exception, mais…

Go ne prévoit pas d’apporter la possibilité d’avoir des exceptions. Les auteurs semblent être farouchement opposés, simplement parce qu’il est parfois utilisé à mauvais escient. Cependant, un mécanisme « panic/recover » vient de faire son apparition… il y a une semaine et demie… Celui-ci devrait permettre de faire tout ce que l’on peut faire avec les exceptions mais uniquement dans les cas justifiés.

Gestion de la mémoire

Deux philosophies s’opposent dans ce domaine. Soit sa gestion est laissée au développeur (C par ex), soit elle est laissée à la machine (Java). Chacune ont leurs avantages ou inconvénients, l’humain n’est pas infaillible, mais de l’autre coté, ça prend du temps machine. Go a choisi la seconde solution, c’est à dire à l’existence d’un ramasse-miette (ou garbage collector)

Tableaux

Les tableaux ne sont pas auto-extensibles comme le sont ceux de perl ou python : ça aurait été agréable, mais peut performant. Contrairement au C, les tableaux de Go embarque la dimension de celui-ci. Un bon avantage. Il est en outre possible de passer à une fonction une vue d’un tableau, c’est à dire un extrait (contigüe) d’un tableau, mais ce n’est pas une copie, c’est à dire que le tableau complet sera modifié in fine.

Conclusion

A titre purement personnel, je ne suis pas prêt de m’y mettre. Déjà que je dois en apprendre plus sur les langages stables… Clairement, ce n’est pas pour moi avant sans doute plusieurs années (quand ce langage sera-t-il carré ? personne ne le sait). Mais j’ai trouvé cette présentation fort enrichissante. Il est très intéressant de voir un langage se construire et de voir aussi la réponse qui peut être donnée aux lourdeurs que l’on a pu rencontrer dès lors que l’on a déjà codé quelques lignes de C et/ou de C++ et que l’on connait certains langages « reposant » comme perl ou python. J’espère que vous avez pris autant de plaisir que moi