GopherCon Denver : Retour sur la conference Go

Les 12,13,14 et 15 Juillet, a eu lieu Gophercon à Denver (Colorado, USA). La conférence la plus importante sur le langage Go.

• La séance du 12 a été dédiée aux ateliers.
• Les séances du 13 et 14 ont été dédiées aux conférences.
• Le 15 (Community Day), était l’occasion pour la communauté Go de s’exprimer au travers de lightning talks, de tables rondes et de groupes de travail sur des projets spécifiques (par exemple dep, kops, le langage Go etc). Un espace était réservé pour des communautés spécifiques comme gopherdata (tensorflow, gonum, machinebox, pachyderm) ou gobot afin de faire connaitre leurs avancées ou laisser les participants programmer des « bots » ou « drones » en utilisant des outils Go. À la fin du dernier jour, il y a eu une table ronde sur la diversité dans la communauté Go.

J’ai eu l’opportunité d’y aller. Et en plus d’une communauté très inclusive et ouverte, j’ai trouvé des conférences de qualité, des projets en croissance et des personnes de tous horizons, ouvertes et bienveillantes.

Dans cet article je vous propose un aperçu de ce que vous avez pu manquer (ou pas, si vous avez eu la chance d’y participer) durant les deux jours de conférences. Il pourra également vous servir de grille de lecture des quelques talks, dont l’information se trouve ici et les videos ici.

Premier jour de conférences

Go Reliability and Durability at Dropbox

Tammy Butow, développeuse d’infrastructure chez Dropbox, a ouvert les sessions avec un retour d’expérience de l’utilisation du Go chez Dropbox.
 

Elle a raconté qu’ils ont commencé à utiliser le langage pour ses promesses de simplicité et de performance. Ils ont conçu et développé plusieurs systèmes avec Go et ont obtenu de très bon résultats avec l’intégration de plusieurs équipes. La courbe d’apprentissage des nouveaux développeurs a été relativement basse, mais ils ont encore quelques problèmes de « race conditions » dans la gestion des données, qui reste encore très difficile à gérer.

Tammy a expliqué qu’ils ont une méthodologie de « chaos engineering » qui consiste à introduire des erreurs sur des noeuds de l’application distribuée. Cette pratique nous rappelle celle utilisée par Netflix avec Simian Army.

The Future of Go

Dans ce talk Russ Cox a lancé la conception de Go 2.0. Il a décrit pourquoi passer à Go 2. L’idée n’est pas d’abandonner Go 1.X sinon de commencer la conception et la construction de cette nouvelle version parallèlement afin de résoudre les problèmes de mise à l’échelle. L’idée est de respecter la promesse de compatibilité de Go et de ne pas fragmenter l’écosystème.

Ensuite, il a confirmé que le cycle de releases de Go ne changera pas.

Finalement, il a formalisé une méthodologie pour l’intégration des fonctionnalités sur Go. Il s’agit de la manière dont la communauté travaille aujourd’hui :
1. Accumuler de l’expérience sur Go au travers de son utilisation
2. Identifier et expliquer un problème
3. Proposer une solution
4. Implémenter, évaluer et affiner la solution
5. Déployer la solution en prod.

Il n’est pas nécessaire qu’une seule personne fasse toutes les étapes.

Les conversations pour Go 2.0 ont commencé à ce moment-là. Il faut commencer à rédiger des rapports d’expériences et à imaginer les nouvelles fonctionnalités de Go 2.0

A Go Programmer’s Guide to Syscalls

Cette fois, Liz Rice nous a aidé à comprendre les appels système (syscalls). Elle a développé en direct un outil strace (un outil de traçage d’appels système) en Go et nous l’avons testé avec un simple « hello world ». 

Valuable Lessons in Over-Engineering the Core of Kubernetes kops

Kris Nova nous a appris une leçon très utile : il faut savoir rester simple. Dans le développement de l’outil kops (kubernetes), son équipe a investi beaucoup de temps en essayant de construire un interpréteur de yaml, qui est devenu un langage en soit très difficile à maintenir, tester et peu pratique pour les utilisateurs (il était très facile d’introduire des bugs dans la construction du cluster). C’est pour ça, qu’ils ont pris la décision d’abandonner ce « nouveau langage » et de se focaliser sur une API qui permet aux utilisateurs de kops de développer leur cluster en utilisant Go.

Go Anti-Patterns

Il y a eu aussi l’espace pour le craft en Go. Edward Muller nous a rappelé certaines mauvaises pratiques ou « bad smells » très communes, dont :

• Le syndrome du tiny package
• Premature exportation ou l’exposition des structures niveau package
• Le mauvais nommage de package et la creation d’un package « utils » à défaut d’une meilleure idée de nommage
• Créer des structures pour stocker les options ou les configurations
• L’excès des pointeurs
• Les if-then-else au lieu des « happy-paths »
• L’utilisation d’un interface {}, etc.

Deuxième jour de conférences

Understanding Channels

Dans la première keynote du deuxième jour, Kavya Joshi nous a appris l’implémentation des go-channels. Nous avons commencé par examiner comment il y a eu un compromis entre simplicité et performance, où la simplicité a été sacrifiée et la performance est assurée pour le runtime scheduler qui permet aux threads du système d’exploitation, de rester « unblocked » et d’optimiser l’utilisation de mémoire.

My Journey to Go

Ashley Macnamara nous a émues aux larmes avec cette deuxième keynote, où elle nous a raconté comme elle est devenue développeusse Go et développeur évangéliste, après une carrière dans la photographie.
Un exemple à suivre pour toutes les personnes qui veulent devenir développeurs ou qui sont en reconversion dans l’informatique. Elle nous a également rappelé qu’il n’est pas nécessaire d’être Rob Pike, Dave Cheney ou Jessie Frazelle pour contribuer à Go.

Advanced Testing with Go

Michell Hachimoto nous a présenté de bonnes pratiques pour tester nos développements Go, sur les niveaux d’une méthodologie de tests et des manières d’écrire un code plus stable.

Parmi les pratiques abordées il a mentionné :

• Tests unitaires pilotés par des données
• La creation des « Tests Helpers » afin d’encapsuler la gestion d’erreurs et le code de référence
• L’execution des tests des sub-processus en condition réel et au travers de « Mocks »

The Fallacies Of Distributed Computing

Michael Hausenblas nous a parlé des « 8 fallacies » (idées fausses) décrites par Peter Deutsch et comment les aborder sur nos projets Go.

• Le réseau est fiable
• Le temps de latence est nul
• La bande passante est infinie
• Le réseau est sûr
• La topologie du réseau ne change pas
• Il y a un et un seul administrateur réseaux
• Le coût de transport est nul
• Le réseau est homogène.

The New Era of Go Package Management

Finalement, Sam Boyer nous a parlé d’un nouvel outil pour la gestion de dépendances de Go : dep. Cette outil  est pensé pour devenir le nouveau standard Go.

Conclusion

Cette expérience a été très enrichissante. C’était une édition riche tant en qualité des talks qu’en variété des sujets, projets et activités.

En attendant la prochaine édition, nous pouvons continuer à contribuer aux projets open source et à aider concevoir la prochaine version de Go!