La eliminación de los tipos núcleo (Core Types) y la evolución concisa del lenguaje Go

• Con la introducción de los genéricos (generics) en Go 1.18, se agregó un nuevo concepto llamado tipo núcleo (core type), pero se decidió eliminarlo en la versión 1.25
• El tipo núcleo era un concepto abstracto pensado para facilitar la implementación del compilador, y reemplazaba al tipo subyacente (underlying type) existente al procesar operandos de tipos genéricos
• En la especificación del lenguaje también se sustituyó el uso del "tipo subyacente" por el de "tipo núcleo"

Parámetros de tipo y restricciones de tipo

• Los parámetros de tipo actúan como marcadores de posición para tipos que se determinarán en el futuro, y se resuelven en tiempo de compilación
• Las restricciones de tipo determinan qué operaciones son posibles para ese tipo de parámetro
• En Go, las restricciones de tipo se definen combinando requisitos de métodos y de tipos, formando así un conjunto de tipos (type set)
• Un conjunto de tipos se refiere al conjunto de todos los tipos que satisfacen una interfaz específica

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

• Este enfoque basado en conjuntos de tipos es muy flexible y potente para definir operaciones sobre tipos genéricos

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

La introducción de los tipos núcleo y sus límites

• El tipo núcleo se definió como una regla para simplificar el uso de tipos genéricos en algunas operaciones
• Forma de definir un tipo núcleo:
  • En el caso de un tipo normal, el tipo núcleo es igual al tipo subyacente de ese tipo
  • En el caso de un parámetro de tipo, solo existe un tipo núcleo si todos los tipos dentro del conjunto de tipos comparten el mismo tipo subyacente
• Sin embargo, este enfoque provocó los siguientes problemas:
  • La especificación del lenguaje se volvió más compleja, haciendo difícil de entender incluso reglas simples
  • El concepto de tipo núcleo se mencionaba innecesariamente incluso en código no genérico
  • Algunas operaciones que dependen del concepto de tipo núcleo se volvieron demasiado restrictivas, por lo que no permitían operaciones que en realidad eran seguras
  • La falta de coherencia con reglas que no usan tipos núcleo reducía la consistencia del diseño general del lenguaje

Eliminación de los tipos núcleo en Go 1.25

• En el lanzamiento de Go 1.25 (previsto para agosto de 2025), se decidió eliminar el concepto de tipo núcleo de la especificación del lenguaje
• Se cambia a un enfoque en el que las restricciones necesarias para cada operación se describen mediante enunciados explícitos
• Principales efectos del cambio:
  • Al reducir la cantidad de conceptos, aprender Go se vuelve más fácil
  • El código no genérico queda más claro sin depender de conceptos de genéricos
  • Es posible diseñar reglas más flexibles para operaciones específicas
  • Se sientan las bases para futuras ampliaciones del lenguaje (por ejemplo, acceso a campos comunes, mejoras en las capacidades de slices, mejora de la inferencia de tipos, etc.)

Principales cambios aplicados y efectos esperados

• Todo el texto de la especificación que mencionaba los tipos núcleo se elimina o se reemplaza por enunciados explícitos
• En los mensajes de error del compilador también se elimina el término tipo núcleo y se ofrecen explicaciones más específicas
• No habrá impacto en el comportamiento de los programas Go existentes
• La especificación del lenguaje se vuelve más simple y, desde la perspectiva del usuario, Go será más intuitivo y claro

[GN⁺]

Opiniones de Hacker News

• Me gusta que el equipo de Go trate los cambios en la especificación con mucho cuidado

  • Los genéricos de Go son un cambio grande y pueden ser difíciles de usar
  • Creo que las restricciones ayudan a evitar el uso excesivo de genéricos
  • He visto casos en proyectos de Java y Typescript donde el uso excesivo del sistema de tipos vuelve el código poco claro
  • Espero que el equipo de Go siga siendo conservador con el lenguaje

• Los últimos 10 años del equipo de desarrollo de Go han sido un proceso de encontrar el equilibrio entre funcionalidad y simplicidad

  • Los genéricos muestran muy bien el núcleo de esa dinámica
  • Implementar sobre Go un sistema de tipos como el de Rust implica demasiada complejidad
  • Me parece bien un pequeño regreso hacia una dirección que priorice la simplicidad
  • El objetivo de Go es ser un mejor Java para equipos de ingenieros de nivel intermedio

• Go 1.25 en realidad no agrega funciones nuevas al lenguaje

  • En la 1.30 quizá se agreguen sum types

• Sigo a Go desde antes de los builds para Windows

  • Todo lo que aprendí en 2011 sigue siendo válido
  • No he tenido la oportunidad de trabajar con Go, pero he aprendido con proyectos pequeños
  • Me decepcionó que en entrevistas a desarrolladores de Go dijeran que parecía poco probable que los genéricos llegaran a Go
  • Ahora que ya se introdujeron los genéricos, planeo empezar proyectos paralelos con Go

• No es cierto que, cuando el argumento de close es un parámetro de tipo, todos los tipos deban ser canales con el mismo tipo de elemento

  • El tipo de elemento no afecta a close, y también compila bien al usar conjuntos de tipos con distintos tipos de elemento
  • Hace falta mejorar la documentación
  • Espero que se acelere la expansión de flexibilidad, como los campos compartidos

• Estoy aprendiendo Go lentamente y vengo de C++

  • Me pregunto si esto es algo similar a la especialización de plantillas
  • Ojalá más lenguajes lo soporten

• [muerto]

• Ahora que la IA generativa ya puede escribir código, me pregunto si el recolector de basura sigue siendo necesario

[aer0700]

Ahora que la IA generativa puede escribir código, me pregunto si el recolector de basura sigue siendo necesario.
> Da mucho en qué pensar...

[galadbran]

Oh... si la IA llega al nivel de escribir ese tipo de código (código que maneja la memoria de forma perfecta), va a ser difícil que los desarrolladores humanos sigan teniendo el mismo rol que ahora.

[kandk]

Si 1+1=2 se puede resolver con matemáticas, no hay razón para resolverlo con IA...

[jeiea]

¿No tendría también sentido el GC en cuanto a reducir el boilerplate que la gente tiene que leer y el contexto del código que hay que seguir?
Si lo que se está prediciendo es que ya ni siquiera hará falta leer el código, entonces ya no sé.
Viendo que el comentario original también está atenuado, no parece que haya generado mucha simpatía.

[savvykang]

¿No se podría eliminar el conteo de referencias cuando es posible calcular en tiempo de compilación los momentos de asignación y liberación de memoria? Parece que la persona que escribió el comentario original en Hacker News no está entendiendo el problema de la reutilización de memoria.