3 pièce(s) jointe(s)
L'équipe en charge du développement de Go annonce la disponibilité de la version Go 1.12
L'équipe en charge du développement de Go annonce la disponibilité de la version Go 1.12,
qui s'accompagne d'un support amélioré des modules
La dernière version de Go, version 1.12, arrive six mois après Go 1.11. La plupart de ses modifications concernent l'implémentation de la chaîne d'outils, du moteur d'exécution et des bibliothèques.
Modules
Lorsque GO111MODULE est défini sur on, la commande go prend désormais en charge les opérations prenant en charge le module en dehors d'un répertoire de module, à condition que ces opérations n'aient pas besoin de résoudre les chemins d'importation relatifs au répertoire actuel ni de modifier explicitement le fichier go.mod. Les commandes telles que go get, go list et go mod download se comportent comme si elles se trouvaient dans un module dont les exigences étaient initialement vides. Dans ce mode, go env GOMOD indique le périphérique nul du système (/ dev / null ou NUL).
Les commandes go qui téléchargent et extraient les modules peuvent désormais être appelées simultanément. Le cache de module (GOPATH / pkg / mod) doit résider dans un système de fichiers prenant en charge le verrouillage de fichier.
La directive go dans un fichier go.mod indique maintenant la version du langage utilisée par les fichiers de ce module. Elle sera définie sur la version actuelle (cf. 1.12) si aucune version existante n’est présente. Si la directive go d'un module spécifie une version plus récente que la chaîne d'outils utilisée, la commande go tentera de générer les packages indépendamment et notera l'incompatibilité uniquement si cette génération échoue.
Lorsqu'une importation ne peut pas être résolue à l'aide des modules actifs, la commande go va tenter d'utiliser les modules mentionnés dans les directives de remplacement du module principal avant de consulter le cache du module et les sources réseau habituelles. Si un remplacement correspondant est trouvé mais que la directive replace ne spécifie pas de version, la commande go utilise une pseudo-version dérivée de zero time.Time (telle que v0.0.0-00010101000000-000000000000).
Chaîne d'outils du compilateur
L'analyse des variables en direct du compilateur s'est améliorée. Cela peut signifier que les finaliseurs seront exécutés plus tôt dans cette version que dans les versions précédentes. Si cela pose un problème, envisagez l’ajout approprié d’un appel runtime.KeepAlive.
De plus en plus de fonctions sont désormais éligibles pour une extension inline par défaut, y compris les fonctions qui n’appellent que d’autres fonctions. Cette intégration supplémentaire rend également important l'utilisation de runtime.CallersFrames au lieu d'itérer directement le résultat de runtime.Callers. Rappelons qu'en informatique, l'extension inline, ou inlining, est une optimisation d'un compilateur qui remplace un appel de fonction par le code de cette fonction. Cette optimisation vise à réduire le temps d'exécution ainsi que la consommation mémoire. Toutefois, l'extension inline peut augmenter la taille du programme (par la répétition du code d'une fonction).
Certains langages (par exemple le C ou le C++) ont un mot clé inline attachable à la définition d'une fonction. Ce mot clé indique au compilateur qu'il devrait essayer d'étendre cette fonction. Le compilateur pourra ensuite utiliser plusieurs heuristiques pour décider quelle fonction doit être étendue inline.
Code:
1
2
3
4
5
6
7
8
9
| // Ancien code qui ne fonctionne plus correctement (il va manquer des inlined call frames)
var pcs [10]uintptr
n := runtime.Callers(1, pcs[:])
for _, pc := range pcs[:n] {
f := runtime.FuncForPC(pc)
if f != nil {
fmt.Println(f.Name())
}
} |
Code:
1
2
3
4
5
6
7
8
9
10
11
| // Nouveau code qui fonctionne correctement.
var pcs [10]uintptr
n := runtime.Callers(1, pcs[:])
frames := runtime.CallersFrames(pcs[:n])
for {
frame, more := frames.Next()
fmt.Println(frame.Function)
if !more {
break
}
} |
Les wrappers générés par le compilateur pour implémenter les expressions de méthode ne sont plus signalés par runtime.CallersFrames et runtime.Stack. Ils ne sont également pas imprimés dans les traces de pile de panique. Cette modification aligne la chaîne d’outils gc sur la chaîne d’outils gccgo, qui supprimait déjà ces wrappers des traces de pile. Les clients de ces API peuvent avoir besoin d'ajuster les images manquantes. Pour le code devant interagir entre les versions 1.11 et 1.12, vous pouvez remplacer l'expression de méthode x.M par la fonction literal func (...) {x.M (...)}.
Le compilateur accepte maintenant un indicateur -lang pour définir la version de langage Go à utiliser. Par exemple, -lang = go1.8 amène le compilateur à émettre une erreur si le programme utilise des alias de type, qui ont été ajoutés dans Go 1.9. Les modifications de langage effectuées avant Go 1.12 ne sont pas systématiquement appliquées.
La chaîne d’outils du compilateur utilise désormais différentes conventions pour appeler des fonctions Go et des fonctions d’assemblage. Cela devrait être invisible pour les utilisateurs, sauf pour les appels qui traversent simultanément Go et assembly et franchissent les limites d'un paquet.
De nombreuses améliorations ont été apportées aux informations de débogage DWARF générées par le compilateur, notamment à l’impression des arguments et aux informations d’emplacement des variables.
Que signifie "panique" ?
La manière idiomatique de gérer des conditions anormales dans un programme en Go consiste à utiliser des erreurs. Les erreurs sont suffisantes pour la plupart des conditions anormales apparues dans le programme.
Mais il existe des situations où le programme ne peut simplement pas continuer à s'exécuter après une situation anormale. Dans ce cas, nous utilisons la panique pour terminer le programme. Lorsqu'une fonction rencontre une panique, son exécution est arrêtée, toutes les fonctions différées sont exécutées, puis le contrôle revient à l'appelant. Ce processus se poursuit jusqu'à ce que toutes les fonctions de la goroutine actuelle soient retournées. Le programme imprime alors le message de panique, suivi de la trace de la pile, puis se termine.
La trace de pile fournit, dans la plupart des cas, suffisamment d’informations pour identifier l’endroit où se produit la panique (dans cet exemple). Elle montre la chaîne d'appels de fonction et le fichier source avec le numéro de ligne auquel la fonction a été appelée.
Runtime
Le moteur d’exécution Go libère maintenant la mémoire dans le système d’exploitation de manière plus agressive, en particulier en réponse à des allocations importantes qui ne peuvent pas réutiliser l’espace de tas existant.
Le minuteur et le code de délai du runtime de Go sont plus rapides et s'adaptent mieux à un nombre plus élevé de processeurs. Cela améliore notamment les performances de manipulation des délais de connexion réseau.
Sous Linux, le runtime utilise maintenant MADV_FREE pour libérer de la mémoire inutilisée. Ceci est plus efficace mais peut entraîner une augmentation du RSS signalé. Le noyau récupérera les données inutilisées lorsque cela sera nécessaire. Pour revenir au comportement de Go 1.11 (MADV_DONTNEED), définissez la variable d'environnement GODEBUG = madvdontneed = 1.
L'ajout de cpu.extension = off à la variable d'environnement GODEBUG désactive désormais l'utilisation des extensions de jeu d'instructions d'UC facultatives dans la bibliothèque standard et au moment de l'exécution. Ceci n'est pas encore supporté sous Windows.
Go 1.12 améliore la précision des profils de mémoire en corrigeant le sur-comptage d'allocations de tas importantes.
Les services de trace, runtime.Caller et runtime.Callers n'incluent plus les fonctions d'initialisation générées par le compilateur. Faire une trace lors de l'initialisation d'une variable globale montrera maintenant une fonction nommée PKG.init.ializers.
Bibliothèque de base
TLS 1.3
Go 1.12 ajoute la prise en charge de l’inscription pour TLS 1.3 dans le paquet crypto / tls, comme spécifié par la RFC 8446. Pour l’activer, ajoutez la valeur tls13 = 1 à la variable d’environnement GODEBUG. Elle sera activée par défaut dans Go 1.13.
Pour négocier TLS 1.3, assurez-vous de ne pas définir une MaxVersion explicite dans Config et exécutez votre programme avec la variable d'environnement GODEBUG = tls13 = 1 set.
Toutes les fonctionnalités de TLS 1.2, à l'exception de TLSUnique dans ConnectionState et de la renégociation, sont disponibles dans TLS 1.3 et fournissent une sécurité et des performances équivalentes ou supérieures. Notez que même si TLS 1.3 est rétrocompatible avec les versions précédentes, certains systèmes hérités risquent de ne pas fonctionner correctement lors de la tentative de négociation. Les clés de certificat RSA trop petites pour être sécurisées (y compris les clés 512 bits) ne fonctionneront pas avec TLS 1.3.
Les suites de chiffrement TLS 1.3 ne sont pas configurables. Toutes les suites de chiffrement prises en charge sont sécurisées et, si PreferServerCipherSuites est défini dans Config, l'ordre de préférence est basé sur le matériel disponible.
Les données antérieures (également appelées "mode 0-RTT") ne sont actuellement pas prises en charge en tant que client ou serveur. De plus, un serveur Go 1.12 ne prend pas en charge le saut de données initiales inattendues si un client les envoie. Étant donné que le mode 0-RTT de TLS 1.3 implique que les clients conservent l'état des serveurs prenant en charge 0-RTT, un serveur Go 1.12 ne peut pas faire partie d'un pool d'équilibrage de charge sur lequel d'autres serveurs prennent en charge 0-RTT. Si vous passez d'un domaine d'un serveur prenant en charge 0-RTT à un serveur Go 1.12, vous devrez le désactiver au moins pendant la durée de vie des tickets de session émis avant le basculement pour assurer un fonctionnement ininterrompu.
Source : note de version
Voir aussi :
:fleche: « Pourquoi on est repassé de Go à PHP ? », Danny van Kooten, l'éditeur de MailChimp nous livre les raisons de ce rebasculement
:fleche: Google prévoit d'apporter un support plus affiné aux modules dans Go 1.12, l'entreprise donne des détails aux développeurs
:fleche: 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
