Article

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.

Alors que les méthodes se font toujours plus nombreuses, les livres toujours plus prescriptifs, les outils toujours plus performants, la démarche toujours plus industrielle, l’industrie du logiciel continue à produire autant de dette, de retard et de bugs qu’auparavant.
C’est un secret de polichinelle et pourtant rien ne change. Pourquoi ?
Peut-être est-il temps de chercher la cause là où trop peu regardent.

Laissez-moi vous raconter une histoire.

Imaginez, vous êtes embauché en tant que chef de projet informatique, dans une startup où le développement est complètement stoppé :

Face à une IA capable de compiler nos intentions en programmes fonctionnels, je m’interroge : notre métier se réduit-il à l’assemblage de syntaxe, ou cache-t-il une dimension qui échappe par nature au calcul ?

J’avais 17 ans quand j’ai enfin mis la main sur “The Art of Computer Programming” de Donald Knuth.
À l’époque, en 1989, les livres de référence sur la programmation étaient rares et les 4 volumes de TAOCP faisaient figure de “bible”; il reste encore pour moi un ouvrage de référence que chaque informaticien devrait lire.

Apprendre Rust en 2022

Si vous suivez mes blogs/podcasts vous savez déjà que je suis un fan du langage Go, aprés avoir été pendant plusieurs années un utilisateur passionné de Perl.

Ce que vous ignorez peut-être c’est que j’ai utilisé ou continue à utiliser de nombreux autres langages, et que je continue régulièrement à apprendre de nouveaux langages.

Ces 10 dernières années j’ai un peu changé ma façon de faire : pour m’immerger complètement dans le langage que j’apprend, j’essaie pendant un an de réaliser tous mes nouveaux projets dans ce langage. Ce n’est pas forcément le meilleur choix d’un point de vue pratique (un outil ligne de commande en Javascript peut être un peu lourd à déployer par exemple) mais ça me permet de m’impliquer à fond dans l’apprentissage d’un langage.

Ces derniers temps, le hasard a fait que j’ai beaucoup entendu parler de Test Driven Development.

Souvent sur le vieux thème “le TDD est mort” (https://dhh.dk/2014/tdd-is-dead-long-live-testing.html) et avec les mêmes questions qui resurgissent :

• jQuelle est la définition des différents types de tests ?
• Quel est le pourcentage de couverture de code idéal ?
• Comment gérer les tests fragiles ? Les tests lents ?

Et si je vais adresser rapidement ces questions aujourd’hui, c’est plus par souci de complétude que par réel intérêt. En effet ces questions ne sont pas propres au TDD, mais communes à l’activité du test logiciel.

Hugo

Cette semaine, sur les bons conseils de mes amis de la frenchgo, j’installe Hugo pour héberger mon blog.

Objectif

J’ai déjà un blog sur Blogger depuis 2007, et un sur Medium depuis 2016 alors pourquoi vouloir héberger mon blog ?

Je quitte Medium car l’idée de devoir payer pour consulter des articles sur un site sur lequel je publie du contenu m’est devenu insupportable. Le choix de cette plateforme m’avait plus ou moins été imposé par un éditeur, même si je dois l’avouer la visibilité procurée a été un critère pour rester dans un premier temps. Mais, n’ayant plus d’articles à produire pour cet éditeur je suis désormais libre de choisir ma plateforme, et je ne vais certainement pas rester sur Medium.

Billet publié à l’origine en janvier 2016 sur mon ancien blog. La version longue et anglaise de cet argumentaire est Why JavaScript in 2016?.

Parmi mes résolutions de début d’année l’étude approfondie de JavaScript et de son écosystème tient une place de choix.

Pourquoi JavaScript ? Alors que Perl 6 est là ? Que des langages plus récents comme nimrod, go, rust ont vent en poupe ? Que des langages offrant d’autres paradigmes comme haskell, clojure seraient plus dépaysant ? Pourquoi JavaScript en 2016 ?!?

Billet publié à l’origine en juin 2010 sur mon ancien blog. C’est le germe de tout ce que j’ai écrit depuis sur l’amélioration continue.

J’ai longtemps pensé que j’aimais bien améliorer la roue : prendre les choses et les pousser un peu plus loin, améliorer ce qui pouvait l’être, corriger ce qui n’allait pas, trouver une nouvelle utilisation, etc…

Mais en y réfléchissant ce n’est pas tant les choses que la démarche qui m’importe : c’est plutôt “continuer à faire tourner la roue de l’amélioration”…

Billet publié à l’origine en février 2009 sur mon ancien blog. C’est le premier d’une série qui s’est prolongée pendant des années : Python en 2009, JavaScript en 2016, Go en 2018, Rust en 2022.

N’ayant pas pris de bonnes résolutions cette année (à part 1280x800 (je sais c’est nul :-p)) je profite d’une semaine de vacances au ski pour prendre une “grande décision” :

2009 sera pour moi l’année de Python. Tout ce que j’aurais fait naturellement en Perl sera fait en Python. Pour me forcer à apprendre réellement Python, découvrir la culture associée, peut être me débarasser de quelques a priori et qui sait, enrichir mon “bag of tricks”…