Le 10 Octobre 2016 a eu lieu la 3ème édition de DotGo au théâtre de Paris. Au menu : des speakers prestigieux, des conférences variées, etc. le tout dans un cadre très agréable.
Nous y étions ! Et voici pour vous des morceaux choisis.
First class function
La journée a commencé avec Dave Cheney et une conférence sur les fonctions en tant que first class citizen. Bien que cette conférence ait été basée sur un article de blog de Rob Pike de 2014 et qu’elle n’abordait pas un sujet nouveau ni très pointu, elle fut quand même très intéressante et particulièrement bien menée. De plus, elle a le mérite d’essayer de promouvoir des idiomes de Go qui semblent assez peu utilisés. En effet, les fonctions first class citizen sont assez souvent oubliées par les développeurs Go, alors qu’elles peuvent réduire drastiquement la quantité de code et le rendre plus lisible.
Dave nous a aussi montré un autre usage pour ces fonctions. Associées aux Channels, elles peuvent éviter d’avoir à analyser une structure pour déterminer un comportement au niveau du consommateur. Le comportement à exécuter est alors choisi par le producteur et ‘encapsulé’ dans cette fonction. Le consommateur, n’ayant plus qu’à exécuter des fonctions sans connaitre les détails d’implémentation, est alors très largement simplifié.
Enfin, la session s’est achevée par un appel à la prudence. En effet, bien que très intéressantes, les fonctions first class citizen ne sont pas la réponse ultime à la vie, la mort, l’univers et tout le reste, et doivent être utilisées à bon escient.
Slice, performance and cache
La journée s’est ensuite poursuivie avec Damian Gryski qui nous a parlé des Slices, de performance et de cache CPU. Partant du constat que les caches entre le processeur et la RAM se sont multipliés aux cours des années et qu’ils peuvent être jusqu’à 200 fois plus rapides en lecture, Damian nous a proposé d’essayer d’en tirer partie. Nous avons notamment vu comment des algorithmes théoriquement plus rapides que d’autres, sont en pratique plus lents, car moins propices à une utilisation intensive des cache L1 et L2. Trois points ressortent pour optimiser notre utilisation des caches. Tout d’abord, mesurer et compter les caches misses à l’aide d’outils comme perf et kcachegrind. Ensuite, il faut garder en mémoire que le minimum de données nécessaires. Que ce soit pour les slices (par exemple, passer d’un slice de int64 à un slice de int32) ou pour les structs (en enlevant les champs inutilisés). De cette façon, plus de données pourront rester en cache. Enfin, il faut privilégier des accès mémoire prédictives. Par exemple, itérer sur un tableau de façon linéaire est prédictif, tandis que le parcours d’une liste chaînée ne l’est pas.
Damian a conclu ensuite en expliquant que les machines et les compilateurs modernes sont très bons pour exécuter des algorithmes simples et bêtes. Ces algorithmes tendent à être assez légers et à utiliser des patterns d’accès prédictif. Pour aller plus loin…
GopherJS
C’est au tour de Dmitri Shuralyov de nous parler du projet GopherJS dont il est contributeur. L’idée est d’écrire des applications front – end en Go et de les compiler en Javascript. C’est un projet ambitieux avec encore beaucoup de challenges.
Immutability in Go, Post mortem from a Dos-ed blockchain
Péter Szilágyi a commencé par une petite introduction à blockchain et Ethereum, l’un des systèmes de blockchain plus complexe en production, puis il est entré dans le vif du sujet. En effet, Ethereum a subi une attaque DDOS en septembre dernier, et Péter se propose de nous faire un retour d’expérience sur l’une des principales mesures prises suite à cet incident : ne plus utiliser de structure mutable dans la blockchain.
L’immutabilité en Go ne va pas de soit même si elle est tout à fait possible, Péter nous a présenté quelques pistes à suivre. Tout d’abord éviter les slices car ceux-ci sont mutables : les échanger entre Goroutines au travers de channels risque de mettre à mal l’immutabilité que vous recherchez. L’utilisation des strings en lieu et place des slices résoudra le problème, les strings étant immutables. Le deuxième point porte sur la nécessité de rendre les champs de votre structure inaccessibles et d’utiliser des mécanismes de « deep copy » lors de l’initialisation de votre structure.
La conclusion est que l’immutabilité est difficile en Go, et sa mise en place peut avoir des impacts sur les performances, notamment au niveau du garbage collector. Cependant, dans le cas de Ethereum, les avantages comme les accès concurrents « lock-free », le partage de mémoire à travers la composition, et un raisonnement plus simple par rapport à la complexité de l’application l’emportent sur ces inconvénients.
Est ensuite venu le temps de la pause repas et du selfie avec le seigneur des lieux, maître Gopher !
La suite du résumé de la conférence est à suivre dans le prochain article…
Et ne manquez pas le hands-on GO lors de la XebiCon !