Il y a une quinzaine de jours, j’ai eu le privilège d’assister à dotGo 2019, la cinquième édition de la conférence Go européenne. Tandis que la plupart des conférences tech auxquelles j’ai assisté avaient lieu dans des hôtels ou des palais des congrès sans âme, l’équipe dotGo s’est démenée pour que la conférence ait lieu dans le prestigieux Théâtre de Paris, rue Blanche. Les sponsors, qui comptaient Heetch, Microsoft, Datadog, Sourcegraph, et GitHub, y sont probablement pour beaucoup.
La légende qu’est Dave Cheney dans le monde de Go était le maître de cérémonie. Malgré sa courte durée (une seule journée, suivie d’une journée d’ateliers), la conférence regorgeait de talks. Voilà ce que j’en ai retenu. Je ne rentrerai pas trop dans les détails ; tout ce que je veux, c’est vous donner une idée de ce à quoi vous attendre de ces talks, qui devraient être en ligne prochainement sur dotconferences.com.
(Et pour ceux et celles que Go intrigue, notez qu’une formation Go adressée aux débutant.e.s est disponible chez Human Coders.)
Première session
Daniel Martí : des micro-benchmarks plus concluants
Daniel Martí a ouvert le bal avec une conf quelque peu technique. Bien que l’interface en ligne de commandes de Go permette aux programmeurs et programmeuses de lancer des micro-benchmarks sur les parties du code où la performance est de mise, les résultats obtenus peuvent être peu concluants à cause d’une variance trop élevée. En termes simples, un micro-benchmark peut paraître prometteur lors d’une exécution, pour ensuite décevoir lors de la suivante. Daniel a montré une série de nouvelles techniques visant à réduire le bruit et obtenir des réponses probantes de vos micro-benchmarks.
Kat Zién : domain-driven design et Go
Kat Zién a ensuite fait un talk sur un sujet cher à mon coeur d’aficionado de Domain-Driven Design : l’architecture hexagonale. On doit le terme à Alistair Cockburn, mais l’idée de base remonte à plus loin et continue d’être redécouverte sous d’autres noms, tels que “l’architecture en oignon”. L’architecture hexagonale consiste à structurer un système en séparant proprement l’implémentation du domaine métier des composants techniques (ex : la base de données) qui la supportent. L’objectif de cette méthode est d’obtenir un système dont la compréhension et la maintenance sont plus aisées.
La conf de Kat était intéressante, mais m’a laissé un peu sur ma faim : j’aurais aimé qu’elle soit plus spécifique et explique comment elle applique ces principes à un système implémenté en Go. Marcus Olsson a d’ailleurs une bonne conf a ce sujet. Cela dit, les confs se devaient d’être courtes, donc je peux pardonner à Kat de ne pas être trop rentrée dans les détails. Je ne manquerai pas de regarder ses futures confs.
Ignat Korchagin : Go comme langage de script
Ignat Korchagin nous a averti à propos des obstacles qui se dressent face à qui veut utiliser Go comme langage de script. En particulier, la syntaxe de Go est incompatible avec la syntaxe en vigueur pour les shebangs, ce qui ne nous facilite pas la vie. Ignat nous a montré quelques astuces, mais aucune ne me satisfait complètement. Je pense que je vais me contenter de Python et shell pour écrire mes scripts jusqu’à nouvel ordre…
Michael McLoughlin : un plus près du métal
Michael McLoughlin nous a ensuite parlé de l’écriture de code assembleur (amd64, notamment) depuis Go. Quand le besoin de performance prime, Go peut ne pas être suffisant, auquel cas il convient d’écrire du code assembleur directement. Plusieurs routines de la bibliothèque standard de Go sont d’ailleurs écrites en assembleur. Cependant, écrire de l’assembleur est un exercice de haute voltige : pas de type checker pour vous aider à écrire un programme correct. D’autre part, la présence de bugs peut avoir des conséquences dramatiques ; imaginez un bug dans une routine crypto.
La solution proposée par Michael est avo, un outil qui vous permet d’écrire des programmes en Go pour générer du code assembleur. Les avantages de cette approche sont clairs : le code source en Go qui est passé en entrée à avo est plus compact, plus facile à tester, à comprendre, et à maintenir que du code assembleur nu, et pourtant la performance de ce code généré n’est pas en reste. Michael a illustré les avantages de son approche en montrant une implémentation d’une function de hachage SHA-1. Impressionnant.
Deuxième session
Lightning talks
Le public a ensuite eu le plaisir d’assister à une série de lightning talks prodigués par Olivier Wulveryck, Roberto Clapis, Natalie Pistunovich, Valentin Deleplace, et Joan López de la Franca Beltran. Pour moi, le meilleur du lot était celui de Valentin, qui s’est habilement appuyé sur une métaphore filée d’une piscine et de son public pour expliquer sa double implémentation d’un sémaphore. Pas mal pour fixer les idées.
Dave Cheney : l’importance d’être constant
Les confs normales ont ensuite repris avec celle de Dave Cheney. Sortant temporairement de son rôle de maître de cérémonie, Dave a choisi de se baser sur l’un de ses billets de 2016. La plupart des packages Go définissent des valeurs sentinelles d’erreurs en utilisant la function errors.New. Par exemple, les packages io et rsa définissent des valeurs struct appelées respectivement EOF et ErrVerification, que les utilisateurs et utilisatrices de ces packages peuvent employer dans des tests d’égalité afin de détecter si une erreur est survenue.
Idéalement, ces valeurs devraient être des constantes, mais, à cause de certaines limitations du langage, elles doivent être définies en tant que variables (var) et peuvent donc être écrasées par mégarde. Je vous laisse imaginer dans quelle mesure un tel risque peut porter atteinte à l’exactitude et la sécurité d’un programme.
Dave a ensuite révélé son astuce pour remédier au problème : définissez d’abord un type d’erreur basé sur le type string, que vous affublez d’une méthode Error se contentant de retourner la valeur de cette string ; ensuite, servez vous de ce type pour définir toutes vos valeurs sentinelles d’erreurs. En procédant de la sorte, rien ne vous empêche dorénavant de définir ces valeurs en tant que constantes. L’approche est intéressante, bien qu’elle ait peu de chances de devenir courante dans la bibliothèque standard.
Jean de Klerk : modules Go et repos Git
Jean de Klerk nous a ensuite présenté les leçons qu’il a retenu du groupement de plusieurs modules dans un seul repo. Il n’y a pas si longtemps, la gestion de dépendances en Go était difficile. Tout a changé (pour le meilleur) avec Go 1.11, qui a vu l’arrivée d’un système de modules en bonne et due forme, né du projet vgo. Ce système de modules reste expérimental, mais devrait être stable d’ici Go 1.13.
L’approche la plus sûre est d’avoir un seul module Go par repo Git. Dans certains cas, cependant, vous pouvez vouloir grouper plusieurs modules sous un même repo, ce qui doit être le cas chez Google, vu leur engouement pour les monorepos. Mais gare à vous ! Je vous laisse regarder la conf de Jean pour les détails, mais ma conclusion est la suivante : un module par repo.
Troisième session
Johann Brandhorst : WebAssembly depuis Go
Johann Brandhorst avait prévu une autre session de live coding pour nous, cette fois à propos de la production de WebAssembly depuis Go. J’avoue ne pas m’être encore assez penché sur le sujet du WebAssembly, donc je suis un peu passé à côté de la conf de Johann… Cependant, le public semblait enthousiaste, donc à surveiller.
Bryan Boreham : réglage du garbage collector
Bryan Boreham nous a ensuite convié a une conf sur le réglage du garbage collector de Go. Le GC de la JVM offre de multiples options et peut s’avérer compliqué à régler ; il existe des bouquins entiers dédiés à cette science occulte. Les Gophers ont la vie plus facile : une seule option, appelée GOGC, est disponible pour régler le garbage collector de Go ! Bryan admet tout de même que des options pour régler les tailles minimales et maximales du tas (heap) ne seraient pas de trop…
Entre parenthèses, cette conf m’a appris que, pour des programmes qui ne mettent pas trop de temps à s’exécuter et qui ne sont pas trop gourmands en mémoire, il peut être avantageux de complètement désactiver le GC (GOGC=off). Astucieux !
Ellen Körbes : non, ceci n’est pas un sex toy…
Ellen Körbes, qui—et c’est important—s’identifie comme non-binaire, a réalisé une session de live coding audacieuse détaillant comment concevoir votre propre dilatateur vaginal—je vous laisse chercher ça dans le dictionnaire, si nécessaire—en utilisant des outils Go de modélisation 3D. Nerd jusqu’à l’os, Ellen a même affublé l’extrémité du modèle d’une tête de Gopher. La classe !
Dernière session
James Bowes : les dangers de reflect et unsafe
James Bowes nous a ensuite interpelé.e.s sur le bien fondé de l’utilisation des packages reflect et unsafe par le commun des mortel·le·s. Le package reflect est utilisé à de nombreux endroits de la bibliothèque standard : quand vous tombez nez à nez avec une interface vide (interface{}) ou bien des tags de structs, il y a fort à parier que reflect n’est pas loin. Quant au package unsafe, il est utilisé par endroits quand contourner le système de type peut procurer des gains de performance avantageux.
Malgré tout, ces deux packages peuvent s’avérer dangereux dans les mains de novices—dont je fais partie. Le commandement de James est clair : en règle générale, n’utilisez pas unsafe et résistez la tentation d’utiliser reflect, notamment pour l’injection de dépendances à l’exécution.
Jess Frazelle : l’agence tous-RISC-V
Jess Frazelle est une idole de la communauté Go. Elle a une ravissante manie de jurer toutes les deux phrases, ce qui contribue à tenir le public en haleine. Elle nous a convié à une visite éclair de la ménagerie des jeux d’instructions x86. RISC-V est l’un de ces jeux d’instructions les plus en vogue, et Jess nous a entretenu de son travail sur un portage Go.
Marcel van Lohuizen : chaînage d’erreurs standard
Enfin, Marcel van Lohuizen nous a fait saliver avec des améliorations en approche dans la gestion d’erreurs en Go. Le chaînage d’erreurs, c’est à dire la pratique qui consiste à garder une référence à la cause d’une erreur au sein de celle-ci, est une fonctionnalité malheureusement absente du package errors de la bibliothèque standard de Go. Pour combler cette absence, la communauté s’est fragmentée en une infinité d’approches différentes pour chaîner les erreurs, toutes plus ou moins incompatibles entre elles. Trouver un moyen de standardiser le chaînage d’erreurs devenait de plus en plus pressant.
Pendant sa conf, Marcel a décrit dans quelles mesures l’API d’errors va s’étendre avec Go 2 pour pouvoir accueillir une façon standard de chaîner les erreurs. Les changements prévus rendent également possible la traduction des messages d’erreurs dans des langues autres que l’anglais. La nouvelle API est déjà disponible dans le package expérimental golang.org/x/exp/errors. Prometteur…
Epilogue
Après quelques pintes dans un pub (dont j’ai oublié le nom) à deux pas du Moulin Rouge, il était temps de récupérer.
D’autres compte-rendus de la conférence ont déjà fleuri sur le Web—celui-là, notamment—et je vous invite à les consulter pour une perspective différente de la mienne.
Merci encore à Human Coders, qui m’ont bien généreusement fait le don d’un ticket. L’équipe Dot a déjà annoncé que l’édition 2020 de dotGo se tiendrait au même endroit en mars prochain. Si elle est promet d’être aussi réussie que dotGo 2019, je tenterai tout pour y assister, et vous devriez faire de même !