Aller à la version 1.22

La version du langage de programmation Go 1.22 est présentée, développée par Google avec la participation de la communauté en tant que solution hybride combinant les hautes performances des langages compilés avec des avantages des langages de script tels que la facilité d'écriture de code. , rapidité de développement et protection contre les erreurs. Le code du projet est distribué sous licence BSD.

La syntaxe de Go est basée sur des éléments familiers du langage C avec quelques emprunts au langage Oberon. Le langage est assez concis, mais le code est facile à lire et à comprendre. Le code Go est compilé en fichiers exécutables binaires autonomes qui s'exécutent de manière native, sans utiliser de machine virtuelle (les modules de profilage, de débogage et d'autres sous-systèmes d'identification des problèmes au moment de l'exécution sont intégrés en tant que composants d'exécution), ce qui permet des performances comparables à celles des programmes C.

Le projet est initialement développé dans l'optique d'une programmation multithread et d'un fonctionnement efficace sur des systèmes multicœurs, notamment en fournissant des moyens au niveau opérateur pour organiser le calcul parallèle et l'interaction entre les méthodes exécutées en parallèle. Le langage offre également une protection intégrée contre les blocs de mémoire suralloués et offre la possibilité d'utiliser un garbage collector.

Parmi les changements de la nouvelle version :

• La prise en charge de la définition de plages d'entiers a été ajoutée aux boucles « for », par exemple, pour parcourir les valeurs de 0 à 9, vous pouvez désormais utiliser la boucle « for i := range 10 {...} ».
• Ajout de la prise en charge expérimentale (GOEXPERIMENT=rangefunc) des fonctions de plage dans les boucles for, vous permettant de spécifier une fonction comme itérateur. Par exemple, "pour i, x := range slices.Backward(s) {...}"
• Résolution d'un problème de longue date avec les boucles for qui entraînait des appels aux coroutines (goroutines) pour partager des variables de boucle entre les itérations. Par exemple, les valeurs de code := []string{"a", "b", "c"} pour _, v := range values ​​​​{ go func() { fmt.Println(v) done < - true }() } affichera désormais "a", "b" et "c", et pas seulement "c", comme c'était le cas auparavant.
• La gestion de la mémoire pendant l'exécution a été optimisée, ce qui a entraîné une augmentation des performances de 1 à 3 % et une réduction de la consommation de mémoire dans la plupart des applications de 1 %.
• Les travaux se sont poursuivis pour inclure des optimisations dans le compilateur basées sur les résultats du profilage de code (PGO - Profile-guided enhancement), qui permettent de prendre en compte les fonctionnalités déterminées lors de l'exécution du programme. Dans la nouvelle version, le compilateur utilise des outils de dévirtualisation pour remplacer les appels indirects de diverses méthodes par l'exécution de blocs en ligne étendus.
• Lorsque PGO a été activé, le changement ajouté a amélioré les performances de la plupart des programmes de 2 à 14 %.
• Une implémentation expérimentale améliorée (GOEXPERIMENT=newinliner) du mécanisme d'inlining d'appel a été ajoutée au compilateur, utilisant des heuristiques pour séparer les opérations importantes et sans importance.
• Le package « math/rand/v2 » a été ajouté à la bibliothèque standard, qui offre une API plus holistique et utilise des algorithmes plus rapides pour générer des nombres pseudo-aléatoires.
• Le package net/http.ServeMux a ajouté la possibilité de spécifier des méthodes et des masques dans les modèles, par exemple, le modèle « GET /static/{id}/ » sera appliqué aux requêtes avec la méthode HTTP « GET » et stockera le valeur du deuxième segment du chemin demandé dans l'identifiant « id".
• Le package database/sql a ajouté la prise en charge du type Null[T], vous permettant d'analyser les colonnes qui peuvent être NULL. Ajout de la fonction Concat au package slices pour fusionner plusieurs tranches de tout type.
• Dans les commandes permettant de travailler avec des espaces de travail (collections de modules), il est possible d'utiliser le répertoire « vendor », qui contient des dépendances au contenu de l'espace de travail. Le répertoire est créé lors de l'exécution de la commande « go work seller » et est utilisé dans les commandes de construction lorsque l'option « -mod=vendor » est définie (activée par défaut s'il existe un répertoire fournisseur).

Changements dans le comportement des services publics.

• go get n'est plus pris en charge en dehors d'un module en mode GOPATH hérité (c'est-à-dire avec GO111MODULE=off). D'autres commandes de build, telles que go build et go test, continueront à fonctionner indéfiniment pour les anciens programmes GOPATH.
• go mod init ne tente plus d'importer les exigences du module à partir des fichiers de configuration pour les outils d'autres fournisseurs (tels que Gopkg.lock).
• go test -cover imprime désormais les résumés de couverture pour les packages couverts qui n'ont pas leurs propres fichiers de test. Avant Go 1.22, un rapport de test et de couverture serait-il disponible pour un tel package ? mymod/mypack [pas de fichiers de test]

  et maintenant, depuis Go 1.22, les fonctions d'un package sont considérées comme non couvertes : couverture mymod/mypack : 0.0 % des déclarations Remarque : si un package ne contient aucun code exécutable, nous ne pouvons pas signaler un pourcentage significatif de couverture ; pour de tels packages, go test continuera à signaler les fichiers de test manquants.

• L'interface Web de l'outil de trace a été légèrement mise à jour dans le cadre du travail de prise en charge du nouveau traceur, corrigeant certains problèmes et améliorant la lisibilité de diverses pages. L'interface Web prend désormais en charge l'exploration des traces dans une vue thread-safe. La visionneuse de traces affiche désormais également la durée complète de tous les appels système. Ces améliorations s'appliquent uniquement à l'affichage des traces produites par les programmes construits sur Go 1.22 ou version ultérieure. Une prochaine version apportera certaines de ces améliorations aux traces produites par l’ancienne version de Go.
• Le runtime stocke désormais les métadonnées de garbage collection basées sur le type plus près de chaque objet de tas. Ce changement réduit également la surcharge de mémoire de la plupart des programmes Go d'environ 1 % en dédupliquant les métadonnées redondantes. Dans certains programmes, l'amélioration peut être moindre car cette modification ajuste les limites de classe de taille de l'allocateur de mémoire, de sorte que certains objets peuvent être déplacés vers une classe de taille supérieure. L'effet de ce changement est que les adresses de certains objets qui étaient auparavant toujours alignées sur une limite de 16 octets (ou plus) ne seront désormais alignées que sur une limite de 8 octets. Certains programmes qui utilisent des instructions d'assemblage qui nécessitent que les adresses mémoire soient alignées sur 8 octets et s'appuient sur le comportement d'alignement précédent de l'allocateur de mémoire peuvent échouer, mais nous nous attendons à ce que de tels programmes soient rares. De tels programmes peuvent être construits avec GOEXPERIMENT=noallocheaders avec la possibilité de revenir à l'ancien modèle de métadonnées et de restaurer le comportement d'alignement précédent, mais les propriétaires de packages doivent mettre à jour leur code assembleur pour éviter l'hypothèse d'alignement, car cette solution de contournement sera supprimée dans une version ultérieure. .
• Comme mentionné dans les notes de version de Go 1.20, Go 1.22 nécessite désormais la version finale de Go 1.20 ou une version ultérieure pour les versions initiales. Nous nous attendons à ce que Go 1.24 nécessite la version finale de Go 1.22 ou une version ultérieure pour la construction initiale.
  Original (go.dev)

Source: linux.org.ru