Les mensonges que nous nous racontons pour continuer à utiliser Golang (2022)

• L’auteur est un ornithorynque

  • Balayer les critiques en qualifiant l’auteur d’incompétent est une approche paresseuse.
  • Un développeur junior peut aborder les problèmes avec un regard neuf, et c’est une raison importante de l’embaucher.
  • L’auteur n’est pas un développeur junior et possède, grâce à des expériences variées, une compréhension de la conception des langages.

• Si maman fume, ça doit aller

  • Suivre aveuglément les technologies utilisées par d’autres entreprises est inefficace.
  • Les blogs techniques servent aussi à donner une bonne image de l’entreprise.
  • Le blog de Tailscale est honnête, mais il faut beaucoup d’efforts pour résoudre les problèmes de Go.

• Les bons côtés

  • Go dispose d’un excellent runtime asynchrone et d’un ramasse-miettes performant.
  • Les outils pour la gestion des paquets, le refactoring ou la cross-compilation sont faciles à utiliser.
  • Mais les défauts de Go ne peuvent pas être ignorés, et le problème tient au fait que la conception du langage semble s’être faite par accident.

• Go est une île

  • Go manque d’interopérabilité avec les autres langages.
  • La toolchain de Go est particulière, et elle ne permet pas d’utiliser les langages d’assemblage ou débogueurs existants.
  • Le moyen le plus simple d’intégrer Go est de passer par les frontières réseau.

• Tout ou rien (donc rien du tout)

  • Go peut laisser des champs de structure non initialisés.
  • L’idée que la valeur zéro ait un sens est naïve et pose souvent problème.
  • La culture de Go consiste davantage à dire de faire attention qu’à résoudre le problème.

• "Rust est parfait et vous êtes tous stupides"

  • Rust peut être adopté progressivement et s’intègre bien avec d’autres langages.
  • Le succès de Rust tient en partie au fait qu’il permet une transition vers un langage sûr.
  • Rust a aussi ses défauts, mais ils sont progressivement corrigés.

• Utiliser Go comme langage de prototype/de démarrage

  • Go est souvent considéré comme un langage facile à apprendre, mais en réalité il demande beaucoup d’expérience.
  • Il manque de fonctionnalités qui permettent de voir clairement qu’un code est erroné.
  • Les défauts de Go apparaissent avec le temps, et c’est un langage dont on ne sort pas facilement.

• Les mensonges que nous nous racontons pour continuer à utiliser Golang

  • Puisque d’autres l’utilisent, cela doit aussi nous convenir
  • Considérer comme acceptables, individuellement ou collectivement, les défauts de conception du langage
  • Penser qu’en étant attentif, on peut surmonter les problèmes
  • Penser que parce qu’il est facile à écrire, le développement de logiciels de production l’est aussi
  • Penser que parce que le langage est simple, tout est simple
  • Penser qu’on pourra toujours tout réécrire plus tard

[tsboard]

Je me demande si un amateur qui n’a passé qu’un temps très bref mais intense avec le langage Go peut vraiment se permettre d’écrire là-dessus... Go a des avantages et des inconvénients très nets, donc ceux qui le choisissent comme ceux qui l’évitent semblent avoir des raisons bien précises. Personnellement, je ne pense pas qu’il faille le comparer à Rust, mais plutôt à Kotlin (Java).

Les goroutines de Go sont vraiment excellentes, mais ce n’est pas de la magie. Surtout sur le backend, dans un petit projet qui n’utilise qu’un seul MySQL, cette concurrence est vraiment difficile à gérer. Des problèmes comme l’épuisement des ressources MySQL ou la gestion du pool, auxquels on ne fait pas particulièrement attention dans un runtime JS/TS, sont plus compliqués qu’on ne l’imagine. Au final, dans cette situation, la base de données devient le goulot d’étranglement, ce qui atténue en partie les avantages de la concurrence en Go. (L’I/O asynchrone ou la boucle d’événements d’un runtime JS/TS peut même être plus adaptée.) Il suffit de lancer un outil comme hey avec -c 100 pour s’en rendre compte.

Et même si le GC est excellent, cela ne veut pas dire qu’on peut se contenter de passer des objets par pointeur à tout-va et ignorer complètement le nettoyage derrière. Tout est affaire de compromis, mais avec Go aussi, il vaut mieux, si possible, passer les petits objets par copie de valeur afin qu’ils soient traités immédiatement à la fin de la fonction. Je suis peut-être enfermé dans une manière de penser un peu datée, mais il ne fallait pas aborder les pointeurs trop facilement sous l’angle de l’efficacité comme en C/C++.

