Go

Et si le vrai gain n’était pas au niveau des octets ?

J’ai toujours été fasciné par les algorithmes de compression, j’avais 15 ans quand j’ai “inventé” le Run Length Encoding (avant d’apprendre qu’il avait été découvert plus de 20 ans avant ma naissance).
Je me suis extasié sur la simplicité “visuelle” du codage de Huffman, de l’astuce de Lempel-Ziv qui construit dynamiquement son dictionnaire.

Ces algorithmes sont puissants, et ce n’est pas un hasard s’ils sont sans cesse améliorés et encore combinés pour produire de nouveaux algorithmes encore plus puissants : Brotli, zstd.

Pourquoi écrire encore sur le layout et les pratiques Go en 2026 ?

En 2018, Mat Ryer écrivait un article de référence How I write HTTP services after 8 years qu’il a mis à jour quelques années plus tard : “How I write HTTP services in Go after 13 years”.

En 2019, je présentais déjà ma manière de coder en Go dans plusieurs présentations d’introduction au langage.

Ce texte est une version révisée de cette présentation, nourrie par mon expérience et mes contraintes en 2026.

Parfois, une investigation raconte une autre histoire que celle que vous attendez.

C’est ce qui m’est arrivé récemment en cherchant pourquoi un pod finissait en OOMKilled deux à trois fois par jour.

Une rapide observation de la mémoire du pod incriminé ne montre pas la courbe croissante typique d’un memory leak. Je manque de données juste avant le OOM (parce que c’est toujours quand votre système de métriques est en train de migrer que ce type d’incident se produit) mais avec les données de la journée, la cause semble se trouver ailleurs.