Goブログ

Go 2に向けて

Russ Cox
2017年7月13日

はじめに

これは、Gophercon 2017で行われた私の講演（こちらでご覧いただけます）のテキストです。Go 2について議論し、計画するにあたって、Goコミュニティ全体からの協力を求めています。

2007年9月25日、Rob Pike、Robert Griesemer、Ken Thompsonが数日間新しいプログラミング言語について議論した後、Robは「Go」という名前を提案しました。

翌年、Ian Lance Taylorと私はチームに加わり、5人で2つのコンパイラと標準ライブラリを構築し、2009年11月10日のオープンソースリリースに至りました。

その後2年間、新しいGoオープンソースコミュニティの助けを借りて、大小さまざまな変更を試み、Goを改良し、2011年10月5日に提案されたGo 1の計画へとつながりました。

Goコミュニティからのさらなる支援を受けて、私たちは計画を修正および実装し、最終的に2012年3月28日にGo 1をリリースしました。

Go 1のリリースは、名前とアイデアのリストから安定した実稼働言語に至るまで、約5年間の創造的で精力的な努力の集大成となりました。また、変化と混乱から安定への明確な転換も示しました。

Go 1に至るまでの数年間に、私たちはGoを変更し、ほぼ毎週のように皆さんのGoプログラムを壊しました。私たちは、これがGoを実稼働環境で使用することを妨げていることを理解していました。実稼働環境では、言語の変更に対応するために毎週プログラムを書き直すことはできません。Go 1を発表したブログ記事で述べているように、その主な動機は、信頼性の高い製品、プロジェクト、出版物（ブログ、チュートリアル、カンファレンストーク、書籍）を作成するための安定した基盤を提供し、ユーザーが自分のプログラムが今後何年も変更されることなくコンパイルおよび実行され続けることに自信を持てるようにすることでした。

Go 1がリリースされた後、私たちは、Go 1が設計された実稼働環境でGoを使用する時間を費やす必要があることを知っていました。私たちは、言語の変更から、独自のプロジェクトでGoを使用し、実装を改善することに明確にシフトしました。Goを多くの新しいシステムに移植し、Goの実行効率を高めるためにパフォーマンスに重要なほぼすべての部分を書き直し、レースディテクタなどの主要なツールを追加しました。

現在、私たちはGoを使用して大規模な本番品質のシステムを構築してきた5年間の経験を持っています。何がうまくいき、何がうまくいかないかについての感覚を養ってきました。Goの進化と成長における次のステップ、Goの未来を計画する時が来ました。本日、GopherConの聴衆の方々、ビデオをご覧になっている方々、後日Goブログを読んでいる方々など、Goコミュニティの皆様全員に、Go 2の計画と実装にご協力いただくようお願いするために、ここに来ました。

この講演の残りの部分では、Go 2の目標、制約と制限、全体的なプロセス、Goの使用経験について書くことの重要性（特に私たちが解決しようとする可能性のある問題に関連するもの）、考えられる解決策の種類、Go 2を提供する方法、そして皆様がどのように貢献できるかについて説明します。

目標

Goに対する私たちの目標は、2007年と同じです。プログラマーが2種類の規模をより効果的に管理できるようにしたいと考えています。1つは、本番環境の規模、特にクラウドソフトウェアに代表される、他の多くのサーバーと対話する並行システムです。もう1つは、開発規模、特に現代のオープンソース開発に代表される、ゆるやかに連携する多くのエンジニアによって作業される大規模なコードベースです。

これらの種類の規模は、あらゆる規模の企業に現れます。5人のスタートアップ企業でさえ、他の企業が提供する大規模なクラウドベースのAPIサービスを使用し、自分たちで書くソフトウェアよりも多くのオープンソースソフトウェアを使用する可能性があります。本番環境の規模と開発規模は、Googleと同じくらい、そのスタートアップ企業にとっても重要です。

Go 2の目標は、Goがスケーリングに失敗する最も重要な方法を修正することです。

（これらの目標の詳細については、Rob Pikeの2012年の記事「Go at Google: Language Design in the Service of Software Engineering」と、私のGopherCon 2015の講演「Go, Open Source, Community」をご覧ください。）

制約

Goの目標は最初から変わっていませんが、Goの制約は確かに変わっています。最も重要な制約は、既存のGoの使用状況です。世界中で少なくとも50万人のGo開発者がいると推定しています。これは、数百万のGoソースファイルと少なくとも10億行のGoコードがあることを意味します。これらのプログラマーとソースコードはGoの成功を表していますが、Go 2の主な制約でもあります。

