Lançamento do Go 1.24

• O Go 1.24 é a atualização oficial após o Go 1.23 e inclui uma ampla gama de mudanças perceptíveis de imediato pelos desenvolvedores, desde recursos da linguagem até runtime, biblioteca padrão e WebAssembly
• No nível da linguagem, há suporte completo a aliases de tipos genéricos, permitindo parametrizar aliases de tipo da mesma forma que tipos definidos
• O runtime mostra, em benchmarks representativos, redução média de 2–3% no overhead de CPU graças ao map baseado em Swiss Tables, melhorias na alocação de objetos pequenos e mudanças nos mutexes internos
• O comando go adiciona um fluxo para rastrear e executar dependências de ferramentas do módulo, e o go vet passa a detectar melhor erros de declaração relacionados a testes
• O suporte de plataforma e a biblioteca padrão também foram ampliados, incluindo FIPS 140-3, testing.B.Loop, os.Root, runtime.AddCleanup, go:wasmexport e builds WASI reactor/library que merecem atenção

---

Escopo das mudanças no Go 1.24

• O Go 1.24 é uma release com várias melhorias em relação ao Go 1.23, e a lista completa de mudanças pode ser consultada nas notas de release do Go 1.24
• A nova versão pode ser baixada na página de downloads do Go

Mudança na linguagem: aliases de tipos genéricos

• O Go 1.24 oferece suporte completo a generic type aliases
• Aliases de tipo também podem ser parametrizados como tipos definidos, ampliando o alcance expressivo em código genérico
• A sintaxe detalhada está incluída na especificação da linguagem

Melhorias de desempenho no runtime

• Com as melhorias no runtime, o overhead médio de CPU caiu de 2–3% em um conjunto representativo de benchmarks
• Há três eixos principais nessa mudança de desempenho
  • nova implementação embutida de map baseada em Swiss Tables
  • alocação de memória mais eficiente para objetos pequenos
  • nova implementação interna de mutexes no runtime

Melhorias nas ferramentas do Go

• O comando go fornece um mecanismo para rastrear dependências de ferramentas do módulo
  • go get -tool adiciona uma diretiva tool ao módulo atual
  • go tool [tool name] executa a ferramenta declarada na diretiva tool
  • Mais detalhes estão na seção go command das notas de release
• O subcomando go vet ganha o novo analisador test
  • Ele reporta erros comuns em declarações de testes, fuzzers, benchmarks e exemplos no pacote de testes
  • Mais detalhes estão na seção vet das notas de release

Adições à biblioteca padrão e à API do runtime

• A biblioteca padrão inclui um novo conjunto de mecanismos para ajudar na conformidade com FIPS 140-3
  • Não é necessário alterar o código-fonte da aplicação para usar os novos mecanismos com algoritmos aprovados
  • Mais detalhes estão na seção FIPS 140-3 compliance das notas de release
• Além de FIPS 140, vários pacotes que antes estavam no módulo x/crypto agora são fornecidos pela biblioteca padrão
• Código de benchmark pode usar o método testing.B.Loop
  • Ele executa iterações de benchmark no formato for b.Loop() { ... }
  • Pode substituir a estrutura de loop comum que usa b.N, como for range b.N
  • Essa abordagem é mais rápida e menos propensa a erros
• O novo tipo os.Root permite operações de sistema de arquivos isoladas abaixo de um diretório específico
• O runtime agora inclui o novo mecanismo de limpeza runtime.AddCleanup
  • Ele é mais flexível, eficiente e menos propenso a erros do que runtime.SetFinalizer

Melhorias no suporte a WebAssembly

• O Go 1.24 adiciona a nova diretiva go:wasmexport, que permite que programas Go exportem funções para um host WebAssembly
• Agora é possível compilar programas Go como WASI reactor/library
• Mais detalhes estão na seção WebAssembly das notas de release

Orientações posteriores e feedback

• Todos os detalhes completos estão nas notas de release do Go 1.24
• Alguns temas serão abordados com mais profundidade em posts futuros do blog
• Se encontrar algum problema, é possível registrar uma issue