Le fait de devoir presque toujours renvoyer error dans les retours de fonction et de devoir le vérifier à chaque fois avec if err != nil {} est vraiment pénible, mais c’est aussi un avantage. Parce que le coût est plus faible qu’avec try catch. Et le mot-clé defer, qui joue un rôle similaire à finally {}, est lui aussi excellent. C’est appréciable de ne pas avoir à se demander à quel moment libérer les ressources. J’aime aussi le fait qu’il soit possible de mettre en place immédiatement un excellent serveur backend avec la seule bibliothèque standard (1.23 et plus). Et surtout, le meilleur point reste qu’une fois compilé pour l’OS cible, il n’y a besoin d’aucun autre runtime ni d’aucune préinstallation.

Je n’utilise pas Go depuis très longtemps, donc j’ai l’impression de m’étendre un peu trop avec des opinions très personnelles, alors je vais m’arrêter là. Haha, moi j’aime bien Go, mais j’aime aussi les autres langages !

[GN⁺]

Avis Hacker News

• Il y a beaucoup de critiques sur les défauts de Go, mais la gestion explicite des erreurs n’en fait pas partie. La gestion par exceptions ajoute une couche de « magie » qui rend les erreurs trop faciles à commettre. Pour les projets personnels, Rust est préféré, mais sur les grands projets impliquant des développeurs de niveaux variés, la philosophie de Go constitue l’approche de gestion des erreurs la plus raisonnable dans le monde moderne.

  • Go est davantage adopté que d’autres langages « nouveaux » grâce à sa simplicité. Ce n’est pas le meilleur langage, mais avec ses nombreuses opinions intégrées, c’est souvent le meilleur choix comme langage généraliste.

• Rust et Go sont très différents, et le juste milieu que les gens recherchent n’existe pas actuellement.

  • Il faudrait un langage relativement simple avec un système de types similaire à celui de Rust.
  • Gleam et Kotlin s’en rapprochent un peu, sans pour autant correspondre complètement. Rust est trop complexe, donc difficile pour les non-spécialistes ou les non-professionnels.
  • Il n’existe pas de langage parfait, mais Go et Rust ont apporté des choses remarquables. Il serait souhaitable qu’un langage de programmation simple et largement utilisable voie le jour en s’inspirant des deux.

• J’aime les langages simples. Comme la technologie implique toujours des compromis, une critique équilibrée est importante.

  • Un lien vers un billet de blog sur les raisons du choix de Go est partagé.

• On peut se demander pourquoi il est si important de critiquer un langage. Les critiques ne sont pas rédigées de manière constructive.

  • Tous les langages peuvent être critiqués. Go fonctionne très bien dans des projets malgré ses différences avec des langages « plus sophistiqués ».
  • Il faut donner du feedback à l’équipe Go, observer l’évolution lente du langage, et continuer à rendre service à la communauté.

• Chaque fois que je lis une critique de Go, je me dis que je continuerai quand même à l’utiliser.

  • Il y a beaucoup de problèmes en théorie, mais en pratique cela reste un bon langage de programmation.
  • J’aime la gestion explicite des erreurs. Et je ne me soucie pas non plus particulièrement des défauts des autres langages.
  • Ceux qui sont sensibles aux défauts de Go continueront à se plaindre. Il suffit de choisir le langage qui nous convient.

• Chaque fois que j’utilise un autre langage, j’ai envie de revenir à Go.

  • Avec Go, il suffit de l’installer, de télécharger le code et de l’écrire, et c’est tout. Pas besoin de se soucier des versions, du runtime, de la configuration, des outils de build ou du gestionnaire de paquets.
  • Rust peut aussi offrir une expérience comparable. En revanche, avec Python, Typescript ou Java, les problèmes liés à la configuration finissent par faire peur à l’idée même de programmer.

• Je cherchais un meilleur Python. Go semblait être le choix évident, mais je déteste sa syntaxe.

  • Rust utilise trop de caractères spéciaux, et Lisp est rebutant à cause des parenthèses et de la notation polonaise inversée.
  • Je compile du code Python avec Nuitka pour distribuer des binaires. Je m’intéresse aussi à la compilation AOT de C#.
  • J’aime Nim et Crystal, mais la petite taille de leur communauté constitue un frein. Nim reste un excellent langage malgré cela.

• Je ne sais pas pourquoi Go et Rust sont si souvent comparés. Il serait plus pertinent de le comparer à Java.