Le support des génériques était très attendu. Il est même considéré comme le changement le plus important du langage de programmation depuis la sortie de Go 1.0 en 2012. Disponible depuis le 14 décembre en bêta, cette version 1.18 de Go est donc la première version préliminaire du langage open source développé par Google à offrir le support du code générique qui utilise des types paramétrés. La programmation générique apporte une amélioration, car elle donne accès à une représentation de fonctions et de structures de données sous forme générique, avec prise en compte des types. Les génériques peuvent fournir des blocs de construction pour partager le code et faciliter la création de programmes.
Dans un billet de blog, l'équipe de Go a néanmoins rappelé que, comme c’est le cas avec toute fonctionnalité récente et importante, les utilisateurs devaient s’attendre à découvrir quelques bogues. Car les génériques ne devraient pas faire exception à cette règle. C’est pourquoi, ils conseillent aux développeurs d'aborder les génériques avec la prudence qui s’impose. De plus, la prise en charge de certains cas subtils, notamment des types spécifiques de génériques récursifs, a été reportée à des versions ultérieures. Cependant, selon l'équipe de développeurs de Go, certains utilisateurs précoces sont « plutôt satisfaits ». Un bref tutoriel expliquant comment démarrer avec les génériques est disponible. Selon un billet de blog publié en juillet 2019, même si Go gère déjà les types Interface, une capacité proche d’une programmation générique, le langage ne fournissait pas ce que les développeurs de Go souhaitaient offrir avec les génériques. Par exemple, les développeurs adeptes des génériques dans Go voulaient rendre possible l’écriture de fonctions de type Reverse sans qu’il faille se soucier des éléments de type dans un tableau dynamique (Slice).
les autres évolutions dans Go 1.18
Parmi les autres nouveautés de Go 1.18, on peut citer :
- Un support intégré pour l'écriture de tests basés sur le fuzzing, de façon à trouver plus facilement les entrées automatiques qui font planter un programme ou renvoient des réponses invalides.
- La possibilité pour les développeurs de travailler avec plusieurs modules Go simultanément dans un mode d’espace de travail Go, ce qui est important pour les grands projets.
- Une commande go version -m étendue qui enregistre désormais les détails de la construction, comme les indicateurs de compilation.
- La possibilité pour les utilisateurs de sélectionner l'une des quatre versions de l'architecture AMD64 grâce à la variable d'environnement GOAMD64.
- Les ports Windows/Arm et Windows/Arm64 supportent désormais la préemption non coopérative, apportant cette capacité aux quatre ports Windows et, corrigeant, il faut l’espérer du moins, les bogues subtils rencontrés lors de l'appel de fonctions Win32 qui bloquaient pendant de longues périodes.
- Le ramasse-miettes inclut désormais les sources de travail du GC (Garbage Collector) qui ne sont pas dans le heap quand il détermine la fréquence d'exécution. Cette fonction rend la surcharge du GC plus prévisible quand ces sources sont importantes.
La version 1.17 de Go a été publiée en août dernier. Le langage est sans doute plus connu pour avoir servi de base au développement du système de conteneurs Docker. Les développeurs à l’origine de Go souhaitaient proposer un langage de programmation simple et facile à apprendre, avec une forte prise en charge de la concurrence.
La Bêta 1 de Go 1.18 est accessible sur go.dev. Cette version est considérée comme « instable ». La version de production de Go 1.18 est prévue pour février 2022. Les notes de version sont accessibles sur tip.golang.org.
les generics c'est le mal.
Signaler un abusOk une fois que l'on a dit cela on a pas dit grand chose et pourtant tout est dit.
Les generics en Go sont "générés" à la compilation ( les interfaces sont des mécanismes au Runtime)
Voyez les generics comme des Macros en C
Cela a très peu de "use-cases" en général on les utilise dans des collections où la manipulation des éléments ne dépend pas complètement des éléments.
Nous avons donc que trois solutions
1) Soit on écrit du code en double, en triple ... pour gérer ton les types souhaités
2) Soit on rajoute une couche supplémentaire Pointer/interface et on manipule que des adresses.
3) Soit le langage nous donne la possibilité de manipuler les éléments typés directement sans vraiment connaître leur type (avec dans GO la possibilité de contrainte exemple je manipule des nombres [T int| int32 | int64 | float32 | float64])
Là où cela devient mal et même très mal c'est la violence faite à la syntaxe pour en fait très peu de Use Case
func Add[T int | int32 | int64 | float32 | float64] (a T, b T) T {
return a+b
}
Oui cela pique les yeux ! Allez passons
Ce qu'il faut bien comprendre c'est que la fonction Add N'EXISTE PAS !!!
le compilateur va générer zéro ligne de code
Et donc vous ne pouvez pas passer cette fonction en paramètres (genre des trucs utiles comme de la Dependency Injection) car Il n'y a pas de Add
si plus tard vous utilisez Add(1,2) ou Add[int](1,2) <<< Go à la compilation va créer
Add(a int, b int) int
et si vous utilisez assi Add[floa664](1.2, 3.4) : Go va créer une deuxième fonction
Add(a float64, b float64) float
Et oui une deuxième Mais dit donc ! On se retrouve avec la solution numéro 1 mais écrit par une Marco
Bon mon conseil : apprenez bien comment utiliser les generics pour ne pas les utiliser
Et si vous êtes face à un cas vraiment tordu et que les generics sont la seul issue alors... envoyez moi le use case cela m’intéresse
Une dernière chose, avec la Beta 1 de 1.18 il y a plein de bug avec les generics mais il y a eu trop de communication autour et les équipes de Go.dev iront au bout Dommage.
Golang reste un langage merveilleux