[GN⁺]

Opiniões no Hacker News

• A implementação de map mais rápida é especialmente bem-vinda, e também é bom que text/template agora dê suporte a range-over-func
  No Go 1.23, o range sobre tipos de função entrou na linguagem, mas até agora não funcionava nos templates do Go

• Gosto porque é tranquilo a ponto de ser sem graça

• Fico curioso sobre quais serão os usos de os.Root
  Pelo que entendi, parece estar relacionado a segurança, como em https://github.com/golang/go/issues/67002, mas como internamente ele não usa Chroot, acho que no fim alguém ainda pode encontrar uma forma de escapar para fora do Root

  • chroot só faz sentido quando a aplicação consegue cravar que continuará funcionando apenas dentro de um único diretório
    Além disso, o processo precisa ter privilégios de superusuário, então não dá para usar em aplicações executadas com permissões de usuário comum
    os.Root() está mais para colocar um cinto de segurança nas operações de sistema de arquivos. Por exemplo, limitar operações relacionadas ao cache da aplicação ao diretório de cache, ou fazer com que um servidor de arquivos sirva apenas arquivos dentro do diretório compartilhado apropriado. Não é uma garantia blindada como chroot, mas impede ataques simples de travessia de diretórios
  • Não sei por que seria preciso usar chroot
    Com recursos de sandbox como Capsicum, dá para abrir um diretório antes de entrar no capability mode e, depois, usar os.Root para abrir arquivos na árvore do sistema de arquivos abaixo desse diretório aberto

• Fico me perguntando se dá para especificar tags a usar ao instalar ferramentas definidas pela diretiva tools
  Tentei como abaixo, mas parece que instala sem tags
  go install -tags 'postgres' github.com/golang-migrate/migrate/v4/cmd/migrate@latest

• Dizem que, ao usar GODEBUG=fips140=only, algoritmos criptográficos que não estejam em conformidade com FIPS 140-3 retornam erro ou dão panic, mas não gosto muito da ideia de a biblioteca padrão dar panic de propósito
  Ainda não olhei o código, mas fico imaginando se isso acontece apenas em funções que hoje não retornam erro por causa da compatibilidade retroativa

  • Isso é um recurso necessário em ambientes governamentais
    Se você não verificar em runtime se o FIPS está configurado, corre o risco de quebrar a conformidade, o que acaba levando a auditorias e reuniões intermináveis. Vejo como muito melhor ter uma indisponibilidade de 30 minutos por causa de um panic do que sofrer por dias criando novos controles e procedimentos de validação
  • Então é só não configurar essa flag
    Esse comportamento é útil para situações que só podem ser detectadas em runtime. Mesmo uma cobertura de testes básica já deixaria isso evidente
  • A única alternativa realista é retornar um erro, mas erros podem ser capturados e ignorados
    Em uma situação envolvendo criptografia, é questionável se isso é desejável. Acho que o nível de log de aviso deve ser evitado. Se for importante e acionável, deve ser erro ou log fatal; se não for, log informativo basta
  • Li que essa parte deve ser ajustada no Go 1.25
    https://devblogs.microsoft.com/go/go-1-24-fips-update/
  • Como nos comentários irmãos, em alguns casos é preciso impor a regra
    Também dá para ver como uma forma de evitar bugs ocultos. É parecido com "The server chose violence" [1] [2], e vale pensar também em quanto a lei de Postel atrapalhou a interoperabilidade. Esse ponto é frequentemente esquecido em vários aspectos da certificação FIPS
    [1] https://cliffle.com/blog/hubris-reply-fault/
    [2] https://news.ycombinator.com/item?id=40178652

• Finalmente entraram os aliases de tipos genéricos, um recurso que já era necessário havia muito tempo

• A nova flag tool é o que mais me anima. Agora dá para se livrar daquele tools.go feio

• Bom. Eu estava esperando este lançamento por causa de GOAUTH
  Espero que trabalhar com repositórios git privados fique menos chato, mas olhando go help goauth, parece difícil criar grandes expectativas