Voyage en Golang

Quand on commence à avoir une certaine expérience de la programmation d’application de gestion, quel que soit le domaine fonctionnel à couvrir, pour une application de bureau ou en web, dans un contexte d’architecture plus ou moins complexe, il est légitime de se poser la question : quel langage de programmation est le plus adapté à mon besoin ?

En pratique, on se dit plus souvent : je vais prendre celui que j’ai l’habitude d’utiliser et/ou que l’équipe connait le mieux !

Attitude tout autant légitime, j’en conviens…

Mais, il n’est pas rare, à titre individuel ou collectivement au sein d’une équipe de développeur·euses, qu’on finisse par se l’avouer : tel ou tel aspect de ce langage est vraiment pénible, pas optimisé, gourmand en ressource, trop verbeux … la liste peut être longue !

Chez INCAYA, la diversité de nos parcours, de nos expériences, fait qu’on discute beaucoup de langages. Il y a les fans de Python, les habitués de NodeJS, les experts Java, les convertis à ReactJS (ou tout autre framework front JS), les puristes du HTML/CSS/VanillaJS, et même une certaine nostalgie de PHP (parce qu’on n’en fait plus beaucoup) … Bref, il ne manquait plus que Golang !

Réapprendre encore et encore

Bon, je l’avoue, de prime abord, j’étais réticent à Go malgré l’enthousiasme d’une partie de l’équipe. Parce qu’il faut réapprendre, repartir de zéro, avec une courbe d’apprentissage parfois vertigineuse …

Chez INCAYA, on construit beaucoup d’API Web souvent avec NodeJS et Express (ou l’un de ses multiples dérivés) dans le but de servir des applications Web souvent en ReactJS… et çà me va bien dans l’absolu (même si je prends plaisir à m’évader dans Python avec Flask notamment) !

Du coup, j’ai pris le taureau par les cornes et suivi les formidables livres tutoriels d’Alex Edwards achetés par un collègue : Let’s Go puis Let’s Go Further (mais y’en a plein d’autres)

Premier constat : c’est pas si rude !

Alors certes ces livres sont hypers didactiques, ce qui contribue très probablement à rendre le langage a priori digeste.

Il n’en reste pas moins que c’est un fait : du code Go se lit très très bien !

J’avais d’ailleurs déjà pu le constater en suivant avec attention le dépôt to-go-or-node-to-go de mon collègue Alexis.

Où sont les dépendances ?

Alors là, c’est vraiment l’une de ses spécialités, surtout en comparaison avec NodeJS : le langage embarque nativement un volume impressionnant de fonctionnalités, diminuant drastiquement les dépendances à d’autres projets.

Prenons l’exemple du Web, justement, j’ai été bluffé par tout ce qu’il est possible de faire, en installant très peu de dépendances : du routing au templating HTML/CSS en passant par la gestion des formulaires, des erreurs ou encore de la connexion à la base de données…

L’avantage que cela procure est une bonne maîtrise de l’éventuelle dette technique (comprendre : du code avec beaucoup de dépendances pas mis à jour depuis longtemps).

Et les concepteurs du langage en ont rajouté une couche avec une promesse de compatibilité fort alléchante.

Des concepts à intégrer

Passons au moment douloureux du voyage, aux obstacles pour qui vient de la galaxie Javascript / NodeJS.

Go communique avec les ressources machines en direct, il n’y a pas de machine virtuelle, donc forcément (et les habitué.es de C/C++ vont comprendre) : il y a des pointeurs !

L’allocation mémoire, l’utilisation des ressources, la concurrence entre les tâches, tout cela va être embarqué dans des Goroutines en complète opposition avec l’asynchronisme de NodeJS.

Cela confère à Golang une solide réputation de langage ultra performant. Pour plus de détails encore sur les performances comparatives des différents languages.

Je type, Tu compiles, Il teste

Golang est typé. Nativement très typé. Jusqu’au concept d’interface emprunté aux langages C/C++ ou Java. Cela ajoute sensiblement à la clarté du code, bien sûr, et s’avère un passage obligé là où NodeJS avec TypeScript, qui alourdit encore les dépendances du projet, peut être largement contourné pour qui voudrait “aller vite” (qui n’a jamais mis les mains dans un projet TypeScript qui, au fil du temps, se remplit dangereusement de any ?).

Golang est compilé, il faut le savoir. On critique parfois le langage à cause de la taille de ses binaires. C’est vrai que c’est surprenant de prime abord. Les concepteurs s’en défendent avec des arguments qui semblent évidents une fois qu’on a compris la philosophie du langage.

Du code Golang est testable en natif, et çà c’est quand même hyper chouette #argumentMassue.

Parce qu’il faut bien conclure

A l’instant où j’écris ces lignes, je n’ai pas encore eu l’occasion de déployer un projet complet en production chez un client, ni même “pour moi”.

Donc, je n’ose pas encore dire “arrêtez NodeJS et passez tous à Golang !”.

Cela étant, je n’aurais aucun mal à conseiller à des développeur·euses, débutant·es comme chevronné·es, d’aller jeter un œil à Golang et de suivre des tutoriels.

Cela concerne d’ailleurs tou·tes les développeur·euses et pas uniquement les spécialistes du web, ce qui en fait un langage très polyvalent.

Thomas B.