Go 1.15, la 16e version majeure du langage de programmation open source développé par Google, doit sortir le 1er août. Selon Ben Hoyt, ingénieur logiciel, cette version viendra avec moins de changements, toutefois de nombreuses améliorations majeures sont au programme, tel qu’un nouveau linker, qui accélérera les temps de construction et réduira la taille des binaires. Dans la mise à jour que Hoyt prévoit comme étant une solide mise à jour du langage, il y a également des améliorations de performance dans le temps d'exécution du langage, des changements dans les architectures prises en charge et quelques mises à jour de la bibliothèque standard, selon un article publié sur Lwn.net. Selon l’article, le modèle de développement de Go est assez différent de celui de la plupart des langues open source. En effet, de nombreuses autres langues proposent des fonctionnalités linguistiques importantes à chaque version, mais Go n'en a proposé que quelques-unes mineures dans les versions depuis la 1.0. L’équipe Go s’est plutôt constamment concentrée sur des améliorations dans l'outillage et à la bibliothèque standard avec chaque version.
Selon Hoyt, il s’agit d’un choix conscient de conception qui a permis à l’équipe de mettre l'accent sur la stabilité et la simplicité du langage depuis sa version 1.0. « La promesse de compatibilité de Go 1 garantit que tous les programmes écrits pour Go 1.0 continueront à fonctionner correctement, sans changement, pour toutes les versions 1.x. Les programmeurs Go considèrent généralement cela comme une bonne chose - leurs programmes continuent à "fonctionner", mais sont généralement plus rapides », lit-on dans l’article.
Comme on pouvait s’y attendre, les améliorations concernant l'outillage, les performances du compilateur et la bibliothèque standard ont encore pris le dessus dans la prochaine version majeure du langage, tandis que les changements dans la spécification du langage sont pratiquement inexistants. Comme le responsable technique chez Google Russ Cox l’a déjà fait remarquer, selon Hoyt, les principaux développeurs prévoient d'être extraconservateurs dans la version 1.15 à cause de la période de pandémie :
« Nous ne savons pas à quel point les deux prochains mois seront difficiles, alors soyons prudents et ne nous imposons pas un stress inutile en apportant les changements subtils de dernière minute que nous devrons déboguer. Laissez-les pour le début du prochain cycle, où ils auront le temps de s'imprégner de la situation. [...] Go 1.15 va être une mise à jour plus petite que d'habitude, et c'est bon ».
Voici les changements majeurs apportés dans Go 1.15 :
Un nouveau linker
L'un des plus grands changements apportés à l'outillage dans Go 1.15 est la réécriture intégrale du linker. Il comporte trois changements structurels majeurs qui sont les suivants :
Déplacement du travail du linker vers le compilateur : Cela permet la parallélisation, car les compilations sont effectuées en parallèle sur plusieurs CPU (ou machines), mais l'étape de liaison doit presque toujours être effectuée en série à la fin de la construction. De plus, les résultats du compilateur sont mis en cache par l'outil Go.
Amélioration des structures de données clés, principalement en évitant les chaînes de caractères : Le linker actuel utilise une grande table de symboles indexée par chaîne ; la nouvelle conception évite autant que possible les chaînes de caractères en utilisant une technique de numérotation des symboles.
Éviter de charger tous les fichiers objets d'entrée en mémoire en même temps : le nouveau linker utilise ainsi moins de mémoire pour les gros programmes, et alloue moins de mémoire globalement – le linker actuel passant plus de 20 % de son temps dans le garbage collector (GC).
Selon Than McIntosh qui travaille sur le nouveau linker, la plupart des améliorations structurelles dans le document de conception ont été réalisées, y compris le nouveau format de fichier objet et la représentation plus serrée des symboles. Les constructions sont déjà plus rapides et utilisent moins de mémoire qu'en 1.14, mais certaines fonctionnalités (par exemple, l'utilisation du format de débogage DWARF 5) devront attendre la version 1.16.
Austin Clements, un contributeur principal au projet Go qui a rédigé le document de conception du nouveau linker, a ajouté plus de détails sur les efforts de parallélisation, ainsi que sur la manière dont le travail est progressivement mis en place :
« Nous avons [...] également apporté de nombreuses autres améliorations en cours de route, comme la mise en parallèle des phases clés et la suppression de nombreuses synchronisations d'E/S inutiles. Afin de tirer le meilleur parti de tous les travaux antérieurs sur le linker, nous avons effectué cette conversion sous la forme d'un "frontwave", avec une phase de conversion de la nouvelle représentation à l'ancienne que nous avons repoussée de plus en plus loin dans le linker. Nous n'avons pas encore terminé : cette phase de conversion est toujours là, bien que le moment exact où elle se produit et ce qu'elle fait dépendent de la plateforme. Pour les plateformes amd64 ELF, elle est assez tardive et fait relativement peu de choses. Pour les autres plateformes, elle n'est pas aussi avancée et fait plus, donc les gains ne sont pas encore aussi importants. Quoi qu'il en soit, il y a plus à attendre pour la version 1.16 ».
Des binaires plus petits
Plusieurs améliorations liées à ce projet permettent de réduire la taille des exécutables construits avec Go 1.15. Le nouveau linker élimine beaucoup plus de code inutilisé, faisant passer un programme de test de 8,2 Mo dans Go 1.14 à 3,9 Mo dans 1.15. Pour les programmes plus réalistes, les tailles binaires diminuent de 3,5 % ou jusqu’à 22 %, selon Hoyt. « Un programme de serveur Web que j'exécute est passé de 21,4 Mo à 20,3 Mo, soit une réduction de 4,9 % », dit-il.
Selon Hoyt, l'élimination du code non utilisé dans le nouveau linker, ainsi que plusieurs améliorations ciblées, comme le CL 230544 de Clements, sont les principaux facteurs qui ont contribué à cette baisse. Il y a quelques autres améliorations mineures de la taille du binaire, comme la CL 228111 de Brad Fitzpatrick, qui évite d'inclure à la fois le code du client et du serveur TLS dans la sortie si un seul d'entre eux est utilisé, réduisant la taille d'un programme TLS dial hello world de 3,2 %.
Des Améliorations de la performance
Go 1.15 introduit de nombreuses améliorations mineures des performances, mais deux des plus notables proviennent d'un contributeur prolifique non Google, Josh Bleecher Snyder, lit-on dans l’article. CL 216401 évite d'allouer de la mémoire lors de la conversion de petits nombres entiers en une valeur d'interface, ce qui améliore de 2 % les temps de compilation à l'assemblage.
Le deuxième changement de Snyder est la CL 226367 dans les internes du compilateur et du runtime, ce qui permet au compilateur d'utiliser plus de registres x86 pour les appels à la barrière d'écriture du GC. Go utilise une barrière d'écriture (un peu comme un verrou) pour maintenir l'intégrité des données sur le tas lorsque le GC fonctionne en même temps que le code utilisateur. Il en résulte des binaires légèrement plus petits et une amélioration de 1 % des temps de compilation. Il y a bien d’autre amélioration de la performance dans Go 1.15.
Outillage et portages
La fonction "modules" de Go (le système de gestion des dépendances de Go) a été introduite pour la première fois dans Go 1.11, et la prise en charge d'un miroir de module ou "proxy" a été ajoutée dans 1.13. La version 1.15 ajoute la prise en charge d'un proxy de repli, permettant à l'outil Go de se replier sur un hôte secondaire si le premier échoue lors du téléchargement du code source du module. Les repliements sont spécifiés en utilisant le nouveau séparateur "|" de la variable d'environnement GOMODCACHE.
En ce qui concerne les changements dans les portages, Go 1.15 en supprimera deux anciens : darwin/386 et darwin/arm, qui fournissaient des binaires 32 bits sur macOS et d'autres systèmes d'exploitation Apple. Brad Fitzpatrick, l'un des acteurs principaux de l'équipe de développement du langage Go qui a annoncé son départ de Google en janvier, note que macOS Catalina ne supporte pas l'exécution d'applications 32 bits, donc la suppression de ces portages aidera à libérer les machines de construction de macOS ainsi qu'à réduire légèrement le compilateur. Ces portages avaient été annoncés comme obsolètes dans la version 1.14, et seront donc supprimés dans la version 1.15.
Sous Windows, Go 1.15 génère maintenant des exécutables qui utilisent par défaut la randomisation de la disposition des espaces d'adresses (ASLR). L'ASLR utilise un code indépendant de la position pour randomiser les adresses de diverses zones de données au démarrage, ce qui rend plus difficile pour les attaquants de prédire les adresses cibles et de créer des exploits de corruption de la mémoire.
Quant à la bibliothèque standard de Go, elle déjà est grande et assez stable, a rapporté Hoyt. Dans Go 1.15, seules des fonctionnalités relativement mineures ont été ajoutées.
Ces changements sont bien accueillis par certains commentateurs : « Excellent ! Il est agréable de voir ce genre d'améliorations des infrastructures ». Par contre, la promesse de compatibilité de Go 1.0 avec toutes les versions 1.x pose un problème à certains commentateurs. « Ce qui est amusant avec la promesse de compatibilité de Go, c'est qu'elle ne fonctionne pas aussi bien que les développeurs de Go l'imaginent probablement ; pas plus tard que la semaine dernière, on a découvert qu'un de mes anciens projets de Go était endommagé et ne pouvait plus être compilé. golang.org/x/crypto en était responsable, ils ont utilisé du code qui ne fonctionnait plus dans les compilateurs de Go plus modernes », a écrit l’un d’entre eux.
Un autre commentaire qui semble venir d’un développeur travaillant sur Go a confirmé le problème : « C'était la faute de golang.org/x/crypto d'avoir utilisé des éléments internes non couverts par la promesse de compatibilité, désolé pour ça. Cependant, nous essayons de maintenir x/crypto au même niveau de compatibilité que la bibliothèque standard, donc je pense que le simple fait de mettre à jour x/crypto en même temps aurait dû permettre une mise à jour en douceur ». Et vous, que pensez-vous de la prochaine version majeure de Go.
Source : Lwn
Et vous ?
Que pensez-vous de la version 1.15 de Go qui sera publiée en août ? Quels sont les changements qui attirent votre attention ?Lire aussi
La version 1.14 de Go est disponible avec une amélioration de performance, et compatible avec la version précédente Brad Fitzpatrick, l'un des acteurs principaux de l'équipe de développement du langage Go, quitte Google, afin de faire quelque chose de différent tout en travaillant avec Go et non plus sur Go Le langage Go continue sa progression avec de nombreux développeurs qui l'utilisent dans les projets professionnels et personnels, selon un sondage L'équipe Go revient sur le processus de développement de la version 2.0 du langage, et soumet des changements à venir dans Go 1.13