Go, un outil ergonomique

Je suis globalement d’accord avec l’esprit général du billet, notamment sur l’expérience développeur en partie grâce au tooling bien unifié (comme d’autres langages de sa génération).

J’ajouterais aussi l’expérience "Ops" que Go apporte. La compilation statique et multi-plateforme out-of-the-box fait que les CI sont plutôt simples à mettre en place et que le déploiement sur un parc hétérogène (instances AMD64 et AArch64) est facilitée. La conteneurisation aussi est pas mal simplifiée, si je compare avec les images que je devais faire avec mes projets Python, et avec un startup time qui est généralement très bon, ce qui est utile pour certains workloads où des conteneurs doivent "roller" le plus rapidement possible (sur k8s ou ECS par exemple). Dans un contexte d’infrastructure dans le Cloud, Go est donc pour moi très ergonomique. Aujourd’hui, pour le type de projets sur lesquels je travaille, c’est limite l’aspect le plus important.

Il permet aussi de rendre accessible à tous le monde la lecture du code, même pour quelqu’un qui n’en a jamais vu. Cela permet aux développeurs de lire du code source facilement. Le code, qui peut-être très complexe, doit être résolu de manière simple (dû au langage simpliste). On peut être assuré que que tout le code que l’on verra sera simple. Ça permet aux développeurs novice de facilement mettre le nez sous le capot.

La lecture aisée du code écrit en Go est un point qui est souvent mis en avant. Je ne peux pas dire que je suis en désaccord fondamentalement, je vais moi-même souvent lire la stdlib pour savoir comment un élément fonctionne dans le détail et je suis souvent surpris de la fluidité de l’expérience.

Mais je me suis toujours demandé s’il n’y avait pas un biais : la population affirmant cela est sûrement déjà assez expérimentée, habituée à lire et relire du code écrit par d’autres.

