"Il n’y a aucun langage avec lequel j’ai une relation aussi passionnante et enrichissante qu’avec Go"

Interview de Rudy Rigot, auteur du livre Programmer en Go : pourquoi ? Comment ?

[04/02/2018]

 

 

 

 


Bonjour Rudy, peux-tu te présenter en quelques mots ?

Bien sûr ! Je suis Rudy Rigot, j’habite à Chicago avec ma femme et ma fille, et je suis dans l’industrie tech depuis un peu plus de dix ans dans divers rôles. J’en ai passé la première moitié en France à faire principalement du consulting et la deuxième moitié aux USA, principalement en Californie, à faire du produit comme il y en a beaucoup ici. Depuis que je suis aux États-Unis, j’ai été ingénieur pour Apple et pour Salesforce, j’y ai aussi cofondé une startup (Holberton School, programme de formation sur deux ans pour ingénieurs logiciels à San Francisco, qui tourne toujours à fond).

Rudy RigotJe suis passionné par les modèles d’innovation technique et le modèle économique des startups, et je fais beaucoup de conseil auprès de ces dernières, à différentes phases de leur développement. Notamment, je les aide à de très « early stage » en tant que startup mentor pour TechStars (un des plus gros accélérateurs de startups au monde). Aussi, je travaille actuellement chez Kenna Security, une startup locale à Chicago qui est en phase d’hyper-croissance depuis trois ans, et je les aide à définir la meilleure manière d'accroître leur équipe tout en conservant (voire en multipliant, si possible !) leur capacité d’innovation qui a fait leur succès jusqu’à maintenant.

En une phrase, je me présente souvent aux gens que j’aide en leur disant que mon expertise est à l’intersection de la technologie et du business via l’innovation.


Depuis que tu as découvert Go, tu n'as cessé d'être sous le charme de ce langage. Pourquoi un tel enthousiasme ?

Justement, une des raisons pour lesquelles j'apprécie Go et son écosystème est qu’il essaie lui aussi, de manière très pragmatique, d’être à l’intersection du business et de la technologie. De ses différents domaines d’application (que j’aborde en détail dans le livre), c'est indiscutablement sa faculté à répondre aux besoins spécifiques des microservices et architectures orientées services qui me passionne le plus, car ce type d'architecture fait constamment ses preuves pour résoudre les problèmes organisationnels auxquels sont confrontées les équipes sur des produits en ligne en phase de croissance.

D’un point de vue technique, je ne cesse d'être impressionné par sa capacité à faire des compromis constructifs dans l’intérêt aussi bien des développeurs que du besoin métier. Souvent, l'orientation des langages de l’industrie oblige à choisir deux qualités entre les trois suivantes : expérience/productivité du développeur, performance applicative et richesse de l'écosystème et de la communauté. Des nombreuses technologies que j’ai pu explorer dans ma carrière, Go est la première à proposer une approche permettant de profiter des trois simultanément. Il y avait une conférence en 2014 qui avait pour titre « Go est 90% parfait, 100% du temps » ; cette phrase exprime bien le compromis constructif obtenu au quotidien par le développeur Go.

 

Go est 90% parfait, 100% du temps


Dans quel contexte l'utilises-tu ?

C’est mon choix de prédilection dès qu'un besoin business peut être solutionné par son propre webservice, que ce besoin soit à court ou long terme. C’est aussi vers lui que je me tourne quand je dois écrire un script dans un contexte qui nécessite de la concurrence (lecture dans plusieurs fichiers, plusieurs appels en base de donnée, etc.), ou que je sais que ce script sera utilisé et maintenu à relativement long-terme.


Quels sont les autres langages que tu utilises ?

Avant d’entrer en phase de croissance, une startup construit généralement un monolithe applicatif avec une technologie qui favorise la productivité plutôt que la performance, le temps de trouver la meilleure adéquation entre son produit et le marché. La startup pour laquelle je travaille ne fait pas exception, et son monolithe applicatif, qui représente toujours une partie importante (mais de moins en moins grande) du business, est en Ruby. Ruby est courant pour les startups early-stage à Chicago, vu que Ruby On Rails a été inventé ici. Du coup, parallèlement à la construction de nouveaux services en Go, une grosse partie de mon travail actuel sur le code existant est en Ruby.