Go 2は、これらのすべての開発者を連れて行かなければなりません。古い習慣を忘れ、新しい習慣を学ぶように求めるのは、見返りが大きい場合のみです。たとえば、Go 1より前は、エラー型によって実装されたメソッドの名前は`String`でした。Go 1では、エラー型をフォーマットできる他の型と区別するために、`Error`という名前に変更しました。先日、エラー型を実装していましたが、何も考えずにメソッドの名前を`Error`ではなく`String`にしてしまい、コンパイルできませんでした。5年後も、古い方法を完全に忘れ去ることができていません。このような明確化のための名前の変更は、Go 1で行うべき重要な変更でしたが、正当な理由がない限り、Go 2では破壊的すぎます。

Go 2は、既存のGo 1ソースコードもすべて引き継がなければなりません。Goエコシステムを分割してはなりません。Go 2で書かれたパッケージがGo 1で書かれたパッケージをインポートし、その逆もまた然り、という混在プログラムは、数年間の移行期間中、問題なく動作する必要があります。その方法を正確に理解する必要があります。`go fix`のような自動化ツールは確かに役割を果たすでしょう。

混乱を最小限に抑えるために、各変更には慎重な検討、計画、およびツールが必要になります。これは、行うことができる変更の数に制限を設けます。2つか3つ、5つ以上はできないでしょう。

より多くの話し言葉で識別子を許可したり、2進整数リテラルを追加したりするなどのマイナーな整理変更は数えていません。このようなマイナーな変更も重要ですが、正しく行うのは簡単です。今日は、エラー処理の追加サポート、不変または読み取り専用値の導入、何らかの形式のジェネリクスの追加、またはまだ提案されていない他の重要なトピックなど、考えられる主要な変更に焦点を当てています。これらの主要な変更は、ほんのわずかしか行うことができません。慎重に選択する必要があります。

プロセス

それは重要な質問を提起します。Goを開発するプロセスは何ですか？

Goの初期の頃、私たちが5人しかいなかった頃は、ガラスの壁で隔てられた隣接した共有オフィスで働いていました。問題について話し合うために全員を1つのオフィスに集め、その後、それぞれの机に戻って解決策を実装するのは簡単でした。実装中に問題が発生した場合、全員を再び集めるのは簡単でした。RobとRobertのオフィスには小さなソファとホワイトボードがあったので、通常は私たちの1人が入ってボードに例を書き始めました。通常、例が書き終わる頃には、他の全員が自分の作業の良い区切りに達し、座って話し合う準備ができていました。その非公式性は、明らかに今日のグローバルなGoコミュニティには規模が合いません。

Goのオープンソースリリース以降の作業の一部は、私たちの非公式なプロセスをメーリングリスト、イシュートラッカー、そして50万人のユーザーがいるより公式な世界に移植することでした。しかし、私たちの全体的なプロセスを明確に説明したことは一度もないと思います。意識的に考えたことはなかったのかもしれません。しかし、振り返ってみると、これはGoでの作業の基本的な概要、つまり最初のプロトタイプが稼働してから私たちが従ってきたプロセスだと思います。

ステップ1は、Goを使用し、Goの経験を積むことです。

ステップ2は、Goの問題点の中で解決が必要なものを見つけ、それを明確に述べ、他の人に説明し、書き留めることです。

ステップ3は、その問題に対する解決策を提案し、他の人と話し合い、その議論に基づいて解決策を修正することです。

ステップ4は、解決策を実装し、評価し、その評価に基づいて改良することです。

最後に、ステップ5は、解決策を提供し、それを言語、ライブラリ、または人々が日常的に使用するツールのセットに追加することです。

特定の変更について、これらのすべての手順を同じ人が行う必要はありません。実際、通常は多くの人が特定のステップで協力し、1つの問題に対して多くの解決策が提案される可能性があります。また、どの時点でも、特定のアイデアをこれ以上進めたくないことに気づき、前のステップに戻る可能性があります。

このプロセス全体について話したことはないと思いますが、その一部は説明しました。2012年にGo 1をリリースし、Goを使用して変更をやめる時が来たと述べたとき、私たちはステップ1を説明していました。2015年にGoの変更提案プロセスを導入したとき、私たちはステップ3、4、5を説明していました。しかし、ステップ2を詳細に説明したことは一度もないので、ここで説明したいと思います。

