ハクソク

世界を動かす技術を、日本語で。

Go 1.25 リリースノート

286日前原文(go.dev)

概要

  • Go 1.25は2025年8月リリース予定、主にツールチェーン・ランタイム・ライブラリの改善
  • 従来通りGo 1互換性ポリシーを維持、既存プログラムは問題なく動作
  • 言語仕様の大きな変更はなし、core typesの記述方法を変更
  • goコマンドやランタイムに多くの新機能・最適化を追加
  • 標準ライブラリやコンパイラの機能強化とバグ修正を実施

Go 1.25の新機能と主な変更点

  • リリース時期 ：2025年8月、Go 1.24から6ヶ月後のリリース
  • 主な変更対象 ：ツールチェーン、ランタイム、ライブラリ
  • 互換性 ：Go 1互換性保証の維持、既存プログラムの動作保証

言語仕様

  • Go 1.25で 言語自体の仕様変更なし
  • core types の記述が専用プローズに変更
  • 詳細は公式ブログ記事参照

ツールチェーン・goコマンド

  • go build -asan ：プログラム終了時のリーク検出をデフォルト化
    • Cで確保されGo/Cの他メモリから参照されない場合エラー報告
    • 環境変数ASAN_OPTIONS=detect_leaks=0で無効化可能
  • プリビルドツール減少 ：コンパイラやリンカ以外は必要時にgo toolでビルド・実行
  • go.mod ignoreディレクティブ ：指定ディレクトリ・サブディレクトリをgoコマンドがパッケージ探索時に無視
  • go doc -http ：ドキュメントサーバ起動とブラウザ表示
  • go version -m -json ：Goバイナリ内のBuildInfo構造体をJSON形式で出力
  • モジュールルートのサブディレクトリ指定 ：go-importメタタグでサブディレクトリをモジュールルートとして解決可能
  • workパッケージパターン ：ワークスペース内全パッケージへのマッチング
  • goコマンドによるgo.mod/go.work更新時のtoolchain行追加廃止
  • go vet ：waitgroup（sync.WaitGroup.Addの誤用検出）、hostport（IPv6非対応アドレスの検出）など新アナライザー追加

ランタイム

  • GOMAXPROCSのコンテナ対応 ：
    • LinuxでcgroupのCPU帯域制限を考慮し、制限がある場合はそちらを優先
    • 全OSで論理CPU数やcgroup制限の変化に応じてGOMAXPROCSを動的更新
    • GOMAXPROCS環境変数やruntime.GOMAXPROCS呼び出しで自動制御無効化可能
    • GODEBUGでcontainermaxprocs=0, updatemaxprocs=0で明示的無効化
  • 新実験的ガーベジコレクタ ：
    • 小オブジェクトのマーキング・スキャン性能向上
    • 実アプリでGCオーバーヘッド10～40%削減見込み
    • GOEXPERIMENT=greenteagcで有効化
  • Trace Flight Recorder ：
    • runtime/trace.FlightRecorder APIでリングバッファに軽量トレース記録
    • 重要イベント発生時のみスナップショット取得可能
    • FlightRecorderConfigで記録時間・容量調整
  • 未処理panic出力の変更 ：
    • recovered後再panic時の出力を簡素化
  • LinuxのVMA名付与 ：
    • 匿名メモリ領域に用途ラベル付与（例：[anon: Go: heap]）
    • GODEBUG=decoratemappings=0で無効化

コンパイラ・リンカ

  • nilポインタバグ修正 ：
    • Go 1.21～1.24でnilチェック遅延バグを修正
    • エラー処理前のnil利用で正しくpanic発生
  • DWARF5対応 ：
    • デバッグ情報をDWARF v5で生成、容量・リンク時間削減
    • GOEXPERIMENT=nodwarf5で旧バージョン利用可能（将来的に廃止予定）
  • スライス高速化 ：
    • スライスのバックストアをより多くスタック上に割り当て性能向上
    • unsafe.Pointer誤用の影響増大、bisectツールで問題特定可能
    • すべての新しいスタック割当を-gcflags=all=-d=variablemakehash=nで無効化可能
  • リンカの-funcalign=N ：関数エントリのアラインメント指定可能