Sinon, avant, j’ai travaillé avec un certain nombre de langages classiques : beaucoup de JavaScript et de Java, du PHP, du Groovy, du Scala, du Python, du C++, etc. J’aimerais bien m’intéresser plus à Haskell, Rust et Elixir cette année.


Quels sont tes autres langages de prédilection ?

Clairement, quand je veux créer rapidement quelque chose qui ne requiert pas la performance et le typage fort de Go, j’ai tendance à regarder du côté de Ruby, qui est sans surprise et offre beaucoup de productivité. Je n’ai rien contre Python, qui est sur un positionnement très similaire, je privilégie juste Ruby parce que je le connais mieux.

J’ai aussi une relation d'amour-haine avec JavaScript, qui est de toute manière incontournable dans le navigateur, et dont j’ai fini par apprendre à apprécier les facéties.

C’est une chose que j'aime bien en tant que programmeur : on a tous établi une sorte de « relation personnelle » avec les langages qu’on utilise ! Et il n’y a aucun langage pour l’instant avec lequel j’ai une relation aussi passionnante et constamment enrichissante qu’avec Go.

 

Go favorise la simplicité du langage à long terme
et la rétrocompatibilité


On compare et oppose souvent Go au langage de Rust conçu et développé par Mozilla. Peux-tu expliquer cela et pourquoi à tes yeux les deux langages sont davantage complémentaires que concurrents ?

Ils ont certainement des points très communs, étant tous deux des langages bas niveau, modernes, compilés, à typage fort et à fil d’exécution multiple. Mais la comparaison s’arrête là, et ils sont très différents à beaucoup d’autres points de vue. Par exemple, Go favorise la simplicité du langage à long terme et la rétrocompatibilité, alors que Rust favorise l’ajout progressif de fonctionnalités dans le langage, quitte à casser la rétrocompatibilité. Go favorise la facilité à gérer la mémoire de manière efficace et productive, alors que Rust favorise le contrôle plus avancé du développeur sur la mémoire, et a donc une courbe d’apprentissage plus ardue sur le sujet. Rust favorise l’interopérabilité de ses exécutables avec les exécutables construits en C, alors que Go favorise la construction d’exécutables sans dépendances. Go a un modèle de concurrence riche et une capacité à compiler pour d’autres systèmes d’exploitation qui sont tous deux des citoyens de premier ordre dans le langage depuis le début, alors que ces deux possibilités ont été ajoutées à Rust plus tard dans sa conception. Il y a nombre d’autres différences dans lesquelles on entre en détail dans le livre.

D’un point de vue métier, je vois bien Go répondre au besoin d’applications de relativement bas niveau, qui n’ont pas de difficulté à embarquer leur propre stratégie d’exécution (par exemple, des pilotes de périphériques, etc.), ainsi que la plupart des webservices. En comparaison, je vois bien Rust répondre au besoin d’applications de très bas niveau nécessitant un couplage fort avec le système d’exploitation, et celui d’une très petite minorité de webservices ayant un besoin particulièrement aigu de gestion de mémoire, puisqu’il offre un contrôle plus avancé de la mémoire pour ces cas extrêmes, au prix d’une prise en main et d’une maintenabilité souvent plus difficile.


À qui conseillerais-tu Go ?

Évidemment à tout ingénieur travaillant sur un produit en croissance, ou souhaitant être recruté sur un produit en croissance ; mais plus généralement, à tout ingénieur voulant mieux comprendre comment utiliser la technologie en général pour résoudre des besoins métier, quelle que soit la technologie utilisée. Go a une courbe d’apprentissage très rapide tout en apportant une approche enrichissante de la productivité et des réflexions sur des niveaux de programmation beaucoup plus bas qu’une majorité des langages de l’industrie. C’est une des principales raisons pour laquelle je voulais écrire un livre spécifiquement sur Go : son apprentissage est instructif pour tout ingénieur quel que soit son environnement, il en ressentira le bénéfice quasi immédiatement en tant qu’ingénieur pour son projet.

 

