Les ports
Comme annoncé dans les notes de version de Go 1.10, Go 1.11 requiert désormais OpenBSD 6.2 ou une version ultérieure, macOS 10.10 Yosemite ou une version ultérieure, Windows 7 ou une version ultérieure; le support des versions précédentes de ces systèmes d'exploitation a été supprimé.
Go 1.11 prend en charge la prochaine version d'OpenBSD 6.4. En raison de changements dans le noyau OpenBSD, les anciennes versions de Go ne fonctionneront pas sous OpenBSD 6.4.
Le nettoyeur de mémoire (-msan) est désormais pris en charge sous linux / arm64.
Les modes de construction c-shared et c-archive sont désormais pris en charge sur freebsd / amd64.
Sur les systèmes MIPS 64 bits, les paramètres de la nouvelle variable d'environnement GOMIPS64 = hardfloat (valeur par défaut) et GOMIPS64 = softfloat permettent de sélectionner l'utilisation des instructions matérielles ou de l'émulation logicielle pour les calculs en virgule flottante. Pour les systèmes 32 bits, la variable d'environnement est toujours GOMIPS, comme ajouté dans Go 1.10.
Go 1.11 sur ARMv7 ne nécessite plus de noyau Linux configuré avec KUSER_HELPERS. Ce paramètre est activé dans les configurations de noyau par défaut, mais est parfois désactivé dans les configurations simplifiées.
WebAssembly
Go 1.11 ajoute un port expérimental à WebAssembly (js / wasm).
Les programmes Go compilent actuellement un module WebAssembly qui inclut l'environnement d'exécution Go pour la planification des routines, les cartes, etc. La taille résultante est au minimum d'environ 2 Mo ou 500 Ko compressés. Les programmes Go peuvent appeler JavaScript en utilisant le nouveau package expérimental syscall / js. La taille binaire et l'interopérabilité avec d'autres langages n'ont pas encore été une priorité mais peuvent être abordées dans les prochaines versions.
À la suite de l'ajout de la nouvelle valeur GOOS "js" et de la valeur GOARCH "wasm", les fichiers Go nommés * _js.go ou * _wasm.go seront désormais ignorés par les outils Go, sauf lorsque ces valeurs GOOS / GOARCH sont utilisées. . Si vous avez des noms de fichiers existants correspondant à ces modèles, vous devrez les renommer.
Outils
Modules, gestion des versions de packages et gestion des dépendances
Go 1.11 ajoute un support préliminaire pour un nouveau concept appelé "modules", une alternative à GOPATH avec un support intégré pour le contrôle de version et la distribution de paquets. En utilisant des modules, les développeurs ne sont plus confinés à travailler au sein de GOPATH, les informations de dépendance de version sont explicites mais légères et les builds sont plus fiables et reproductibles.
Le support de module est considéré comme expérimental. Les détails sont susceptibles de changer en réponse aux commentaires des utilisateurs de Go 1.11, et d’autres outils sont prévus. Bien que les détails de la prise en charge des modules puissent changer, les projets qui convertissent en modules à l'aide de Go 1.11 continueront à fonctionner avec Go 1.12 et versions ultérieures. Si vous rencontrez des bogues en utilisant des modules, veuillez enregistrer les problèmes afin que l’équipe responsable du développement de Go puisse les corriger.
Restriction de chemin d'importation
Étant donné que la prise en charge du module Go attribue une signification particulière au symbole @ dans les opérations de ligne de commande, la commande go interdit désormais l'utilisation de chemins d'importation contenant des symboles @. Ces chemins d'importation n'ont jamais été autorisés par go get, donc cette restriction ne peut affecter que les utilisateurs qui créent des arborescences GOPATH personnalisées par d'autres moyens.
Chargement du paquet
Le nouveau package golang.org/x/tools/go/packages fournit une API simple pour localiser et charger les paquets du code source de Go. Bien que cela ne fasse pas encore partie de la bibliothèque standard, pour de nombreuses tâches, il remplace efficacement le package go / build, dont l’API ne prend pas entièrement en charge les modules. Comme il exécute une commande de requête externe telle que go list pour obtenir des informations sur les packages Go, il permet la construction d'outils d'analyse qui fonctionnent aussi bien avec des systèmes de construction alternatifs tels que Bazel et Buck.
Chaîne d'outils du compilateur
Plus de fonctions sont désormais éligibles par défaut, y compris les fonctions appelant panic.
La chaîne d'outils du compilateur prend désormais en charge les informations de colonne dans les directives de ligne.
Un nouveau format de données d'exportation de package a été introduit. Cela devrait être transparent pour les utilisateurs finaux, sauf pour accélérer les temps de construction des grands projets Go. Si cela pose des problèmes, il peut être désactivé à nouveau en transmettant -gcflags = all = -iexport = false à l'outil go lors de la construction d'un fichier binaire.
Le compilateur rejette maintenant les variables inutilisées déclarées dans un garde de type switch, tel que x dans l'exemple suivant:
Code : | Sélectionner tout |
1 2 3 4 | func f(v interface{}) { switch x := v.(type) { } } |
Toutes les modifications apportées à la bibliothèque standard sont mineures. L’équipe assure que la bibliothèque comporte plusieurs modifications et mises à jour mineures, en tenant compte de la compatibilité avec la promesse Go 1.
crypto
Certaines opérations cryptographiques, dont ecdsa.Sign, rsa.EncryptPKCS1v15 et rsa.GenerateKey, lisent maintenant de manière aléatoire un octet supplémentaire de caractère aléatoire pour garantir que les tests ne reposent pas sur un comportement interne.
crypto / cipher
La nouvelle fonction NewGCMWithTagSize implémente le mode Compteur Galois avec des longueurs de balises non standard pour assurer la compatibilité avec les cryptosystèmes existants.
crypto / rsa
PublicKey implémente maintenant une méthode Size qui renvoie la taille du module en octets.
crypto / tls
La nouvelle méthode ExportKeyingMaterial de ConnectionState permet d’exporter du matériel de chiffrement lié à la connexion conformément à la RFC 5705.
crypto / x509
Le comportement obsolète hérité consistant à traiter le champ CommonName comme un nom d'hôte lorsque aucun autre nom de sujet n'est présent est désormais désactivé lorsque le CN n'est pas un nom d'hôte valide. CommonName peut être complètement ignoré en ajoutant la valeur expérimentale x509ignoreCN = 1 à la variable d'environnement GODEBUG. Lorsque le CN est ignoré, les certificats sans SAN valident les sous-chaînes avec des contraintes de nom au lieu de renvoyer NameConstraintsWithoutSANs.
Les restrictions d'utilisation des clés étendues ne sont à nouveau vérifiées que si elles apparaissent dans le champ KeyUsages de VerifyOptions, au lieu d'être toujours vérifiées. Cela correspond au comportement de Go 1.9 et versions antérieures.
La valeur renvoyée par SystemCertPool est maintenant mise en cache et peut ne pas refléter les modifications du système entre les invocations.
Source : note de version
Voir aussi :
Le langage Go se dote d'un nouveau logo, une première étape dans la refonte de l'image du langage, la mise à jour du site sera la prochaine étape
Emploi développeur 2017 : les langages les plus demandés et les mieux payés, Java, JavaScript et PHP plus demandés, mais Perl, Go et Scala mieux payés
RedMonk janvier 2018 : Go semble déjà essoufflé et Swift rattrape Objective-C alors que Kotlin est en pleine ascension dans le classement