（Go 1の開発と言語変更からの移行の詳細については、Rob PikeとAndrew GerrandのOSCON 2012の講演「The Path to Go 1」をご覧ください。提案プロセスの詳細については、Andrew GerrandのGopherCon 2015の講演「How Go was Made」と提案プロセスドキュメントをご覧ください。）

問題の説明

問題を説明するには2つの部分があります。最初の部分（簡単な部分）は、問題が正確に何であるかを述べることです。私たち開発者は、これについてはかなり得意です。結局のところ、私たちが書くすべてのテストは、コンピュータでさえ理解できるほど正確な言語で、解決すべき問題の記述です。2番目の部分（難しい部分）は、問題の重要性を、なぜ私たちが時間をかけてそれを解決し、解決策を維持する必要があるのかを誰もが理解できるほど十分に説明することです。問題を正確に述べるのとは対照的に、問題の重要性を説明する必要があることはあまりありませんし、私たちはそのことについてそれほど得意ではありません。コンピュータは私たちに「なぜこのテストケースが重要なのですか？これは本当に解決すべき問題ですか？この問題を解決することが、あなたができる最も重要なことですか？」とは決して尋ねません。いつか尋ねるようになるかもしれませんが、今日は尋ねません。

2011年の古い例を見てみましょう。Go 1を計画しているときに、`os.Error`を`error.Value`に名前変更することについて書いたものです。

問題は、非常に低レベルのライブラリではすべてが os.Error のために "os" をインポートするという、簡潔な一行で始まります。次に、私がここで下線を引いた5行は、問題の重要性を説明することに専念しています。"os" を使用するパッケージは、それら自身の API でエラーを提示することができず、他のパッケージはオペレーティングシステムサービスとは関係のない理由で "os" に依存しています。

この5行で、あなたはこの問題が重要だと納得できるでしょうか？それは、私が省略したコンテキストをどれだけうまく補完できるかによって異なります。理解されるためには、他人が何を理解する必要があるかを予測する必要があります。当時の私の聴衆、つまりその文書を読んでいた Google の Go チームの他の10人にとっては、その50語で十分でした。昨秋、GothamGo の聴衆、つまりはるかに多様なバックグラウンドと専門分野を持つ聴衆に同じ問題を提示するには、より多くのコンテキストを提供する必要があり、実際のコード例と図とともに約200語を使用しました。今日の世界的な Go コミュニティでは、問題の重要性を説明するには、同僚に話す時には省略するような、具体的な例で示されるコンテキストを追加する必要があるというのは事実です。

他の人々に問題が重要であることを納得させることは、不可欠なステップです。問題が重要でないように見えると、ほとんどすべての解決策が高すぎるように思われます。しかし、重要な問題には、通常、妥当なコストの解決策が多数あります。特定の解決策を採用すべきかどうかについて意見が合わない場合、実際には解決しようとしている問題の重要性について意見が合わないことがよくあります。これは非常に重要なので、少なくとも後から見ると、これを明確に示す最近の2つの例を見てみましょう。

例：うるう秒

最初の例は時間に関するものです。

イベントにどれくらいの時間がかかるかを計測したいとします。開始時刻を書き留め、イベントを実行し、終了時刻を書き留め、開始時刻を終了時刻から差し引きます。イベントに10ミリ秒かかった場合、減算の結果は10ミリ秒、おそらくプラスマイナスわずかな測定誤差になります。

start := time.Now()       // 3:04:05.000
event()
end := time.Now()         // 3:04:05.010

elapsed := end.Sub(start) // 10 ms

この明白な手順は、うるう秒の間に失敗する可能性があります。私たちの時計が地球の自転と完全に同期していない場合、公式には午後11時59分60秒であるうるう秒が、真夜中の直前に挿入されます。うるう年とは異なり、うるう秒は予測可能なパターンに従わないため、プログラムや API に組み込むのが困難です。時折発生する61秒の分を表す代わりに、オペレーティングシステムは通常、真夜中になる直前に時計を1秒戻すことによってうるう秒を実装します。そのため、午後11時59分59秒が2回発生します。この時計のリセットにより、時間が逆戻りしているように見えるため、10ミリ秒のイベントが負の990ミリ秒かかったと計測される可能性があります。

start := time.Now()       // 11:59:59.995
event()
end := time.Now()         // 11:59:59.005 (really 11:59:60.005)

elapsed := end.Sub(start) // –990 ms