Le langage étant tellement simple que tous les développeurs venant d’autres technologies (C, C++, C#, Java, Python, …) peuvent l’aborder rapidement et très vite s’amuser avec.

Avant le Go, Python a été mon langage principal en perso et en entreprise pendant des années. (Je ne peux pas me prononcer pour les gens ayant un background C, C++, C# ou Java.) Passer à Go m’a quand même un peu secoué. C’était pas difficile, mais il y avait quand même certaines notions à bien (re)voir pour ne pas écrire du Go n’importe comment. Pensons aux notions de passage par valeur et par référence (un problème qui ne se posait pas vraiment quand je faisais du Python) et le code concurrent qui n’était pas tout à fait similaire à ce que je faisais avec les coroutines asynchrones, même si les patterns de concurrence généraux se retrouvent parfois. Il y a aussi quelques gotchas bas-niveau qu’il vaut mieux connaître et comprendre !

Mais est-ce qu’à l’inverse ce n’est pas un frein pour des applications desktop de ne pas bénéficier des bibliothèques partagées sur le système et d’avoir à la place des gros programmes qui embarquent toutes leurs libs ?

Ne connaissant pas du tout le Go je suis allé jeter un œil à plusieurs fichiers source de la stdlib, et je pense que ça confirme l’idée du biais. J’arrive à comprendre le code parce que ça ressemble tout de même beaucoup au C (mêmes opérateurs, mêmes structures dans le code) mais je ne dirais pas que c’est facile à lire.

J’ajouterais aussi l’expérience "Ops" que Go apporte. La compilation statique et multi-plateforme out-of-the-box fait que les CI sont plutôt simples à mettre en place et que le déploiement sur un parc hétérogène (instances AMD64 et AArch64) est facilitée.

Mais est-ce qu’à l’inverse ce n’est pas un frein pour des applications desktop de ne pas bénéficier des bibliothèques partagées sur le système et d’avoir à la place des gros programmes qui embarquent toutes leurs libs ?

C’est bien possible, oui. Mais je t’avoue que je n’ai jamais travaillé sur des projets de ce type.

D’ailleurs, puisque tu abordes le sujet, Go c’est quand même un peu une île isolée du grand continent ; dès que tu as besoin de le lier à des lib qui viennent d’ailleurs avec cgo, tu perds quand même une petite partie de la convénience dont j’ai parlée, il faut bien l’admettre.

La lecture aisée du code écrit en Go est un point qui est souvent mis en avant. Je ne peux pas dire que je suis en désaccord fondamentalement, je vais moi-même souvent lire la stdlib pour savoir comment un élément fonctionne dans le détail et je suis souvent surpris de la fluidité de l’expérience.

Mais je me suis toujours demandé s’il n’y avait pas un biais : la population affirmant cela est sûrement déjà assez expérimentée, habituée à lire et relire du code écrit par d’autres.

À mes yeux, utiliser la stdlib pour jauger de la lisibilité du langage tombe un peu dans le même biais que les bancs de microbenchmarks pour comparer les perfs des langages : ça donne une information parcellaire qu’on ne peut pas vraiment généraliser.

Je pense que la facilité de lecture ne se mesure pas forcément en lisant la stdlib mais plutôt quand on rentre dans un gros projet dans la vraie vie. Et encore je pense que l’adjectif le plus adapté n’est pas "facile" mais "boring", "sans surprise".

Go est un de ces rares langages qui ne permettent pas de "golfer", contrairement à Python, par exemple, dont la facilité de lecture est légendaire au sens littéral, c’est-à-dire mythique, c’est-à-dire célèbre mais inventée de toute pièce et très largement exagérée.

Dès lors que l’on restreint l’expressivité du langage à un ensemble réduit de structures syntaxiques simples et bien connues de tout le monde, on ne peut plus surprendre, perdre, ni induire les lecteurs en erreur à grands coups de listes ou de générateurs en intension, de "async truc" ou "yield machin", de "clause finally dans une boucle for", de décorateurs magiques… ou encore d’itérateurs placés en chaîne comme en Rust.

Go est "boring", donc verbeux et explicite, ce qui, entre de bonnes mains, pousse les devs à adopter les bonnes pratiques (factoriser, isoler les éléments de code dans des fonctions que l’on se fait un devoir de nommer de façon claire, ce qui se ressent, par conséquent, sur la testabilité du code). Ce que cela encourage, c’est notamment à exprimer les règles métier d’un programme d’une façon qui n’a pas vraiment la possibilité d’être mal comprise ou mal maîtrisée.

Et ça, en effet, c’est hyper reposant.

Ça l’est aussi dans la mesure où il est très courant de générer du code Go : de tout temps le code généré a été notoirement célèbre pour être chiant à lire. En Go, ce n’est pas le cas : il est généré parce que quelqu’un, un jour, l’a trouvé chiant à écrire, mais d’expérience et sauf exceptions rares (genre abus de goto), il reste aussi lisible que le code produit par un humain, et donc "reviewable".

Après c’est comme partout, on peut aussi trouver du code mal foutu, mal découpé, mal pensé, ou difficile à suivre en Go. Le langage et ses qualités intrinsèques ne sauraient remplacer la compétence de la personne qui l’utilise.

À mes yeux, utiliser la stdlib pour jauger de la lisibilité du langage tombe un peu dans le même biais que les bancs de microbenchmarks pour comparer les perfs des langages : ça donne une information parcellaire qu’on ne peut pas vraiment généraliser.

Je me suis mal exprimé, ce n’est pas tout à fait ce que j’ai voulu dire et je ne veux pas généraliser l’ensemble des codes en Go à partir de la stdlib. Je m’attendrais toutefois à un certain caractère prescriptif, mais c’est un autre sujet.

Ce que cela encourage, c’est notamment à exprimer les règles métier d’un programme d’une façon qui n’a pas vraiment la possibilité d’être mal comprise ou mal maîtrisée.

C’est vrai, au point que j’ai déjà eu à lire le code directement pour me rendre plus explicites les règles métier d’un programme. Mon exemple le plus récent, c’est d’avoir lu le code de image/jpeg pour comprendre certains aspects de JPEG/JFIF que je ne saisissais pas totalement en lisant sa norme ITU-T. En l’occurrence c’est dans la stdlib, mais c’est ici contingent (j’ai aussi eu à le faire en dehors). C’était plutôt ça l’esprit de ma remarque avec la stdlib, d’ailleurs (je pensais à cet exemple précis)

Merci pour ce billet qui donne envie de tester le Go. Pour mettre un peu de contexte, je développe principalement en C#, j’aime beaucoup ce langage mais je trouve qu’il a tendance à se "complexifier" avec le temps (de plus en plus de feature et de syntaxe). Étant dans une phase ou j’ai envie de découvrir de nouvelles choses, je me dis pourquoi pas le go. Pour ceux qui l’utilise en entreprise, vous l’utilisez dans quel contexte / sorte de projet ? J’ai l’impression qu’en France, il n’est pas très répandu, c’est juste une impression ou une réalité ?

Il y a deux domaines d’application où il est vraiment bien installé :

• les serveurs (de backend ou d’infrastructure),
• les clients en ligne de commande (docker, kubectl, etc.).

D’autres sont évidemment possibles mais dans le monde "pro" c’est essentiellement là qu’on le trouve et qu’il brille.

Pour ceux qui l’utilise en entreprise, vous l’utilisez dans quel contexte / sorte de projet ? J’ai l’impression qu’en France, il n’est pas très répandu, c’est juste une impression ou une réalité ?

Je ne manque pas de recruteurs (en France) qui me proposent des postes en rapport avec Go spécifiquement. Autant qu’en Python, je dirais, pour ce que mon anecdote vaut.

De ce que je vois pour le moment, le profil des entreprises (en France) qui utilisent Go vont plutôt être sur des produits qui ont un aspect très infra et systèmes (par exemple produit d’automatisation, produits d’audit système, produit PaaS dans le Cloud). Tandis que les offres en Python que j’obtiens, ça sera plutôt pour des entreprises éditant un SaaS (typiquement avec Django).

Je suis tombé sur un lien très à propos de notre conversation de la semaine dernière, je partage ça avec vous : https://github.com/SuperPaintman/the-evolution-of-a-go-programmer

La pratique est pourtant déjà courante, en tout cas de ce que je perçois (donc biais possible), sans que ce soit problématique de prime abord.
J’entends qu’il y a de plus en plus d’usage de « snap » et similaires sous GNU/Linux, et avant cela il existait déjà des « optware » même si c’était plus réservé (et moins pour des applis bureautique mais plus pour des trucs propriétaires qui fonctionnent en console et/ou démon.) Je vois aussi de plus en plus d’applications Electron où cela semble être le cas : on embarque son instance de navigateur et on n’utilise quasiment pas de bibliothèque système (bon, je crois en vrai qu’on fait appel au minimum indirectement.) De ce que je vois, sous Android et iOS, les applications mobiles partagent peu de bibliothèques (mais utilisent le minimum disponible selon ce que le manifeste autorise ?)

Si ce n’est pas un frein, je ne dis pas que c’est génial d’une part pour l’espace disque consommé et parce-que d’autre part certaines failles sont dupliquées et patchées individuellement.