Sortie de Go 1.24

• Go 1.24 est une mise à jour officielle après Go 1.23, qui couvre un large éventail de changements directement perceptibles par les développeurs, des fonctionnalités du langage au runtime, à la bibliothèque standard et à WebAssembly
• Côté langage, la version prend entièrement en charge les alias de types génériques, ce qui permet de paramétrer les alias de types comme les types définis
• Le runtime affiche en moyenne une réduction de 2 à 3 % de l’overhead CPU dans les benchmarks représentatifs, grâce notamment aux map basées sur Swiss Tables, à l’amélioration de l’allocation des petits objets et à des changements dans les mutex internes
• La commande go ajoute un flux pour suivre et exécuter les dépendances d’outils d’un module, tandis que go vet détecte mieux les erreurs de déclaration liées aux tests
• La bibliothèque standard et la prise en charge des plateformes s’étendent également : FIPS 140-3, testing.B.Loop, os.Root, runtime.AddCleanup, go:wasmexport et les builds WASI reactor/library sont à examiner

---

Périmètre des changements de Go 1.24

• Go 1.24 est une version qui apporte plusieurs améliorations par rapport à Go 1.23 ; la liste complète des changements est disponible dans les notes de version de Go 1.24
• La nouvelle version peut être téléchargée depuis la page de téléchargement de Go

Changement du langage : alias de types génériques

• Go 1.24 prend entièrement en charge les alias de types génériques
• Les alias de types peuvent désormais être paramétrés comme les types définis, ce qui élargit les possibilités d’expression dans le code générique
• La syntaxe détaillée figure dans la spécification du langage

Améliorations des performances du runtime

• Grâce aux améliorations du runtime, l’overhead CPU diminue en moyenne de 2 à 3 % sur un ensemble de benchmarks représentatifs
• Les principaux axes de cette évolution des performances sont au nombre de trois
  • Une nouvelle implémentation intégrée de map basée sur les Swiss Tables
  • Une allocation mémoire plus efficace pour les petits objets
  • Une nouvelle implémentation des mutex internes du runtime

Améliorations des outils Go

• La commande go fournit un mécanisme pour suivre les dépendances d’outils d’un module
  • go get -tool ajoute une directive tool au module courant
  • go tool [tool name] exécute un outil déclaré dans la directive tool
  • Plus de détails figurent dans la section go command des notes de version
• Une nouvelle analyse test est ajoutée à la sous-commande go vet
  • Elle signale les erreurs courantes dans les déclarations de tests, fuzzers, benchmarks et exemples des packages de test
  • Plus de détails figurent dans la section vet des notes de version

Ajouts à la bibliothèque standard et aux API du runtime

• La bibliothèque standard inclut un ensemble de nouveaux mécanismes aidant à la conformité FIPS 140-3
  • Aucune modification du code source des applications n’est nécessaire pour utiliser les nouveaux mécanismes avec les algorithmes approuvés
  • Plus de détails figurent dans la section conformité FIPS 140-3 des notes de version
• Outre FIPS 140, plusieurs packages auparavant présents dans le module x/crypto sont désormais fournis dans la bibliothèque standard
• Le code de benchmark peut utiliser la méthode testing.B.Loop
  • Elle permet d’exécuter les itérations de benchmark sous la forme for b.Loop() { ... }
  • Elle peut remplacer la structure de boucle courante utilisant b.N, comme for range b.N
  • Cette approche est plus rapide et moins sujette aux erreurs
• Le nouveau type os.Root permet d’effectuer des opérations de système de fichiers isolées sous un répertoire spécifique
• Le runtime ajoute un nouveau mécanisme de nettoyage, runtime.AddCleanup
  • Il est plus flexible, plus efficace et moins sujet aux erreurs que runtime.SetFinalizer

Améliorations de la prise en charge de WebAssembly

• Go 1.24 ajoute une nouvelle directive go:wasmexport permettant aux programmes Go d’exporter des fonctions vers un hôte WebAssembly
• Les programmes Go peuvent être compilés en WASI reactor/library
• Plus de détails figurent dans la section WebAssembly des notes de version

Indications de suivi et retours

• Toutes les informations détaillées figurent dans les notes de version de Go 1.24
• Certains sujets seront traités plus en profondeur dans de futurs articles de blog
• En cas de problème, il est possible d’ouvrir une issue

[GN⁺]

Avis sur Hacker News

