Goの16回目の誕生日

 (go.dev)
11 ポイント 投稿者 GN⁺ 2025-11-16 | 1件のコメント | WhatsAppで共有
  • Go言語のオープンソース公開16周年を迎え、直近1年間の主要な技術的進展と今後の計画を整理
  • Go 1.24と1.25では、テスト・セキュリティ・性能全般にわたる大規模な改善を実施
  • synctest、container-aware scheduling、flight recorder などにより、本番環境の信頼性と効率を強化
  • 暗号パッケージのFIPS 140-3認証準備、Green Tea GC などでセキュリティと性能を向上
  • GoエコシステムはAI統合開発と現代的なコード自動化へと拡張中で、今後は大規模ハードウェアおよびAI対応をさらに強化する予定

Go 16周年と最近のリリース概要

  • 11月10日にGoのオープンソース公開16周年を記念
  • 2024年2月にGo 1.24、8月にGo 1.25が定期リリースサイクルに従って配布
  • 2つのバージョンには、信頼性の高いソフトウェア開発向けAPI、セキュリティ強化、ランタイム性能改善が含まれる
  • Goチームは生成AI時代の変化に対応し、GoベースのAI統合・エージェント・インフラ開発を推進中

中核言語および標準ライブラリの改善

  • Go 1.24で実験的に導入され、1.25で正式化された**testing/synctest パッケージ**は、非同期・並列コードのテストを簡素化
    • 時間の仮想化により、遅いまたは不安定なテストを、信頼性が高く即時に実行できるテストへ変換
    • Goランタイムおよび標準ライブラリと深く統合された構造
  • testing.B.Loop APIは、既存のベンチマークAPI（B.N）の使い勝手を改善し、従来の落とし穴を解消
  • Context ベースのテスト後始末およびログ出力APIが追加され、テスト管理の効率が向上
  • Go 1.25はcontainer-aware schedulingを導入し、コンテナ内の並列処理を自動調整
    • CPUスロットリングを防止し、レイテンシを改善
  • flight recorder機能は実行トレーサーを拡張し、エラー発生直前のイベントを詳細に記録可能

セキュリティ重視のソフトウェア開発

  • Goの暗号パッケージは、独立系セキュリティ企業Trail of Bitsの監査で低重大度の単一問題のみが発見
  • Go Security TeamとGeomysの協力によりCAVP認証を取得し、FIPS 140-3認証の準備を完了
    • 規制環境におけるGoの実用性を高め、既存の非公式ソリューション依存の問題を解消
  • Go標準ライブラリは、**デフォルトで安全な設計（safe by default）**の方向へ進化
    • Go 1.24の**os.Root API**は、ファイルシステムアクセス時のパストラバーサル脆弱性を防止

内部構造と性能改善

  • Go 1.24では**map 実装が全面的に再設計**され、最新のハッシュテーブル設計を反映
    • 性能向上、レイテンシ低減、メモリ効率改善を実現
  • Go 1.25のGreen Teaガベージコレクタは、GCオーバーヘッドを10〜40%削減
    • 最新ハードウェアに合わせた新しいアルゴリズムを適用
    • Go 1.26ではAVX-512対応ハードウェアで追加10%の改善を予定
    • Go 1.26からデフォルトで有効化予定

開発スタック拡張とAI統合

  • Goは言語を超えて完全な開発プラットフォームへと進化中
  • gopls言語サーバーは4回の定期リリース（v0.17〜v0.20）で機能を強化
    • コードアナライザー、リファクタリング、JSONタグ処理、MCP組み込みサーバーなどを追加
  • **自動コードモダナイズ（modernizer）**機能を導入
    • 古いコードパターンを最新かつ安全な形へ自動変換
    • IDEの提案機能と統合され、一貫したコード維持とAI補助学習に寄与
    • Go 1.26ではgo fixコマンドがmodernizer全体を一括適用するよう再編予定
  • Anthropicおよびコミュニティとの協力により、Model Context Protocol（MCP）向け公式Go SDK v1.0.0を公開
    • MCPクライアント・サーバーをサポートし、goplsのMCP機能を基盤とする
    • GoogleのADK for Goは、MCP SDK上でマルチエージェントシステム開発フレームワークを提供
    • Goの並行性・性能・信頼性が、AI本番開発に適していることを示している

今後の計画とコミュニティ

  • Green Tea GCの一般提供、SIMDハードウェア対応、マルチコア拡張性強化を予定
  • encoding/json の大規模アップグレード、goroutineリークのプロファイリング、net/http・unicode改善などを進行中
  • GoとAIの結合に向けた言語・ツール・診断体系を拡張
  • Goオープンソースプロジェクトは貢献者コミュニティ拡大と開発プロセスの拡張性を目標とする
  • Goの発展はユーザーおよび貢献者コミュニティの貢献に基づいており、今後の継続的な成長が期待される

関連記事