時刻時計は、このような時計のリセットをまたがるイベントのタイミングには不正確であるため、オペレーティングシステムは現在、絶対的な意味を持たず、秒をカウントし、リセットされることのない単調増加時計という2番目の時計を提供しています。

奇妙な時計のリセット中は別として、単調増加時計は時刻時計よりも優れているわけではなく、時刻時計には時刻を伝えるのに役立つという追加の利点があるため、単純にするために Go 1 の時間 API は時刻時計のみを公開しています。

2015年10月、バグレポートで、Go プログラムが時計のリセット、特に典型的なうるう秒をまたがってイベントを正しく計時できないことが指摘されました。提案された修正は、元の issue のタイトルでもありました。「単調増加クロックソースにアクセスするための新しい API を追加する」。私は、この問題は新しい API を正当化するほど重要ではないと主張しました。数か月前の2015年半ばのうるう秒では、Akamai、Amazon、Google は終日時計をわずかに遅くし、時計を戻すことなく追加の秒を吸収しました。この「リープスメア」アプローチが最終的に広く採用されれば、本番システムにおけるうるう秒の時計リセットの問題は解消されるように思われました。対照的に、Go に新しい API を追加すると、新しい問題が追加されます。2種類の時計を説明し、ユーザーにそれぞれをいつ使用するかを教育し、既存のコードの多くの行を変換する必要があります。これらはすべて、めったに発生せず、自然に解消する可能性のある問題のためです。

明確な解決策のない問題が発生した場合、私たちは常に同じことを行います。待つのです。待つことで、問題に関する経験と理解を深めるための時間が増え、良い解決策を見つけるための時間も増えます。この場合、待つことで、ありがたいことにCloudflare での軽微な停止という形で、問題の重要性についての理解が深まりました。彼らの Go コードは、2016年末のうるう秒の間に DNS リクエストの時間を約負の990ミリ秒と計測し、サーバー全体で同時パニックを引き起こし、ピーク時に DNS クエリの0.2％を中断させました。

Cloudflare はまさに Go が対象としていた種類のクラウドシステムであり、Go がイベントを正しく計時できないことに基づく本番停止が発生しました。そして、これが重要なポイントですが、Cloudflare は John Graham-Cumming によるブログ記事「うるう秒が Cloudflare DNS に影響を与えた方法と理由」で彼らの経験を報告しました。本番環境での Go の経験に関する具体的な詳細を共有することで、John と Cloudflare は、うるう秒の時計リセット全体で正確なタイミングの問題を修正せずに放置するには重要すぎると私たちに理解させました。その記事が公開されてから2か月後、私たちは Go 1.9 で出荷されるソリューションを設計および実装しました（実際には新しい API なしで実現しました）。

例：エイリアス宣言

2番目の例は、Go でのエイリアス宣言のサポートです。

過去数年間、Google は大規模なコード変更に焦点を当てたチームを設立しました。これは、C++、Go、Java、Python、およびその他の言語で記述された数百万のソースファイルと数十億行のコードのコードベース全体に適用される API の移行とバグ修正を意味します。そのチームの仕事から学んだことの1つは、ある名前を使用する API を別の名前に変更する場合、クライアントコードを一度にすべてではなく、複数のステップで更新できることの重要性です。これを行うには、古い名前の使用を新しい名前に転送する宣言を記述できる必要があります。C++ にはこの転送を可能にする #define、typedef、および using 宣言がありますが、Go にはありません。もちろん、Go の目標の1つは大きなコードベースにうまくスケーリングすることです。Google での Go コードの量が増えるにつれて、ある種の転送メカニズムが必要であり、他のプロジェクトや企業も Go コードベースが大きくなるにつれてこの問題に遭遇することが明らかになりました。

2016年3月、私は Robert Griesemer と Rob Pike と、Go が段階的なコードベースの更新をどのように処理できるかについて話し始め、エイリアス宣言にたどり着きました。これはまさに必要な転送メカニズムです。この時点で、私は Go の進化の仕方に非常に満足していました。Go の初期の頃からエイリアスについて話し合ってきました。実際、最初の仕様書案にはエイリアス宣言を使用した例がありますが、エイリアス、そして後に型エイリアスについて議論するたびに、明確なユースケースがなかったため、それらを省略しました。今回、エイリアスを追加することを提案したのは、それらが洗練された概念だったからではなく、スケーラブルなソフトウェア開発という Go の目標を達成する上で重要な実際的な問題を解決したからです。これが Go の将来の変更のモデルになることを願っていました。