標準ライブラリ

  • testing/synctestパッケージ ：
    • 並行コードのテスト支援
    • テスト関数を仮想時間・バブル内で実行
    • GOEXPERIMENT=synctest時の旧APIはGo 1.26で廃止予定
  • 実験的encoding/json/v2パッケージ ：
    • 新しいJSON実装（GOEXPERIMENT=jsonv2で有効化）
    • encoding/jsonとjsontextの新パッケージ追加
    • マーシャリング・アンマーシャリングは互換、エラーメッセージは変更あり
    • 処理速度大幅向上、特にデコード
    • ユーザーに新APIの試用とフィードバックを推奨

その他ライブラリの細かな変更

  • archive/tar ：Writer.AddFSでシンボリックリンク対応
  • encoding/asn1 ：T61String/BMPStringのパース一貫性向上、不正エンコーディングの拒否
  • crypto ：MessageSignerインターフェース追加、SignMessage関数導入、fips140設定の動的変更禁止、AVX2非対応時のSHAアルゴリズムの低速化
  • crypto/ecdsa ：低レベルエンコーディング用関数追加、FIPS 140-3モードで署名速度向上
  • crypto/ed25519 ：FIPS 140-3モードで署名速度向上

まとめ

  • Go 1.25は 大規模な新機能追加や最適化 を含みつつ、 後方互換性を重視
  • コンテナ環境・並行処理・デバッグ・JSON処理 の分野で大幅な進化
  • 実験的機能の活用とフィードバックが今後の進化を左右

Hackerたちの意見

やった、新しいバージョンだ！そんなにワクワクする感じではないけど（Goのリリースって大体そんな感じだし、いいことだね）、jsonv2とgreenteaがテストされて、1.26で標準になるといいな。

└

greentea 何か分からなくて調べたら、新しいGCみたいだね。https://github.com/golang/go/issues/73581

この言語が進化していくのが大好き。多くの同僚が嫌ってる部分もあるけど、俺はここでGoやGoa、SQLcを組み合わせてコードの山を書いてる。結構いいコンパイラも背後にいるしね。厳格な言語を使わないことで何を逃してるかは分かってるけど、それでも全然問題ないトレードオフだと思ってる。

└

最初は好きじゃなかったけど、今は慣れてきた。まだ不満はあるけど、それは主に全体的なアーキテクチャから来るもので、解決することはないだろうけど、仕事で使う限られた範囲では結構楽しいよ。

└

golangには慣れてきたけど、まだ好きな言語ってわけじゃない。最近困ってるのはドキュメントだね。Pythonのサードパーティモジュールのドキュメントは素晴らしくて、ほぼどれも使いやすい。サードパーティライブラリを使うときは、大きいのも小さいのも、十分なドキュメントがあってすぐに使えるんだけど、golangのライブラリは逆にドキュメントが全然ないか、READMEのサンプルコードが古くて全然動かないことが多い。IDEとの統合は素晴らしいけど、エディタが自分が欲しいフィールドや関数を提案してくれることがあるのに、それを選ぶと「そんなフィールドや関数はない」って文句言われることも多い。まだ解決できてないんだよね。だから、うーん、言語自体は「素晴らしい」けど、確かにいくつかの極端な強みや便利さがある。例えば「この引数でこの関数を別スレッドで実行する」っていうのが言語のキーワードになってるし、サブプロセスやスレッド、concurrent.futuresに深く入らなくてもいいのがいいよね。同期機能も簡単にアクセスできるし、Sync.Onceは並行性が重要な言語であることを考えるとすごく明白だと思う。でも、エコシステムは……まあ、いい時でもちょっと混乱してるかな。良いモジュールは素晴らしいけど、他のモジュールはひどい。

└

Goは、10年間放置していた非自明なソースコードに戻っても、ビルドや実行に全く問題がなかった唯一の言語だよ。それだけで、個性的な部分を補って余りあるね。

└

家族の食卓に食べ物を置いてくれる言語は、どんな言語でもいいと思う。俺にとっては、RubyとGoの両方がそうだった。

