Go 1.24 リリース

 (go.dev)
1 ポイント 投稿者 GN⁺ 2025-02-15 | 1件のコメント | WhatsAppで共有
  • Go 1.24はGo 1.23以降の正式アップデートであり、言語機能からランタイム・標準ライブラリ・WebAssemblyまで、開発者がすぐに実感できる変更を幅広く含む
  • 言語レベルでは ジェネリック型エイリアス を完全にサポートし、型エイリアスも定義型のようにパラメータ化できる
  • ランタイムはSwiss Tablesベースの map、小さなオブジェクト割り当ての改善、内部ミューテックスの変更により、代表的なベンチマークで平均 CPUオーバーヘッドを2〜3%削減 した
  • go コマンドはモジュールの ツール依存関係 を追跡・実行するフローを追加し、go vet はテスト関連の宣言ミスをより的確に検出する
  • 標準ライブラリとプラットフォーム対応も拡張され、FIPS 140-3、testing.B.Loop、os.Root、runtime.AddCleanup、go:wasmexport、WASI reactor/library ビルドを確認する必要がある

Go 1.24の変更範囲

  • Go 1.24はGo 1.23に対する複数の改善を含むリリースであり、変更一覧全体は Go 1.24 release notes で確認できる
  • 新バージョンはGoのダウンロードページから入手できる

言語の変更: ジェネリック型エイリアス

  • Go 1.24は generic type aliases を完全にサポートする
  • 型エイリアスも定義型のように パラメータ化 できるため、ジェネリックコードでの表現範囲が広がる
  • 詳細な構文は language spec に含まれている

ランタイム性能の改善

  • ランタイム改善により、代表的なベンチマーク群で平均 CPUオーバーヘッドが2〜3%減少 した
  • 性能変化の主要な軸は3つある
    • Swiss Tables ベースの新しい組み込み map 実装
    • 小さなオブジェクトに対する、より効率的な メモリ割り当て
    • 新しいランタイム内部ミューテックス実装

Goツールの改善

  • go コマンドはモジュールの ツール依存関係 を追跡する仕組みを提供する
    • go get -tool で現在のモジュールに tool ディレクティブを追加する
    • go tool [tool name] で tool ディレクティブに宣言されたツールを実行する
    • 詳しくはリリースノートの go command を参照
  • go vet サブコマンドには新しい test アナライザが追加された
    • テストパッケージのテスト、ファザー、ベンチマーク、サンプル宣言における一般的なミスを報告する
    • 詳しくはリリースノートの vet を参照

標準ライブラリとランタイムAPIの追加

  • 標準ライブラリには FIPS 140-3 準拠 を支援する新しい仕組み一式が含まれる
    • 承認済みアルゴリズムに対して新しい仕組みを利用するために、アプリケーションのソースコード変更は不要
    • 詳しくはリリースノートの FIPS 140-3 compliance を参照
  • FIPS 140に加え、以前は x/crypto モジュールにあった複数のパッケージが 標準ライブラリ で提供される
  • ベンチマークコードでは testing.B.Loop メソッドを利用できる
    • for b.Loop() { ... } の形でベンチマーク反復を実行する
    • for range b.N のように b.N を使う一般的なループ構造を置き換えられる
    • この方式はより高速で、エラーの可能性が低い
  • 新しい os.Root 型は、特定のディレクトリ配下に隔離された ファイルシステム操作 を可能にする
  • ランタイムには新しいクリーンアップ機構 runtime.AddCleanup が追加された

WebAssembly対応の改善

  • Go 1.24は、GoプログラムがWebAssemblyホストへ関数をエクスポートできる新しい go:wasmexport ディレクティブを追加する
  • GoプログラムをWASI reactor/library としてビルドできる
  • 詳しくはリリースノートの WebAssembly を参照

今後の案内とフィードバック

  • 詳細全体は Go 1.24 release notes にある
  • 一部のトピックは今後のブログ記事でさらに深く扱われる予定
  • 問題が見つかった場合は issue を登録できる