春の後半、Robert と Rob は提案を書き、Robert はGophercon 2016 ライトニングトークでそれを発表しました。次の数か月は順調に進まず、Go の将来の変更のモデルには kesinlikle なりませんでした。私たちが学んだ多くの教訓の1つは、問題の重要性を説明することの重要性でした。

少し前、問題が発生する可能性のある背景と理由を説明しましたが、問題がいつかあなたに影響を与えるかどうかを評価するのに役立つ具体的な例はありませんでした。昨夏の提案とライトニングトークでは、パッケージ C、L、L1、および C1 から Cn を含む抽象的な例を示しましたが、開発者が関連付けることができる具体的な例はありませんでした。その結果、コミュニティからのフィードバックのほとんどは、エイリアスは他のすべての人ではなく、Google の問題のみを解決するという考えに基づいていました。

Google の私たちが当初、うるう秒の時間リセットを正しく処理することの重要性を理解していなかったのと同様に、私たちは、大規模な変更中の段階的なコードの移行と修復を処理することの重要性を、より広範な Go コミュニティに効果的に伝えることができませんでした。

秋に、私たちはやり直しました。私は講演を行い、オープンソースのコードベースから引用した複数の具体的な例を使用して問題を提示する記事を書き、この問題が Google 内だけでなく、あらゆる場所でどのように発生するかを示しました。より多くの人々が問題を理解し、その重要性を理解できるようになったので、私たちはどのような解決策が最適かについて生産的な議論を行いました。型エイリアスはGo 1.9 に含まれるようになり、Go がこれまで以上に大きなコードベースにスケーリングするのに役立ちます。

経験レポート

ここでの教訓は、異なる環境で作業している人が理解できる方法で問題の重要性を説明することは難しいが不可欠であるということです。コミュニティとして Go に対する大きな変更について議論するには、解決したい問題の重要性を説明することに特に注意を払う必要があります。Cloudflare のブログ記事や私のリファクタリング記事のように、問題が実際のプログラムや実際の本番システムにどのように影響するかを示すことが、最も明確な方法です。

このような経験レポートは、抽象的な問題を具体的な問題に変え、その重要性を理解するのに役立ちます。また、テストケースとしても機能します。提案された解決策は、レポートが説明する実際の現実世界の問題に対する影響を調べることで評価できます。

例えば、私は最近ジェネリクスを検討していますが、Goユーザーがジェネリクスを使って解決する必要がある詳細で具体的な問題については、明確なイメージがありません。その結果、レシーバーとは別にパラメータ化されたメソッド、つまりジェネリックメソッドをサポートするかどうかといった設計上の質問に答えることができません。現実世界のユースケースが大量にあれば、重要なユースケースを検証することで、このような質問に答え始めることができます。

別の例として、エラーインターフェースをさまざまな方法で拡張する提案を見てきましたが、大規模なGoプログラムがエラーをどのように理解し、処理しようとしているのかを示す経験報告は見たことがありません。ましてや、現在のエラーインターフェースがそれらの試みをどのように妨げているのかを示す報告は見たことがありません。このような報告は、問題の詳細と重要性をよりよく理解するのに役立ち、それは問題を解決する前にしなければならないことです。

他にも例を挙げることができます。Goに対するすべての主要な変更の可能性は、人々が現在どのようにGoを使用しているか、そしてなぜそれが十分に機能していないのかを文書化した1つ以上の経験報告によって動機付けられるべきです。Goで検討できる明らかな主要な変更について、私はそのような報告をあまり知りません。特に、現実世界の例で説明された報告は知りません。

これらの報告は、Go 2の提案プロセスの素材であり、皆さんのGoでの経験を理解するために、皆さんに書いていただく必要があります。Goユーザーは50万人おり、幅広い環境で働いていますが、私たちはそれほど多くありません。自分のブログに投稿を書くか、Medium に投稿を書くか、GitHub Gist に書く（Markdownの場合は .md ファイル拡張子を追加する）か、Googleドキュメント に書くか、その他の好きな公開メカニズムを使用してください。投稿後、新しいWikiページ golang.org/wiki/ExperienceReports に投稿を追加してください。

解決策

解決すべき問題を特定し、説明する方法がわかったので、すべての問題が言語の変更によって解決されるのが最善ではなく、それでも問題ないことに簡単に触れておきます。

