1 puntos por GN⁺ 2025-02-15 | 1 comentarios | Compartir por WhatsApp
  • Go 1.24 es una actualización estable posterior a Go 1.23 e incluye una amplia gama de cambios que los desarrolladores notarán de inmediato, desde funciones del lenguaje hasta el runtime, la biblioteca estándar y WebAssembly
  • A nivel del lenguaje, admite por completo los alias de tipos genéricos, lo que permite parametrizar los alias de tipos igual que los tipos definidos
  • El runtime muestra una reducción promedio de 2–3% en la sobrecarga de CPU en benchmarks representativos, gracias a map basado en Swiss Tables, mejoras en la asignación de objetos pequeños y cambios en los mutex internos
  • El comando go agregó un flujo para rastrear y ejecutar dependencias de herramientas de los módulos, y go vet detecta mejor errores en declaraciones relacionadas con pruebas
  • También se amplió el soporte de la biblioteca estándar y de plataformas, por lo que conviene revisar FIPS 140-3, testing.B.Loop, os.Root, runtime.AddCleanup, go:wasmexport y la compilación de WASI reactor/library

Alcance de los cambios en Go 1.24

  • Go 1.24 es un lanzamiento con varias mejoras respecto de Go 1.23, y la lista completa de cambios puede consultarse en las notas de lanzamiento de Go 1.24
  • La nueva versión se puede descargar desde la página de descargas de Go

Cambios en el lenguaje: alias de tipos genéricos

  • Go 1.24 admite por completo los alias de tipos genéricos
  • Los alias de tipos también pueden parametrizarse igual que los tipos definidos, lo que amplía el rango de expresión en código genérico
  • La sintaxis detallada está incluida en la especificación del lenguaje

Mejoras de rendimiento del runtime

  • Gracias a mejoras en el runtime, la sobrecarga de CPU se reduce en promedio entre 2 y 3% en un conjunto de benchmarks representativos
  • Los principales ejes del cambio de rendimiento son tres
    • Nueva implementación integrada de map basada en Swiss Tables
    • Asignación de memoria más eficiente para objetos pequeños
    • Nueva implementación de mutex internos del runtime

Mejoras en las herramientas de Go

  • El comando go ofrece un mecanismo para rastrear dependencias de herramientas de los módulos
    • go get -tool agrega una directiva tool al módulo actual
    • go tool [tool name] ejecuta una herramienta declarada en la directiva tool
    • Más detalles en la sección go command de las notas de lanzamiento
  • Se agregó un nuevo analizador test al subcomando go vet
    • Reporta errores comunes en declaraciones de tests, fuzzers, benchmarks y ejemplos dentro de paquetes de prueba
    • Más detalles en la sección vet de las notas de lanzamiento

Nuevas API en la biblioteca estándar y el runtime

  • La biblioteca estándar incluye un conjunto de nuevos mecanismos para ayudar con el cumplimiento de FIPS 140-3
    • No se requieren cambios en el código fuente de las aplicaciones para usar los nuevos mecanismos con algoritmos aprobados
    • Más detalles en la sección FIPS 140-3 compliance de las notas de lanzamiento
  • Además de FIPS 140, varios paquetes que antes estaban en el módulo x/crypto ahora se ofrecen en la biblioteca estándar
  • El código de benchmarks puede usar el método testing.B.Loop
    • Ejecuta las iteraciones del benchmark con la forma for b.Loop() { ... }
    • Puede reemplazar la estructura de bucle habitual que usa b.N, como for range b.N
    • Este enfoque es más rápido y menos propenso a errores
  • El nuevo tipo os.Root permite realizar operaciones de sistema de archivos aisladas bajo un directorio específico
  • El runtime agregó un nuevo mecanismo de limpieza, runtime.AddCleanup

Mejoras en el soporte de WebAssembly

  • Go 1.24 agrega una nueva directiva go:wasmexport, que permite a los programas Go exportar funciones a un host WebAssembly
  • Los programas Go pueden compilarse como WASI reactor/library
  • Más detalles en la sección WebAssembly de las notas de lanzamiento