1件のコメント

 
GN⁺ 2025-11-16
Hacker Newsの意見

  • 自分は Go が本当に好き。モノレポ環境で特に真価を発揮する。新しいアプリケーションを追加するときはフォルダを1つ作って、main() 関数のある go ファイルを置くだけでいい。ルートで go install ./... を実行すれば全体がすばやくビルドされる
    CLI プログラムを素早く作る必要があるとき、このシンプルさは本当に 神の一手 だった

    • 他の言語でもほとんど同じことはできるのでは、という疑問がある
    • こうした モノレポ活用例 はもっと頻繁に語られるべきだと思う

  • 以前は言語がボトルネックではないと言われていたが、Go を初めて見たとき「これは違う」と感じた。習得も本当に速い。おそらく言語仕様が小さいからだろう。
    体感としては Rust の80%の機能を20%の労力で 得られる感じだ

    • Go の良さは、言語全体を短時間で把握できる点にある。並行性 や落とし穴まで含めて全体を理解できる。一方で C# や C++ は複雑すぎて、全体を理解している人はほとんどいない
    • Rob Pike の言う通り、Go は ジュニア開発者 のために設計された言語だ。Google 内部でビルド時間を短縮したいという目的も大きかった。だから未使用の依存関係があるとコンパイルエラーになる (出典)
    • 言語仕様が小さいからといって必ずしも単純とは限らない。たとえば Swift は仕様が大きくても定義が緩い。Go の仕様を読んでいて 整数リテラルの文法 に誤りを見つけたことがあるくらいだ
    • ただ、Rust に残る20%の機能が 有用性の80% を占めているのは惜しい
    • しかも Go もだんだん複雑になっている。たとえば ジェネリクス が追加されて以降、単純さは薄れている

  • 自分にとって Go は 過度に単純化された Rust のようなものだ。コード自動修正、ループの強制、map のキー存在確認も不便。
    配列処理や enum 定義もぎこちなく、会社の linter ルール のせいでコードが分割され、まるでエンタープライズ Java のようになる。
    それでもインターフェースはシンプルで、学ぶのは速い。
    もし Go に まともな enum、自然な slice 構文、iterator、結果アンラップの短縮構文 があれば、ずっと良くなったと思う

    • Go の欠点の1つは 短い変数名 の文化だ。構造体の先頭フィールドが継承のように振る舞ったり、大文字/小文字でアクセス制御をするのも不便。
      標準の json ライブラリも空の slice を null にシリアライズするなど問題が多い。
      それでも ツール類の速さ は優秀で、実用性は認める
    • 自分は Go の lexer/parser をフォークして、Result[T]/Option[T]、sum type、iterator、tuple などを追加した実験的な言語を作った (agl プロジェクト)
    • Go にも enum はある。ただ sum type がないだけだ。配列と slice は C とほぼ同じで、「マジック」が少ないせいで逆に分かりづらく見えるだけだ。
      結果アンラップ はコミュニティで長年議論されているが、まだすっきりした解決策はない
    • 実際、Go にはすでに iter パッケージ と slices.Delete がある。
      配列の途中から要素を頻繁に削除するなら、データ構造の選択が間違っている
    • slices.Delete で削除できるし、if err != nil の強制のようなものは言語の問題ではなく チームのルールの問題 だ

  • Go が Apple II 向けにリリース されるのかと勘違いして一瞬期待した (SWEET16 参照)

  • 新しい Go コードベースへの貢献はしやすい。
    言語のシンプルさと gofmt、golangci-lint のような標準ツールのおかげで、どのコードベースも似たような構造になる。
    他の言語コミュニティのようなビルドツール論争もない

    • 自分が働く科学者たちに コードフォーマッタとリンター を使うよう説得している。Go のように強制するのは良い判断だったと思う
    • ちょうど Go を学び始めたところだが、「1つのやり方だけ」という哲学が気に入っている。
      ただ % 演算子の負数処理の仕方はやや紛らわしかった

  • 自動コードモダナイズツール(modernizer) の導入は興味深い。
    gopls v0.18.0 以降、構文解析によって古いイディオムを見つけて より高速で安全なコードに自動変換 してくれる。
    gofmt がスタイルの一貫性を作ったように、modernizer は イディオムの一貫性 を作るだろう

  • golangci-lint で exhaustive、exhaustruct、wrapcheck のようなリンターを有効にすると、安全性 が大きく向上し、開発速度も上がる

  • うちの会社では Go バックエンド開発者向けの 10週間のオンボーディングプログラム を運営している (計画リンク)
    Python から Go に移行して7年になるが、これが スタートアップ成功の重要な要因 だった

    • ただし Go 関連の採用はたいてい DevOps の知識(AWS, Kubernetes, CI/CD) を求める。純粋なソフトウェアエンジニアリングのポジションは少ない
    • 直接リンク

  • 最初は Go を疑っていたが、今では一番好きな言語だ。シンプルでありながら強力だ。
    ただ null チェック、エラースタックトレース、sum type の exhaustive チェック が標準で提供されればと思う

    • null チェックツールとして NilAway が開発中だ
    • sum type のチェック は golangci-lint で可能だ

  • Go は 関数型プログラミング 関連の機能がもう少しあれば完璧だと思う。
    特に 不変性、null 処理、switch の網羅性チェック が物足りない。
    Uber の NilAway を使って補っているが、型システムのレベルでサポートされるとさらに良い

    • Borgo というプロジェクトもあるが、まだ未成熟だ
    • sum type と nil ポインタのない Go を夢見ている。Gleam はその方向に近いが、あまりにも別の道へ進んでしまった