Go 1.20 est la dernière version qui fonctionnera sur toutes les versions de Windows 7, 8, Server 2008 et Serve
Go 1.20 est la dernière version qui fonctionnera sur toutes les versions de Windows 7, 8, Server 2008 et Server 2012,
la version 1.21 nécessitera au moins Windows 10 ou Server 2016
La version 1.20 de Go n'est pas encore disponible. Il s'agit ci-dessous des notes de version en cours d'élaboration. Go 1.20 sera la dernière version qui fonctionnera sur toutes les versions de Windows 7, 8, Server 2008 et Server 2012. Go 1.21 nécessitera au moins Windows 10 ou Server 2016. La sortie de cette version 1.20 est prévue en février 2023.
Go est un langage de programmation open source, développé par Google, qui facilite le développement de logiciels simples, fiables et efficaces. En raison de sa simplicité, il est utilisé aussi bien pour développer des applications, écrire des scripts pour de grands systèmes. Cette simplicité est nécessaire aussi pour assurer la maintenance et l'évolution des programmes sur plusieurs générations de développeurs.
S'il vise aussi la rapidité d'exécution, indispensable à la programmation système, il considère le multithreading comme le moyen le plus robuste d'assurer sur les processeurs actuels, cette rapidité tout en rendant la maintenance facile par séparation de tâches simples exécutées indépendamment. Cette conception permet également le fonctionnement sans réécriture sur des architectures multicœurs en exploitant immédiatement l'augmentation de puissance correspondante. Passons en revue quelques nouveautés et améliorations annoncées. :
Go 1.17 abordait les conversions d’une séquence vers un pointeur de tableau. Go 1.20 étend cela pour permettre les conversions d'une séquence vers un tableau : étant donné une séquence x, [4]byte(x) peut maintenant être écrit au lieu de *(*[4]byte)(x).
Le paquetage unsafe définit trois nouvelles fonctions : SliceData, String, et StringData. Avec la fonction Slice de Go 1.17, ces fonctions offrent maintenant la possibilité complète de construire et de déconstruire des valeurs de type séquence et chaîne, sans dépendre de leur représentation exacte.
La spécification définit maintenant que les valeurs struct sont comparées un champ à la fois, en considérant les champs dans l'ordre où ils apparaissent dans la définition du type struct, et en s'arrêtant à la première non-concordance. Auparavant, la spécification pouvait être lue comme si tous les champs devaient être comparés allant au-delà de la première discordance.
De même, la spécification définit maintenant que les valeurs des tableaux sont comparées un élément à la fois, dans l'ordre croissant des index. Dans les deux cas, la différence affecte le fait que certaines comparaisons doivent exister. Les programmes existants restent inchangés : la nouvelle formulation de la spécification décrit ce que les implémentations ont toujours fait.
Les types comparables (tels que les interfaces ordinaires) peuvent maintenant satisfaire les contraintes comparables, même si les arguments de type ne sont pas strictement comparables (la comparaison peut échouer à l'exécution). Cela permet d'instancier un paramètre de type contraint par comparable (par exemple, un paramètre de type pour une clé de carte générique définie par l'utilisateur) avec un argument de type non strictement comparable tel qu'un type d'interface, ou un type composite contenant un type d'interface.
Opérateurs de comparaison en Go
== equal
!= not equal
< less
<= less or equal
> greater
>= greater or equal
Dans toute comparaison, le premier opérande doit pouvoir être affecté au type du second opérande, ou vice versa. Les opérateurs d'égalité == et != s'appliquent aux opérandes de types comparables. Les opérateurs d'ordre <, <=, >, et >= s'appliquent aux opérandes de types ordonnés.
Ports
Windows
Go 1.20 est la dernière version qui fonctionnera sur toutes les versions de Windows 7, 8, Server 2008 et Server 2012. Go 1.21 nécessitera au moins Windows 10 ou Server 2016.
Darwin et iOS
Go 1.20 est la dernière version qui fonctionnera sur macOS 10.13 High Sierra ou 10.14 Mojave. La version 1.21 de Go nécessitera macOS 10.15 Catalina ou une version ultérieure.
FreeBSD/RISC-V
Go 1.20 ajoute un support expérimental pour FreeBSD sur RISC-V (GOOS=freebsd, GOARCH=riscv64).
Outils
Commande Go
Le répertoire $GOROOT/pkg ne stocke plus les archives de paquetages pré-compilés pour la bibliothèque standard : go install ne les écrit plus, go build ne les vérifie plus et la distribution Go ne les fournit plus. Au lieu de cela, les paquets de la bibliothèque standard sont construits selon les besoins et mis en cache dans le cache de construction, tout comme les paquets hors GOROOT. Ce changement réduit la taille de la distribution de Go et évite également le déséquilibre de la chaîne d'outils C pour les paquets qui utilisent cgo.
L'implémentation de go test -json a été améliorée pour la rendre plus robuste. Les programmes qui exécutent go test -json n'ont pas besoin de mises à jour. Les programmes qui invoquent directement l'outil go test2json doivent maintenant exécuter le binaire de test avec -v=test2json (par exemple, go test -v=test2json ou ./pkg.test -test.v=test2json) au lieu du simple -v.
Un changement lié à go test -json est l'ajout d'un événement dont l'action est définie pour démarrer au début de l'exécution de chaque programme de test. Lors de l'exécution de plusieurs tests à l'aide de la commande go, ces événements de démarrage sont garantis d'être émis dans le même ordre que les paquets nommés sur la ligne de commande.
La commande go définit désormais des balises de construction de caractéristiques d'architecture, telles que amd64.v2, pour permettre de sélectionner un fichier d'implémentation de paquet en fonction de la présence ou de l'absence d'une caractéristique d'architecture particulière. Les sous-commandes go acceptent désormais -C <dir> pour changer le répertoire en <dir> avant d'exécuter la commande, ce qui peut être utile pour les scripts qui doivent exécuter des commandes dans plusieurs modules différents.
- Les commandes go build et go test n'acceptent plus le paramètre -i, qui est déprécié depuis Go 1.16 ;
- La commande go generate accepte désormais -skip <pattern> pour ignorer les directives [C=Go]//go:generate[/Co] correspondant à <pattern> ;
- La commande go test accepte désormais -skip <pattern> pour ignorer les tests, les sous-tests ou les exemples correspondant à <pattern>.
Lorsque le module principal est situé dans GOPATH/src, go install n'installe plus les bibliothèques des paquets non principaux dans GOPATH/pkg, et go list ne signale plus de champ Target pour ces paquets.
Les commandes go build, go install et d'autres commandes liées à la compilation prennent désormais en charge l'option -pgo qui permet l'optimisation guidée par le profil. L'indicateur -pgo spécifie le chemin du fichier du profil. En spécifiant -pgo=auto, la commande go recherche un fichier nommé default.pgo dans le répertoire du paquet principal et l'utilise s'il est présent. Ce mode nécessite actuellement qu'un seul paquet principal soit spécifié sur la ligne de commande, mais cette restriction pourrait être levée dans une prochaine version. La spécification de -pgo=off désactive l'optimisation guidée par le profil.
Les commandes go build, go install et d'autres commandes liées à la construction prennent désormais en charge l'option -cover qui construit la cible spécifiée avec des instruments de couverture de code.
go version
La commande go version -m prend désormais en charge la lecture d'un plus grand nombre de types de binaires Go, notamment les DLL Windows construites avec go build -buildmode=c-shared et les binaires Linux sans autorisation d'exécution.
Cgo
La commande go désactive désormais cgo par défaut sur les systèmes ne disposant pas d'une chaîne d'outils C. Plus précisément, lorsque la variable d'environnement CGO_ENABLED n'est pas définie, que la variable d'environnement CC n'est pas définie et que le compilateur C par défaut (généralement clang ou gcc) n'est pas trouvé dans le chemin d'accès, CGO_ENABLED prend la valeur 0 par défaut.
L'effet le plus important de ce changement par défaut est que lorsque Go est installé sur un système sans compilateur C, il utilisera désormais des constructions Go pures pour les paquets de la bibliothèque standard qui utilisent cgo, au lieu d'utiliser les archives de paquets pré-distribuées (qui ont été supprimées, comme indiqué ci-dessus) ou d'essayer d'utiliser cgo et d'échouer. Cela permet à Go de mieux fonctionner dans certains environnements de conteneurs minimaux ainsi que sur macOS, où les archives de paquets pré-distribuées ne sont plus utilisées pour les paquets basés sur cgo depuis Go 1.16.
Les paquets de la bibliothèque standard qui utilisent cgo sont net, os/user et plugin. Sous macOS, les paquets net et os/user ont été réécrits pour ne pas utiliser cgo : le même code est maintenant utilisé pour les constructions cgo et non cgo ainsi que pour les compilations croisées. Sous Windows, les paquets net et os/user n'ont jamais utilisé cgo. Sur les autres systèmes, les compilations avec cgo désactivé utiliseront une version purement Go de ces paquets.
Sous macOS, le détecteur de course a été réécrit pour ne pas utiliser cgo : les programmes avec détecteur de course peuvent être construits et exécutés sans Xcode. Sous Linux et d'autres systèmes Unix, ainsi que sous Windows, une chaîne d'outils C hôte est nécessaire pour utiliser le détecteur de course.
Vet
Amélioration de la détection de la capture de variables de boucle par des fonctions imbriquées
L'outil vet signale maintenant les références aux variables de boucle suite à un appel à T.Parallel() dans les corps de fonctions de sous-tests. Ces références peuvent observer la valeur de la variable d'une itération différente (ce qui entraîne généralement le saut de cas de test) ou un état invalide dû à un accès concurrent non synchronisé.
L'outil détecte également les erreurs de référence dans plus d'endroits. Auparavant, il ne prenait en compte que la dernière instruction du corps de la boucle, mais il inspecte désormais de manière récursive les dernières instructions dans les instructions if, switch et select.
Moteur d'exécution
Le moteur d'exécution dispose désormais d'une prise en charge expérimentale de l'allocation d'arène à sécurité mémoire qui permet de libérer rapidement la mémoire en masse. Utilisée de manière appropriée, elle peut améliorer les performances de la CPU jusqu'à 15 % dans les applications gourmandes en allocation mémoire. Certaines structures de données internes du ramasse-miettes ont été réorganisées pour être à la fois plus efficaces en termes d'espace et de CPU. Ce changement réduit les frais généraux de mémoire et améliore les performances globales de la CPU jusqu'à 2 %.
Le ramasse-miette se comporte de manière moins erratique en ce qui concerne les aides goroutines dans certaines circonstances. Go 1.20 ajoute un nouveau paquet runtime/coverage contenant des API pour écrire des données de profil de couverture au moment de l'exécution à partir de programmes longs et/ou de programmes serveurs qui ne se terminent pas par os.Exit().
Compilateur
Go 1.20 ajoute le support de l'optimisation guidée par le profil (PGO). PGO permet à la chaîne d'outils d'effectuer des optimisations spécifiques à l'application et à la charge de travail sur la base des informations de profil d'exécution. Actuellement, le compilateur prend en charge les profils CPU pprof, qui peuvent être collectés par les moyens habituels, tels que les paquets runtime/pprof ou net/http/pprof. Pour activer PGO, passez le chemin d'un fichier de profil pprof via l'option -pgo à go build, comme mentionné ci-dessus.
Go 1.20 utilise PGO pour mettre en ligne de manière plus active les fonctions aux endroits où les appels sont importants. Les benchmarks pour un ensemble représentatif de programmes Go montrent que l'activation de l'optimisation de l'inline guidée par le profil améliore les performances d'environ 3-4 %. Le compilateur Go 1.20 a mis à jour son frontal pour utiliser une nouvelle façon de gérer les données internes du compilateur, ce qui corrige plusieurs bogues liés aux types génériques et permet d'utiliser des types locaux dans les fonctions et méthodes génériques.
Par rapport à Go 1.19, les performances du code généré sont généralement légèrement améliorées, les temps de mur de compilation sont légèrement augmentés, les temps d'utilisation de la compilation sont légèrement réduits.
Source : Golang
Et vous ?
Quels sont les changements qui captent votre attention pour Go 1.20 ? Quelles sont vos attentes ?
Voir aussi :
Répondre avec citation
Partager