解決したい問題の1つは、コンピューターは基本的な算術演算中に追加の結果を計算できることが多いですが、Goはそれらの結果に直接アクセスできないことです。2013年に、Robertは2つの結果（「カンマOK」）式という考え方を基本的な算術に拡張することを提案しました。たとえば、xとyがuint32値である場合、lo, hi = x * y は通常の低い32ビットだけでなく、積の高い32ビットも返します。この問題は特に重要とは思われなかったため、潜在的な解決策を記録 しましたが、実装しませんでした。私たちは待ちました。

最近、Go 1.9用に、さまざまなビット操作関数を含む math/bitsパッケージ を設計しました。

package bits // import "math/bits"

func LeadingZeros32(x uint32) int
func Len32(x uint32) int
func OnesCount32(x uint32) int
func Reverse32(x uint32) uint32
func ReverseBytes32(x uint32) uint32
func RotateLeft32(x uint32, k int) uint32
func TrailingZeros32(x uint32) int
...

パッケージには各関数の優れたGo実装がありますが、コンパイラは利用可能な場合は特別なハードウェア命令を代用します。 math/bitsでのこの経験に基づいて、Robertと私は、言語を変更することで追加の算術結果を利用できるようにすることは賢明ではなく、代わりにmath/bitsのようなパッケージで適切な関数を定義する必要があると考えています。ここでは、最良の解決策は言語の変更ではなく、ライブラリの変更です。

Go 1.0の後で解決したかった別の問題は、ゴルーチンと共有メモリによってGoプログラムにレースを導入しやすくなり、本番環境でクラッシュやその他の誤動作が発生することでした。言語ベースの解決策は、データレースを許可しない、データレースのあるプログラムの作成、または少なくともコンパイルを不可能にする方法を見つけることでした。Goのような言語にそれをどのように適合させるかは、プログラミング言語の世界ではまだ未解決の問題です。代わりに、メインディストリビューションにツールを追加し、使いやすくしました。そのツールである レース検出器 は、Goエクスペリエンスに不可欠な部分となっています。ここでは、最良の解決策は言語の変更ではなく、ランタイムとツールの変更でした。

もちろん、言語の変更もありますが、すべて問題が言語で解決されるわけではありません。

Go 2の出荷

最後に、Go 2をどのように出荷および提供しますか？

最良の計画は、Go 2の 下位互換性のある部分 を、Go 1リリースシーケンスの一部として、機能ごとに段階的に出荷することだと思います。これには、いくつかの重要な特性があります。まず、Go 1リリースを 通常のスケジュール に保ち、ユーザーが現在依存しているタイムリーなバグ修正と改善を継続します。次に、Go 1とGo 2の間で開発作業が分割されるのを回避します。3つ目に、Go 1とGo 2の乖離を回避し、全員の最終的な移行を容易にします。4つ目に、一度に1つの変更に集中して提供できるため、品質の維持に役立ちます。5つ目に、下位互換性のある機能を設計するように促します。

変更がGo 1リリースに反映される前に、議論と計画のための時間が必要になりますが、今から約1年後、Go 1.12前後でマイナーな変更が見られるようになるのは妥当だと思います。それはまた、私たちに最初にパッケージ管理サポートを提供する時間を与えます。

すべての下位互換性のある作業が完了したら、たとえばGo 1.20で、Go 2.0で下位互換性のない変更を行うことができます。下位互換性のない変更がないことが判明した場合、Go 1.20 *が* Go 2.0であると宣言するかもしれません。いずれにせよ、その時点で、Go 1.Xリリースシーケンスの作業からGo 2.Xシーケンスの作業に移行します。おそらく、最終的なGo 1.Xリリースのサポート期間が延長されます。

これはすべて少し推測的なものであり、私が今述べた特定のリリース番号はおおよその見積もりのプレースホルダーですが、Go 1を放棄するつもりはなく、実際には可能な限りGo 1を取り入れることを明確にしたいと思います。

ヘルプ募集

私たちはあなたの助けが必要です。

Go 2の議論は今日から始まり、メーリングリストやイシュートラッカーなどの公開フォーラムで公開されます。道のりのすべてのステップで私たちを助けてください。

今日、私たちが最も必要としているのは経験報告です。Goがどのように機能しているか、そしてもっと重要なことに、どのように機能していないかを教えてください。ブログ記事を書き、実際の例、具体的な詳細、実際の経験を含めてください。そして、私たちの Wikiページ にリンクしてください。そうすれば、私たちGoコミュニティがGoについて何を変更したいのかについて話し始めることができます。

ありがとうございました。