LookupMXとResolver.LookupMXは、今や有効なIPアドレスのように見えるDNS名と有効なドメイン名を返すようになった。以前は、名前サーバーがDNS名としてIPアドレスを返すとLookupMXはそれを捨てていたが、RFCに従って。けど、実際には名前サーバーがIPアドレスを返すこともあるんだよね。これは面白いね。どのサーバーがレコードとしてIPアドレスを返すのか？なぜ彼らはそうしたいのだろう？

└

PRに関連するGitHubのイシューを見れば、いくつかの例が見つかるよ: https://github.com/golang/go/issues/56025#issuecomment-20667... スレッドの元の投稿者は、MailgunがGoを使っていて、これに関連する問題に直面しているからみたいだね: https://github.com/golang/go/issues/56025#issuecomment-26720...

新しい encoding/json/v2 パッケージ（GOEXPERIMENT=jsonv2 フラグの裏に隠れてる）！パフォーマンスの改善をもたらし、ついに開発者が外部タイプのカスタムマーシャラーを実装できるようになるよ。> 代わりに、ユーザーはMarshalFunc、MarshalToFunc、UnmarshalFunc、またはUnmarshalFromFuncに一致する関数を実装して、任意のタイプのJSON表現を指定できる。これにより、JSON機能の呼び出し元は、任意のタイプがJSONとしてどのようにシリアライズされるかを制御できる。素晴らしいね。

└

わあ、jsonについてのトップコメントだ。（編集：もうトップ1じゃないけど、ポイントは変わらない）。情報技術やソフトウェアエンジニアリング業界が「jsonのパースと再パッキング」ばかりなのは皮肉だね。

└

新しいjsonエンコーディングの変更が入ってすごくワクワクしてる！早く試してみたいな！特に新しいomitemptyやマップのキーのマシュリングは、私の汚いコードをきれいにするのに役立ちそう。

└

「encoding/json/v2のデザインは今後も進化していくと期待している。開発者には新しいAPIを試してもらい、提案された問題についてフィードバックを提供してほしい。これが何を指しているのか詳しい人いる？v2が実験的なものとして入っているのは、彼らがそれに満足しているということだと思ったけど、『進化することを期待している』っていうのは『まだ良くないことを知っている』って感じがする。もしかしたら私の理解が間違ってるかもだけど。他の実験は『これは新しいコードだから、テストしてね』って感じで、変わるものではなかったから。」

Goのツールがどれだけ充実しているか、ほんと好き。go/analyzerフレームワークはかなり進んでるし、他の言語でこんなにアクセスしやすいASTサポートを提供してるのは知らないな。

└

JDKは、JavaのASTにアクセスするための一級のサポートがあると思うよ。

└

これってカウントされる？ https://docs.python.org/3/library/ast.html

└

GoはASTへのアクセスを考えるときに思いつく言語の中では最後の方だね。最初に思いつくのはLispかな。

└

LispとLuaはどちらもASTのサポートがしっかりしてるよね。

WaitGroup.Go、めっちゃいいね。ボイラープレートをこれに置き換えることで、たくさんのコードを削除できそう。

今、多くのライブラリがgo.modを1.25に更新してるのを見てみて。1.25の機能を使ってないのに、1.24を続けたい人は古いバージョンに留まるか、たくさんの手間をかけないといけない。これは「最小」バージョンであって、依存関係のロックじゃないんだよね！

└

「今はほとんどのライブラリがアップデートしてるのを見てみて...こんなの見たことない。ほとんどのパッケージは実際にgo.modに1.13が入ってる。1.19を見かけることはめったにない。」

└

こんなの見たことない。人気のあるライブラリは、少なくとも2つ前のバージョンをサポートしてるよね。

「LookupMXとResolver.LookupMXは、今や有効なIPアドレスのように見えるDNS名や有効なドメイン名を返すようになった。以前は、名前サーバーがDNS名としてIPアドレスを返すと、LookupMXはそれを捨てていた。RFCで要求されていたからね。しかし、実際には名前サーバーがIPアドレスを返すこともある。ああ、意図的にコードをスタンダードに準拠させないようにしてるんだ。」

新機能のインタラクティブツアー: https://antonz.org/go-1-25/