Lorsque j’ai appris l’existence de Go, le langage de programmation propre à Google, j’ai été intrigué. Conçu et publié en 2007, Go, alias Golang, faisait partie d’une foule de nouveaux langages-Rust, D, Nim, Scala, Clojure-générant du buzz au début et au milieu des années 2010 : À l’époque, les programmeurs semblaient désireux de s’éloigner du bagage verbeux des anciens langages dorsaux (Java, C++) ainsi que de l’inefficacité informatique et de l’insécurité des types des langages dynamiques utilisés sur le Web (PHP, Ruby, Python). Ils voulaient la sécurité de type, ce qui signifie qu’ils voulaient le typage statique. Et ils voulaient de la vitesse.
Il était facile de trouver des histoires sur des startups, comme IronMQ, qui sont passées de dizaines de serveurs utilisés pour héberger Rails à un couple qui pouvait être hébergé dans un langage comme Go. Et en tant que personne qui était, à l’époque, imprégnée de PHP5 et de tous ses problèmes, je me comptais parmi la foule des intéressés.
Lorsque j’ai découvert Go pour la première fois, dans mon ancien poste de CTO chez ActiveCampaign, j’ai essayé d’écrire un peu de code dedans. Et je n’ai pas aimé. Il me posait des problèmes dès que je laissais une variable inutilisée ou que j’importais un paquet non utilisé. Go était particulièrement strict sur le typage – j’étais familier avec la coercition de type de PHP, mais j’étais également habitué à C et C++, qui vous permettent de mélanger les entiers signés et non signés, ainsi que de mélanger les tailles d’entiers (16 bits, 32 bits, 64 bits).
Go n’avait pas de génériques. En fait, l’un de ses principaux concepteurs de langage (Rob Pike) était plutôt strident sur ce qui manquait au langage. Comme le disait Pike, c’était une bonne chose, et une bonne chose pour vous. Le langage a été conçu pour les ingénieurs « moyens » qui travaillaient chez Google, si on peut les appeler ainsi. Dans un certain sens, ce que vous avez lu sur Go à cette époque était ressenti comme une dévalorisation. Et à ce jour, il n’est pas difficile de trouver des gens qui continuent à partager cette critique.
Alors qu’est-ce qui m’a fait changer d’avis ?
Go est simple. Il se distingue des autres langages à cet égard. La simplicité est une vertu, et toute complexité que l’on introduit dans le langage est soigneusement étudiée.
Pendant longtemps – trop longtemps, si vous demandez à certains -Go manquait d’une véritable gestion des paquets. Ce n’est qu’en 2018 – après plusieurs cycles d’engagement de la communauté et un gestionnaire de paquets expérimental non officiel appelé « dep » – que tout support officiel de leur solution (« modules ») a été ajouté au langage.
Mais dans cette simplicité, vous trouvez beaucoup de valeur. Vous pouvez facilement écrire quelques one-liners en Ruby qui font des choses cool, mais caché dans ces one-liners est beaucoup de magie : Il est difficile pour le développeur sans prétention de toujours saisir le processus qui se passe dans les coulisses. Il faut peut-être cinq lignes de code pour écrire la même chose en Go, mais vous savez ce que font ces cinq lignes.
Go supprime également l’un des concepts classiques de la POO : l’héritage. Vous ne pouvez pas écrire une classe de base en Go et avoir une autre classe qui en hérite. En fait, vous n’avez pas de « classes » du tout.
Au début, cela semble être une énorme contrainte de se voir retirer l’un des outils de base de la réutilisation du code et de l’encapsulation. Et il est naturel que votre première inclination soit un sentiment de ressentiment.
Mais, de nos jours, vous n’utilisez souvent pas l’héritage, même si vous le pouviez. Vous utilisez des interfaces, vous vous concentrez sur le comportement et les abstractions – et cela, vous pouvez facilement le faire en Go. En fait, c’est tout ce que vous pouvez faire en Go. Au bout d’un moment, l’absence d’héritage est une bonne chose, car vous évitez une couche de dette technique en n’ayant pas à revisiter le dangereux nid de relations que vous aviez construit en utilisant l’héritage. Peut-être que Pike était sur quelque chose après tout.
Aujourd’hui, Go s’est taillé un créneau défini dans l’écosphère des langages. Il n’essaie pas de remplacer C++, comme on le pensait autrefois (et le suggérait). Alors que vous auriez pu penser avoir besoin de Java pour un certain projet il y a 10 ans, de nos jours, vous feriez peut-être mieux de tendre la main à Go.
Langues à apprendreLes leaders de l’ingénierie discutent de Ruby on Rails, C#, Python et JavaScript
.