関連記事

1件のコメント

 
GN⁺ 2025-02-15
Hacker Newsのコメント

  • より高速なmap実装が特にうれしいし、text/template がついに range-over-func をサポートしたのも良い
    Go 1.23 で関数型に対する range は入ったが、Go テンプレートではこれまで動かなかった

  • 退屈なくらい無難で気に入っている

  • os.Root の使いどころが何なのか気になる
    理解した限りでは https://github.com/golang/go/issues/67002 のようなセキュリティ関連の話だが、内部的に Chroot を使っていないなら、結局は誰かが Root の外へ抜け出す方法を見つけるかもしれない

    • chroot は、アプリケーションが今後も単一のディレクトリ内だけで動作すると確定できる場合にしか意味がない
      しかもプロセスにスーパーユーザー権限が必要なので、一般ユーザー権限で動くアプリケーションでは使えない
      os.Root() は、ファイルシステム操作に安全ベルトを付ける方向に近い。たとえばアプリケーションのキャッシュ関連処理をキャッシュディレクトリに制限したり、ファイルサーバーが適切な共有ディレクトリ内のファイルだけを提供するようにしたりする用途だ。chroot のような鉄壁の保証ではないが、単純なディレクトリトラバーサル攻撃は防げる
    • なぜ chroot を使う必要があるのかわからない
      Capsicum のようなサンドボックス機能と組み合わせるなら、capability mode に入る前にディレクトリを開いておき、あとで os.Root でその開いておいたディレクトリ配下のファイルシステムツリーにあるファイルを開ける

  • tools ディレクティブで指定したツールをインストールするときに使うタグを指定できるのか気になる
    下のように試してみたが、タグなしでインストールされるように見える
    go install -tags 'postgres' github.com/golang-migrate/migrate/v4/cmd/migrate@latest

  • GODEBUG=fips140=only を使うと、FIPS 140-3 に準拠しない暗号アルゴリズムがエラーを返すかパニックすると書かれているが、標準ライブラリが意図的にパニックする形はあまり好ましくない
    まだコードは見ていないが、下位互換性のために現在エラーを返さない関数でだけそうしているのか気になる

    • これは政府系の環境で必要な機能だ
      FIPS が設定されているかをランタイムで確認しないとコンプライアンス違反になるリスクがあり、結局は監査や終わりのない会議につながる。新しい統制や検証手順を整えるのに何日も苦労するくらいなら、パニックで 30 分の障害が起きるほうがずっとましだと思う
    • ならそのフラグを設定しなければいい
      こういう動作はランタイムでしか検知できない状況に有用だ。最低限のテストカバレッジさえあればすぐ表面化するはずだ
    • 現実的な代替案はエラーを返すことだけだが、エラーは捕まえて無視できる
      暗号化が関わる状況でそれが望ましいかは疑問だ。警告ログ程度で済ませるのは避けるべきだと思う。重要で対処可能ならエラーか致命ログであるべきだし、そうでないなら情報ログで十分だ
    • この点は Go 1.25 で整理されそうだと読んだ
      https://devblogs.microsoft.com/go/go-1-24-fips-update/
    • 兄弟コメントにあるように、場合によっては強制が必要だ
      隠れたバグを避けるやり方とも言える。"The server chose violence" [1] [2] に近い話で、Postel の法則が相互運用性の足をどれだけ引っ張ってきたかも考える価値がある。この点は FIPS 認証のさまざまな側面でしばしば忘れられる
      [1] https://cliffle.com/blog/hubris-reply-fault/
      [2] https://news.ycombinator.com/item?id=40178652

  • ついにジェネリック型エイリアスが入った。もっと前から必要だった機能だ

  • 新しいtoolフラグがいちばん楽しみだ。これで見栄えの悪い tools.go をなくせる

  • 良い。今回のリリースは GOAUTH のために待っていた
    プライベートな git リポジトリでの作業が少しでも面倒でなくなることを願っているが、go help goauth を見る限り、あまり大きな期待はできなさそうだ