後方互換性、Go 1.21、そして Go 2

• Goプログラミング言語における後方互換性の重要性に関する記事で、Go 1.21の新機能とGo 2の将来に焦点を当てている
• Go 1.21には互換性向上のための新機能が含まれており、Goを安定的で予測可能なものに保つことを目指し、開発者が言語の変化ではなく作業に集中できるようにしている
• Goチームは10年以上にわたり互換性を重視しており、Go 1仕様に従って書かれたプログラムは、その仕様の存続期間中、変更なしで正しくコンパイルおよび実行されるという明確な意図を持っている
• 互換性維持のための2つの主要なアプローチとして、APIチェックとテストを説明。APIチェックは既存APIが削除されたり、既存コードを壊す形で変更されたりしないことを保証する。テストには、次期Goリリースの開発版に対して既存のテストを実行することが含まれる
• Google社内でGoをテストして発見された、構造体リテラルと新しいフィールド、時間精度などに関する微妙な互換性問題の例を紹介
• 互換性の問題を、出力変更、入力変更、プロトコル変更の3つのカテゴリに分類
• Go 1.21では、GODEBUG の利用を拡張・正式化することで後方互換性を向上。GODEBUG 設定は少なくとも2年間維持され、mainパッケージの go.mod ファイルに記載されたGoバージョンと一致するよう設定される
• 記事はGo 2に関する更新で締めくくられ、Go 1プログラムを壊すGo 2は存在しないと発表している。代わりにGoチームは互換性を最優先し、これがGo 1のために下した最も重要な設計判断だと考えている

[GN⁺]

Hacker Newsの意見

• この記事は、Go 1.21における互換性の重要性と、将来あり得るGo 2について論じています。
• Go 1.21は2つの特徴的な機能を提供します。各変更に対するGODEBUG設定と、以前の実装の使用検知のためのメトリクス、そして旧版および新版のgo toolchainを自動的に取得するモジュールごとのtoolchainバージョンです。
• 特定バージョンのGoが指定されている場合、新しいGoバージョンは関連するオプトアウト設定を自動的に適用し、新しい挙動が要求されるまで有効にならないようにします。
• Go言語チームは後方互換性の維持に尽力しており、その姿勢は大規模なGoシステムを保守する開発者たちから評価されています。
• 一部のユーザーは、型システムに対する重要な改善には破壊的変更が必要になる可能性があるという懸念を示しています。
• Goが実際のGo 2を持たないようにすべきだという提案もあり、重要な変更は言語の分岐や改名を必要とする可能性があるためです。
• 「退屈」と表現されるGoの安定性と予測可能性は、断片化され絶えず変化するJavaScriptエコシステムと対照的です。
• この記事では、「Go 1.21における前方互換性とToolchain管理」に関する関連投稿にも触れています。
• Goにおける後方互換性への取り組みは称賛されており、あるユーザーはPythonからGoへコードを移行したことが、自分たちの拡張をどう支えたかを共有しています。
• 互換性を保証するためにGoで使われている手法は高く評価されており、他の言語設計でも採用を検討されています。