Suppression des types centraux (Core Types) et évolution simplifiée du langage Go

• Avec l’introduction des generics dans Go 1.18, un nouveau concept, les types centraux (core types), avait été ajouté, mais il a été décidé de les supprimer en 1.25
• Les types centraux étaient un concept abstrait destiné à faciliter l’implémentation du compilateur, en remplaçant le type sous-jacent (underlying type) existant lors du traitement des opérandes de types génériques
• Dans la spécification du langage aussi, le « type sous-jacent » a été remplacé par le « type central »

Paramètres de type et contraintes de type

• Les paramètres de type servent de placeholders pour des types qui seront déterminés plus tard, au moment de la compilation
• Les contraintes de type déterminent les opérations possibles sur le type du paramètre concerné
• En Go, les contraintes de type sont définies en combinant des exigences de méthodes et de types, ce qui permet de former un ensemble de types (type set)
• Un ensemble de types désigne l’ensemble de tous les types qui satisfont une interface donnée

  type Constraint interface {
    ~[]byte | ~string
    Hash() uint64
  }
  

• Cette approche fondée sur les ensembles de types est très souple et puissante pour définir les opérations sur les types génériques

  func at[bytestring Constraint](s bytestring, i int) byte {
    return s[i]
  }
  

Introduction des types centraux et leurs limites

• Les types centraux ont été définis comme une règle destinée à simplifier l’usage des types génériques dans certaines opérations
• Méthode de définition des types centraux :
  • Dans le cas d’un type ordinaire, le type central est identique à son type sous-jacent
  • Dans le cas d’un paramètre de type, un type central n’existe que si tous les types de l’ensemble de types possèdent le même type sous-jacent
• Mais cette approche a entraîné les problèmes suivants :
  • La spécification du langage est devenue plus complexe, rendant difficiles à comprendre même des règles simples
  • Le concept de type central était mentionné inutilement même dans du code non générique
  • Certaines opérations utilisant le concept de type central sont devenues excessivement restrictives, au point de ne pas autoriser des opérations pourtant sûres en pratique
  • Le manque de cohérence avec les règles qui n’utilisent pas les types centraux a réduit la cohérence d’ensemble de la conception du langage

Suppression des types centraux dans Go 1.25

• Avec la sortie de Go 1.25 (prévue pour août 2025), il a été décidé de supprimer le concept de type central de la spécification du langage
• La spécification évolue vers une formulation explicite, opération par opération, des contraintes nécessaires
• Principaux effets de ce changement :
  • Réduire le nombre de concepts, ce qui facilitera l’apprentissage de Go
  • Rendre le code non générique plus clair, sans dépendance à des concepts liés aux generics
  • Permettre des règles plus souples selon les opérations concernées
  • Poser les bases de futures extensions du langage (par ex. accès à des champs communs, amélioration des fonctionnalités sur les slices, amélioration de l’inférence de types, etc.)

Principales applications et effets attendus

• Toutes les formulations de la spécification mentionnant les types centraux sont supprimées ou remplacées par des phrases explicites
• Le terme « type central » disparaît aussi des messages d’erreur du compilateur, remplacé par des explications plus précises
• Le comportement des programmes Go existants n’est pas affecté
• La spécification du langage devient plus simple et, du point de vue des utilisateurs, Go devient plus intuitif et plus clair

[GN⁺]

Avis Hacker News

• J’apprécie que l’équipe Go traite les changements de spécification avec beaucoup de prudence

  • Les génériques de Go constituent un grand changement et peuvent être difficiles à utiliser
  • Je pense que les contraintes empêchent une utilisation excessive des génériques
  • J’ai vu des cas, dans des projets Java et Typescript, où une utilisation excessive du système de types rend le code peu clair
  • J’espère que l’équipe Go continuera d’aborder le langage de manière conservatrice

• Les dix dernières années de l’équipe de développement de Go ont été une quête d’équilibre entre fonctionnalités et simplicité

  • Les génériques illustrent bien cette dynamique
  • Implémenter au-dessus de Go un système de types comme celui de Rust ajoute trop de complexité
  • Un léger retour vers une direction privilégiant la simplicité est bienvenu
  • Go vise à être un meilleur Java pour des équipes d’ingénieurs de niveau intermédiaire

• Go 1.25 n’ajoute pas réellement de nouvelles fonctionnalités au langage

  • Les sum types pourraient être ajoutés en 1.30

• Je suis Go depuis avant les builds Windows

  • Tout ce que j’ai appris en 2011 est encore valable aujourd’hui
  • Je n’ai pas eu l’occasion de travailler avec Go, mais je l’ai appris à travers de petits projets
  • J’avais été déçu d’entendre, lors d’un entretien avec un développeur Go, que les génériques ne seraient probablement pas introduits dans Go
  • Maintenant que les génériques ont été introduits, je prévois de démarrer un projet perso en Go

• Il n’est pas exact de dire que, lorsque l’argument de close est un paramètre de type, tous les types doivent être des canaux avec le même type d’élément

  • Le type d’élément n’a pas d’effet sur close, et la compilation fonctionne très bien même avec un ensemble de types ayant des types d’élément différents
  • La documentation doit être améliorée
  • J’espère que l’extension de la flexibilité, comme avec les champs partagés, va s’accélérer

• J’apprends Go lentement et je viens d’un background C++

  • Je me demande si c’est similaire à la spécialisation de templates
  • J’aimerais que davantage de langages prennent cela en charge

• [mort]

• Maintenant que l’IA générative peut écrire du code, je me demande si le ramasse-miettes est toujours nécessaire

[aer0700]

Maintenant que l’IA générative peut écrire du code, on se demande si le ramasse-miettes est encore nécessaire.
> C’est évocateur...

[galadbran]

Oh là… Si l’IA atteint le niveau où elle peut produire ce genre de code (du code qui gère parfaitement la mémoire), il sera sans doute difficile pour les développeurs humains de conserver le même rôle qu’aujourd’hui.

[kandk]

On peut résoudre 1+1=2 avec les mathématiques, alors pourquoi vouloir absolument le résoudre avec l’IA…

[jeiea]

Le GC n’a-t-il pas aussi un intérêt quand il s’agit de réduire le boilerplate lisible par des humains et le contexte de code à suivre ?
Si vous prévoyez qu’il n’y aura même plus besoin de lire le code, alors là je ne sais pas.
Vu que le commentaire d’origine est lui aussi grisé, il ne semble pas avoir suscité une grande adhésion.

[savvykang]

Ne peut-on pas supprimer le comptage de références lorsqu’il est possible de calculer au moment de la compilation quand la mémoire est allouée et libérée ? Il semble que l’auteur du commentaire original sur Hacker News ne comprenne pas le problème de la réutilisation de la mémoire.