• L’implémentation de map plus rapide est particulièrement bienvenue, et c’est aussi une bonne chose que text/template prenne désormais en charge range-over-func
  Go 1.23 a introduit range sur les types fonction, mais cela ne fonctionnait pas jusqu’ici dans les templates Go

• J’aime bien le côté presque ennuyeusement sans surprise

• Je me demande à quoi servira os.Root
  D’après ce que j’ai compris, cela semble lié à la sécurité, comme dans https://github.com/golang/go/issues/67002, mais comme ça n’utilise pas Chroot en interne, j’ai l’impression que quelqu’un pourrait finir par trouver un moyen de sortir de Root

  • chroot n’a de sens que lorsqu’une application peut affirmer qu’elle ne fonctionnera que dans un seul répertoire à l’avenir
    En plus, le processus doit disposer des privilèges superutilisateur, donc ce n’est pas utilisable pour les applications exécutées avec des droits utilisateur normaux
    os.Root() ressemble davantage à une ceinture de sécurité pour les opérations sur le système de fichiers. Par exemple, limiter les opérations liées au cache d’une application au répertoire de cache, ou faire en sorte qu’un serveur de fichiers ne serve que les fichiers situés dans le bon répertoire partagé. Ce n’est pas une garantie absolue comme chroot, mais ça bloque les attaques simples par traversée de répertoires
  • Je ne vois pas pourquoi il faudrait utiliser chroot
    Avec des fonctions de sandboxing comme Capsicum, on peut ouvrir un répertoire avant d’entrer en mode capability, puis utiliser ensuite os.Root pour ouvrir des fichiers dans l’arborescence du système de fichiers sous ce répertoire ouvert

• Je me demande s’il est possible de spécifier les tags à utiliser lors de l’installation des outils indiqués par la directive tools
  J’ai essayé comme ci-dessous, mais il semble que l’installation se fasse sans tags
  go install -tags 'postgres' github.com/golang-migrate/migrate/v4/cmd/migrate@latest

• Il est indiqué qu’avec GODEBUG=fips140=only, les algorithmes cryptographiques non conformes à FIPS 140-3 renvoient une erreur ou provoquent un panic, mais je n’aime pas trop l’idée qu’une bibliothèque standard fasse intentionnellement un panic
  Je n’ai pas encore regardé le code, mais je me demande si cela ne concerne que les fonctions qui, pour des raisons de compatibilité descendante, ne renvoient actuellement pas d’erreur

  • C’est une fonctionnalité nécessaire dans les environnements gouvernementaux
    Si l’on ne vérifie pas à l’exécution que FIPS est activé, on risque de rompre la conformité, ce qui finit par mener à des audits et à des réunions sans fin. À mon avis, une panne de 30 minutes due à un panic vaut largement mieux que de passer des jours à mettre en place de nouveaux contrôles et procédures de validation
  • Dans ce cas, il suffit de ne pas définir ce flag
    Ce comportement est utile pour des situations détectables uniquement à l’exécution. Même une couverture de tests basique devrait le révéler immédiatement
  • La seule alternative réaliste est de renvoyer une erreur, mais une erreur peut être attrapée puis ignorée
    Je me demande si c’est souhaitable dans un contexte de chiffrement. Je pense qu’il faut éviter le niveau « avertissement » dans les logs. Si c’est important et actionnable, cela doit être une erreur ou un log fatal ; sinon, un log d’information suffit
  • J’ai lu que cette partie devrait être clarifiée dans Go 1.25
    https://devblogs.microsoft.com/go/go-1-24-fips-update/
  • Comme le disent les commentaires voisins, il faut parfois imposer les choses
    On peut aussi voir cela comme une manière d’éviter des bugs cachés. C’est similaire à « The server chose violence » [1] [2], et il vaut aussi la peine de réfléchir à la manière dont la loi de Postel a freiné l’interopérabilité. C’est un point souvent oublié dans plusieurs aspects de la certification FIPS
    [1] https://cliffle.com/blog/hubris-reply-fault/
    [2] https://news.ycombinator.com/item?id=40178652

• Les alias de types génériques sont enfin là, c’était une fonctionnalité nécessaire depuis longtemps

• Le nouveau flag tool est ce que j’attends le plus. On va enfin pouvoir se débarrasser des moches tools.go

• Bien. J’attendais cette version à cause de GOAUTH
  J’espère que le travail avec des dépôts git privés deviendra moins pénible, mais en regardant go help goauth, il semble difficile d’en attendre beaucoup