Guía posterior y feedback

  • La información detallada completa está en las notas de lanzamiento de Go 1.24
  • Algunos temas se abordarán con más profundidad en próximas publicaciones del blog
  • Si se encuentra algún problema, se puede registrar un issue

1 comentarios

 
GN⁺ 2025-02-15
Opiniones de Hacker News
  • La implementación de map más rápida es especialmente bienvenida, y también está bueno que text/template ahora soporte range-over-func
    En Go 1.23 se incorporó range para tipos de función, pero hasta ahora no funcionaba en las plantillas de Go

  • Me gusta porque es tan tranquilo que casi resulta aburrido

  • Me pregunto para qué se usará os.Root
    Por lo que entiendo, parece relacionado con la seguridad, como en https://github.com/golang/go/issues/67002, pero como internamente no usa Chroot, al final quizá alguien encuentre la forma de escapar fuera de Root

    • chroot solo tiene sentido cuando una aplicación puede confirmar que en adelante va a operar únicamente dentro de un solo directorio
      Además, el proceso necesita privilegios de superusuario, así que no se puede usar en aplicaciones que se ejecutan con permisos de usuario normal
      os.Root() se parece más a ponerles un cinturón de seguridad a las operaciones del sistema de archivos. Por ejemplo, limitar las operaciones relacionadas con la caché de una aplicación al directorio de caché, o hacer que un servidor de archivos solo sirva archivos dentro del directorio compartido correspondiente. No es una garantía blindada como chroot, pero sí bloquea ataques simples de directory traversal
    • No entiendo por qué habría que usar chroot
      Junto con funciones de sandboxing como Capsicum, se puede abrir el directorio antes de entrar en capability mode y luego usar os.Root para abrir archivos del árbol del sistema de archivos bajo ese directorio abierto
  • Me pregunto si se pueden especificar tags para instalar una herramienta indicada con la directiva tools
    Probé algo como lo siguiente, pero parece instalarse sin tags
    go install -tags 'postgres' github.com/golang-migrate/migrate/v4/cmd/migrate@latest

  • Se dice que si se usa GODEBUG=fips140=only, los algoritmos criptográficos que no cumplen con FIPS 140-3 devuelven un error o hacen panic, pero no me convence mucho que la biblioteca estándar haga panic deliberadamente
    Todavía no vi el código, pero me pregunto si solo ocurre en funciones que actualmente no devuelven errores por compatibilidad hacia atrás

    • Esta es una función necesaria en entornos gubernamentales
      Si no se verifica en runtime si FIPS está configurado, existe el riesgo de romper el cumplimiento, lo que termina en auditorías y reuniones interminables. En mi opinión, es mucho mejor tener una caída de 30 minutos por un panic que sufrir durante días creando nuevos controles y procedimientos de validación
    • Entonces basta con no configurar ese flag
      Este comportamiento es útil para situaciones que solo se pueden detectar en runtime. Con una cobertura de pruebas básica debería quedar en evidencia enseguida
    • La única alternativa realista es devolver un error, pero los errores se pueden capturar e ignorar
      Me pregunto si eso es deseable cuando se trata de criptografía. Creo que habría que evitar dejarlo a nivel de log de advertencia. Si es importante y accionable, debería ser un error o un log fatal; si no, con un log informativo alcanza
    • Leí que esta parte probablemente se ordene en Go 1.25
      https://devblogs.microsoft.com/go/go-1-24-fips-update/
    • Como dicen los comentarios hermanos, en algunos casos hace falta imponerlo
      También puede verse como una forma de evitar bugs ocultos. Es parecido a "The server chose violence" [1] [2], y vale la pena pensar cuánto frenó la interoperabilidad la ley de Postel. Este punto se suele olvidar en varios aspectos de la certificación FIPS
      [1] https://cliffle.com/blog/hubris-reply-fault/
      [2] https://news.ycombinator.com/item?id=40178652
  • Por fin llegaron los alias de tipos genéricos, una función que hacía falta desde hace tiempo

  • Lo que más espero es el nuevo flag tool. Ahora podremos deshacernos del feo tools.go

  • Bien. Estaba esperando este release por GOAUTH
    Espero que trabajar con repositorios git privados sea menos molesto, pero viendo go help goauth, parece difícil hacerse demasiadas ilusiones