5 fonctionnalités utiles que vous ne verrez pas dans le langage de programmation Go

Après plus de 12 ans dans la nature, le langage Go est désormais fermement établi comme un outil pour les programmeurs professionnels et pour la construction de systèmes à grande échelle. Bien que Go soit délibérément sobre, propre et efficace, les demandes pour certaines fonctionnalités se multiplient à maintes reprises, même si, en y regardant de plus près, ces fonctionnalités vont à l’encontre des philosophies sous-jacentes ou des objectifs de conception de Go.

Voici cinq fonctionnalités couramment demandées dans Go, que vous ne verrez probablement pas toutes, ou qui n’apparaîtront que sous une forme qui complète le reste de ce qui se trouve dans Go maintenant.

Opérateur ternaire

De nombreuses langues ont une construction qui est essentiellement une if/then/else bloquer dans une seule instruction. Par exemple, en Python, nous pouvons écrire, x = 1 if condition else 0ou en JavaScript nous pouvons écrire, x = condition ? 1 : 0.

La FAQ Go est assez directe sur la raison pour laquelle le langage n’a pas cette fonctionnalité :

Les concepteurs du langage avaient vu l’opération trop souvent utilisée pour créer des expressions d’une complexité impénétrable… Un langage n’a besoin que d’une seule construction de flux de contrôle conditionnel.

De nombreux programmeurs Go sont d’accord avec cette évaluation, à en juger par les commentaires d’une proposition d’opérateur ternaire en 2019. Des propositions connexes, comme celle d’une affectation conditionnelle plus tôt cette année-là, n’ont pas non plus réussi à gagner du terrain.

Types somme ou types algébriques

Une autre fonctionnalité que l’on retrouve dans les langages modernes comme Rust est la somme. Également connu sous le nom de type algébrique ou de type variant, un type somme est une variable qui peut être l’un des nombreux types non nullables possibles. Dans certains langages, un type somme peut être utilisé pour renvoyer une valeur valide ou une valeur d’erreur à partir d’une opération.

Certains programmeurs Go aiment l’idée d’avoir de tels types. En théorie, un type non nullable faciliterait la gestion des vérifications pour nil. Les types de somme rendraient également la gestion des erreurs plus gracieuse.

Cependant, les propositions d’améliorations de ces systèmes de type n’ont pas décollé. Allez interface type est devenu le moyen idiomatique d’implémenter bon nombre des mêmes mécanismes que ceux qui seraient gérés par les types somme.

La FAQ de Go a ceci à dire sur le problème :

Nous avons envisagé d’ajouter des types de variantes à Go, mais après discussion, nous avons décidé de les laisser de côté car ils se chevauchent de manière confuse avec les interfaces. Que se passerait-il si les éléments d’un type variant étaient eux-mêmes des interfaces ?

Une proposition de 2017 pour les types de somme, maintenant déclinée, indiquait une discussion du co-créateur du langage Go, Russ Cox, dans laquelle Cox soulevait les mêmes préoccupations concernant les interfaces.

Types de structure immuables

De nombreux langages soutiennent l’idée d’une structure immuable – pas seulement une variable scalaire qui sert de constante (comme un entier ou un flottant) mais une collection d’éléments d’ordre supérieur qui est immuable.

Go permet au programmeur de créer des constantes, mais uniquement pour les types scalaires, tels que les entiers ou les flottants. Il n’est pas possible dans Go de créer une tranche immuable d’entiers, par exemple. La seule façon d’avoir quelque chose comme des comportements immuables dans Go est de faire des copies de choses et d’opérer sur les copies. Cela peut être lent, et cela impose un fardeau supplémentaire au développeur pour s’assurer qu’il copie bien et qu’il n’opère pas sur les originaux.

Des propositions ont fait surface pour créer des types immuables dans Go 1.x. L’un des plus complets proposait de donner à chaque type une contrepartie immuable et proposait des suggestions pour la mise en œuvre de méthodes d’interface immuables. Les objections à la proposition ont soulevé des “défauts majeurs” tels que const L’empoisonnement, par lequel l’ajout de comportements constants dans une partie d’un programme nécessitait que tous les chemins de code dépendants les implémentent également, ou devenait plus tard difficile à annuler. Un utilisateur de longue date du langage D a décrit son expérience avec une fonctionnalité similaire ajoutée à ce langage, et comment cela a compliqué les choses de manière imprévisible.

Valeurs d’argument par défaut

Une autre fonctionnalité que vous trouvez dans de nombreux autres langages de programmation est les valeurs d’argument par défaut pour les méthodes ou les fonctions. Ici, une méthode est initialisée avec des valeurs par défaut, donc si vous ne fournissez pas d’arguments lorsque vous l’appelez, la méthode fournira les valeurs par défaut.

Go n’a pas de fonctionnalité comme celle-ci, car ses concepteurs l’ont considérée comme contraire à la philosophie du langage. Une objection est que les valeurs d’argument par défaut encouragent une mauvaise conception de l’API, car elles permettent de modifier les arguments d’une fonction après avoir été établis. Les propositions d’ajouter cette fonctionnalité à la langue aussi récemment qu’en 2020 ont été refusées pour les mêmes motifs.

Une alternative potentielle pour les valeurs d’argument par défaut est les fonctions variadiques, qui sont des fonctions qui peuvent prendre n’importe quel nombre d’arguments du même type. Les fonctions variadiques permettraient de transmettre ultérieurement plus d’arguments à la fonction et aux arguments non fournis de se voir attribuer automatiquement des valeurs. Mais tout cela se fait au prix de ne pas être explicitement décrit dans la signature de la fonction, ce qui va à l’encontre de la philosophie de Go.

Gestion des erreurs conventionnelles

La gestion des erreurs dans Go fonctionne en faisant en sorte que les fonctions renvoient à la fois une valeur normale et une valeur d’erreur. Si la valeur d’erreur est autre que nilune erreur s’est produite et c’est à l’appelant de la gérer.

C’est une approche simple mais aussi répétitive et verbeuse, parfois à outrance. Allez panic/recover Le modèle, ce que le langage a de plus proche des exceptions, n’est pas destiné à être utilisé pour la vérification régulière des erreurs, mais pour sauver un programme qui plante.

Un objectif ouvert pour une future version de Go est une meilleure façon de gérer les erreurs, mais jusqu’à présent, peu de choses ont surgi qui semblent susceptibles de remplacer le commun if err != nil passe-partout

Une proposition consistait à remplacer le modèle commun (c’est-à-dire exécuter une fonction, obtenir ses valeurs avec une erreur et renvoyer l’erreur dans la chaîne d’appel si elle n’est pasnil) avec une fonction de vérification d’erreur intégrée appelée try. Mais de nombreux utilisateurs de Go ont résisté à l’idée pour de nombreuses raisons, notamment la raison pour laquelle une construction plus concise n’est pas une solution au problème. try proposition a été refusée.

Toute modification de la façon dont Go gère les erreurs devra d’abord satisfaire ses utilisateurs existants, dont beaucoup considèrent la verbosité et l’explicite de Go comme un avantage et non comme un fardeau.