Il est moins pertinent pour des projets
où la rapidité de développement est plus importante
que la maintenabilité à long terme


À qui le déconseillerais-tu ?

Il est indiscutablement moins pertinent pour des projets où la rapidité de développement est nettement plus importante que la maintenabilité à long terme, un cas évident étant celui de la startup qui n’a pas encore trouvé son « product-market fit » et qui doit donc se concentrer sur sa recherche et ignorer le développement à long terme ; je ne compte plus le nombre de startups très jeunes que j’ai vues échouer pour s’être trop concentrées sur le long-terme et n’avoir pas expérimenté assez vite. Les langages qui font des choix extrêmes pour la productivité au détriment de tout le reste (Ruby, Python, ...) sont sans conteste plus adaptés à ces besoins.

Aussi, si vous ne connaissez pas Go et devez écrire un script qui ne tournera qu’une fois, et n’a pas de contrainte de performance, je vous conseillerais d’utiliser un langage que vous connaissez pour ce type de besoin, n’importe lequel, plutôt que d’en apprendre un pour l’occasion.

Mais pour toute autre situation, Go est un langage particulièrement enrichissant à découvrir.


Pour ton livre Programmer en Go : Pourquoi ? Comment? tu as adopté une approche peu courante dans la documentation technique puisque tu invites d'abord le lecteur à réfléchir sur la manière dont sont résolues quelques grandes problématiques de la programmation avant de lui montrer comment utiliser Go. Pourquoi ce choix ?

Pour les mêmes raisons que le meilleur conseil que je donne aux ingénieurs moins expérimentés que moi est toujours : notre rôle n’est pas de résoudre des problèmes techniques, mais de résoudre des problèmes métier à l’aide d’outils techniques. Comme tous les outils techniques, Go a été créé pour répondre à des besoins métiers. Comprendre ces besoins métiers permet de comprendre plus vite et de retenir plus longtemps les choix de conception faits par l’équipe Go, et en plus, d’être un ingénieur plus pertinent, qui utilise le bon outil pour le bon besoin, et ainsi apporte plus de valeur.

Le livre commence donc par le « pourquoi », expliqué d’une manière simple et enrichissante. Cela nous permet d’enchaîner avec une partie « comment » construite autour d’études de cas relativement superficielles et très simples à comprendre, en comptant non seulement qu’elles recouvrent 80% des cas techniques qu’un développeur rencontrera, mais qu’en plus, ce développeur pourra facilement extrapoler les 20% restants.


Quels conseils donnerais-tu aux développeurs qui débutent avec Go ?

couverture du livre Programmer en Go : Pourquoi ? Comment ?Lisez mon livre, bien sûr ;-) !

Si vous ne le lisez pas, tentez de trouver ailleurs une approche qui commence avec le « pourquoi », vous apprendrez beaucoup plus vite et plus profondément. Considérez Go comme une opportunité pour vous en tant qu’ingénieur.

D'autre part, si vous vous apprêtez à vous lancer et que vous êtes impressionné, n’oubliez pas que Go est réputé pour être l’un des langages de l’industrie les plus simples à apprendre. Comme toujours la découverte de la syntaxe d’un nouveau langage vous causera quelques maux de tête, mais je vous promets que tout s'éclaircira beaucoup plus rapidement que vous en avez l’habitude.


Merci pour tes réponses. Souhaites-tu ajouter quelque chose ?

J’espère vraiment, en publiant ce livre en français, qu’il permettra à des ingénieurs francophones travaillant sur des produits de devenir force de proposition dans leur équipe au fur et à mesure de la croissance de ce produit. J’espère sincèrement que mon livre propulsera des carrières et des produits. C’est l’effet que j’essaie d’obtenir aux US à petite échelle avec les étudiants et les startups que j’accompagne un par un, et j’espère vraiment que ce livre permettra d’obtenir un résultat similaire, à plus grande échelle, en terre francophone.

Bonne lecture !