はじめに

3年連続で、GoチームとコントリビューターはGopherConの前日に集まり、Goプロジェクトの将来について議論し計画を立てました。イベントでは、ブレイクアウトグループへの自己組織化、午前中の提案プロセスに関するタウンホール形式の議論、そしてコントリビューターが選択したトピックに基づく午後のブレイクアウト円卓会議が含まれました。私たちは5人のコントリビューターに、今年のサミットでのさまざまな議論での経験について執筆を依頼しました。

(写真：Steve Francia)

コンパイラとランタイム（Lynn Bogerによるレポート）

Goコントリビューターサミットは、Goに貢献する他の人々とトピックやアイデアを話し合う絶好の機会でした。

その日は、部屋にいる全員と会うことから始まりました。GoのコアチームとGoに積極的に貢献している他の人々の良い組み合わせでした。そこから、興味のあるトピックと、大きなグループを小さなグループに分割する方法を決めました。私の関心分野はコンパイラなので、そのグループに参加し、ほとんどの時間を彼らと過ごしました。

最初の会議では、多くのトピックが提起され、その結果、コンパイラグループは一日中会議を続けることにしました。私は興味のあるいくつかのトピックを共有し、他の人が提案した多くのトピックも私にとって興味深いものでした。リストにあるすべての項目が詳細に議論されたわけではありません。以下は、最も関心があり議論されたトピックのリストで、他のトピックについてなされた簡単なコメントが続きます。

バイナリサイズ。バイナリサイズに関する懸念が表明され、特にリリースごとに増加し続けていることが指摘されました。インライン化の増加やその他の最適化など、いくつかの考えられる理由が特定されました。おそらく、小さなバイナリを望むユーザーのセットと、可能な限り最高のパフォーマンスを望む別のグループがあり、一部のユーザーは気にしないかもしれません。これはTinyGoのトピックにつながり、TinyGoはGoの完全な実装ではないこと、そしてTinyGoがGoから分岐してユーザーベースを分割しないようにすることが重要であると指摘されました。ユーザー間のニーズと現在のサイズに寄与する正確な理由を理解するために、さらなる調査が必要です。パフォーマンスに影響を与えることなくサイズを削減する機会があれば、それらの変更を行うことができますが、パフォーマンスが影響を受ける場合、一部のユーザーはより良いパフォーマンスを好むでしょう。

ベクターアセンブリ。Goでベクターアセンブリを活用する方法についてしばらく議論され、過去にも関心のあったトピックです。これらすべてがベクター命令の使用に関連していますが、その使用方法が異なるため、ベクターアセンブリのトピックから始めて、これを3つの独立した可能性に分けました。これはコンパイラのトレードオフのもう一つのケースです。

ほとんどのターゲットでは、crypto、hash、mathなどの標準パッケージには、可能な限り最高のパフォーマンスを得るためにアセンブリの使用が必要な重要な関数があります。しかし、アセンブリで書かれた大きな関数は、サポートと保守が難しく、各ターゲットプラットフォームで異なる実装が必要になる場合があります。一つの解決策は、マクロアセンブリや他の高レベル生成技術を利用して、ベクターアセンブリを読みやすく理解しやすくすることです。

この問題のもう一つの側面は、Goコンパイラを強化してコードシーケンスを「SIMD化」し、ベクター命令を利用するようにGoソースファイルをコンパイルする際に、Goコンパイラが直接SIMDベクター命令を生成できるかどうかです。GoコンパイラにSIMDを実装すると、複雑さとコンパイル時間が増加し、常にパフォーマンスが向上するコードになるとは限りません。コードの変換方法は、場合によってはターゲットプラットフォームに依存する可能性があり、それは理想的ではありません。

Goでベクター命令を活用するもう一つの方法は、Goソースコード内からベクター命令をより簡単に利用できるようにする方法を提供することです。議論されたトピックは、組み込み関数（イントリンシックス）、またはRustのような他のコンパイラに存在する実装でした。gccでは一部のプラットフォームでインラインアセンブリが提供されており、Goもこの機能を提供できる可能性がありますが、インラインアセンブリとGoコードを混ぜると、レジスタの使用状況の追跡やデバッグに関してコンパイラの複雑さが増すことは経験上知っています。これにより、ユーザーはコンパイラが予期しない、または望まないことを行うことができ、複雑さのレベルが追加されます。理想的ではない場所に挿入される可能性があります。

まとめると、利用可能なベクター命令を活用し、より簡単かつ安全に記述できる方法を提供することが重要です。可能な限り、関数はGoコードを最大限に利用し、高レベルのアセンブリを使用する方法を見つける可能性があります。これらのアイデアの一部を実装するために実験的なベクターパッケージを設計することについて議論がありました。

新しい呼び出し規約。数人が、レジスタベースの呼び出し規約を提供するためのABIの変更のトピックに関心を持っていました。現在の状況が詳細に報告されました。それが使用できるようになるまでに何が残っているかについて議論がありました。ABI仕様を最初に記述する必要があり、それがいつ行われるかは明らかではありませんでした。私はこれが他のプラットフォームよりも一部のターゲットプラットフォームに利益をもたらすことを知っていますし、レジスタ呼び出し規約は他のプラットフォームのほとんどのコンパイラで使用されています。

一般的な最適化。x86以外のプラットフォームでより有益な特定の最適化が議論されました。特に、不変量の巻き上げや強度低下などのループ最適化は実行可能であり、一部のプラットフォームでより大きな利益をもたらす可能性があります。潜在的な解決策が議論され、実装はそれらの改善が重要であると考えるターゲットに任されることになるでしょう。

フィードバック指向最適化。これは将来の可能な機能強化として議論され、論争になりました。私の経験では、コードの最適化に後で利用できるパフォーマンスデータを収集するために使用する意味のあるプログラムを見つけるのは困難です。これはコンパイル時間を増加させ、少数のプログラムにのみ意味のあるデータを保存するために多くのスペースを必要とします。

保留中の提出物。グループ内の数人のメンバーは、makesliceの改善やrulegenの書き換えなど、彼らが作業しており、まもなく提出する予定の変更について言及しました。

コンパイル時間の懸念。コンパイル時間について簡単に議論されました。フェーズタイミングがGOSSAFUNC出力に追加されたことが指摘されました。

コンパイラコントリビューター間のコミュニケーション。Goコンパイラのメーリングリストが必要かどうか尋ねられました。その目的のためにgolang-devを使用し、件名に「compiler」を追加して識別することが提案されました。golang-devのトラフィックが多すぎる場合は、将来的にコンパイラ固有のメーリングリストを検討することができます。

コミュニティ。コミュニティで積極的に活動しており、同様の関心分野を持つ人々とつながるという点で、この日は非常に有益でした。問題やメーリングリスト、CLに表示されるユーザー名でしか知らなかった多くの人々と会うことができました。いくつかのトピックや既存の問題について話し合い、オンラインでの返信を待つことなく直接インタラクティブなフィードバックを得ることができました。私が遭遇した問題について課題を提起するように勧められました。これらのつながりは、この日だけでなく、会議中に出会った他の人々との間でも起こり、この初日に紹介されたことで、多くの興味深い議論につながりました。これらのつながりが、将来、より効果的なコミュニケーションと、問題やコード変更のより良い処理につながることを願っています。

ツール（Paul Jollyによるレポート）

コントリビューターサミット中のツールブレイクアウトセッションは拡張形式で行われ、メインカンファレンス開催日にはgolang-toolsグループが主催する2つのセッションが追加されました。この概要は、コントリビューターワークショップでのツールセッションと、メインカンファレンス開催日でのgolang-toolsセッションの統合レポートの2つの部分に分かれています。

コントリビューターサミット。ツールセッションは、集まった約25名からの自己紹介から始まり、その後、gopls、ARM 32ビット、eval、signal、analysis、go/packages api、リファクタリング、pprof、モジュールエクスペリエンス、モノレポ分析、goモバイル、依存関係、エディタ統合、コンパイラ最適化の決定、デバッグ、視覚化、ドキュメントなど、トピックのブレインストーミングが行われました。多くの人が多くのツールに大きな関心を持っていました！

このセッションは2つの領域（時間的制約のため）に焦点を当てました：goplsと視覚化。Gopls（発音：「ごー・ぷりーず」）はGoのLanguage Server Protocol (LSP)サーバーの実装です。goplsの主任開発者であるRebecca StamblerとGoツールチームの残りのメンバーは、goplsに関する人々の経験、つまり安定性、不足している機能、エディタとの統合の機能状況などに興味を持っていました。一般的な意見としては、goplsは非常に良好な状態であり、ほとんどのユースケースで非常にうまく機能しているというものでした。統合テストのカバレッジは改善される必要がありますが、これはすべてのエディタで「正しく」行うのが難しい問題です。ユーザーがエディタを介して遭遇するgoplsエラーのより良い報告方法、テレメトリー/診断、goplsのパフォーマンスメトリクスなどについて議論しました。これらすべてのトピックは、メインカンファレンス開催日のgolang-toolsセッションでより詳細にカバーされました（以下を参照）。議論の主要な領域は、goplsを拡張する方法、例えば、追加のgo/analysis vetのようなチェック、リンターチェック、リファクタリングなどでした。現在、良い解決策はありませんが、積極的に調査中です。会話は視覚化という非常に広範なトピックに移り、Anthony Starksによるデモベースの紹介がありました（彼は偶然にもGopherCon 2018でGo for information displaysについて素晴らしい講演を行いました）。

カンファレンス開催日。メインカンファレンス開催日のgolang-toolsセッションは、GopherCon 2018でのグループ発足以来行われている月次会議の続きでした。1日目と2日目のセッションの完全な議事録が利用可能です。これらのセッションも各セッションに25～30人が参加し、盛況でした。Goツールチームが多数（この分野への支援の好ましい兆候）参加しており、Uberのプラットフォームチームも参加していました。コントリビューターサミットとは対照的に、これらのセッションの目標は具体的な行動項目を持ち帰ることでした。

Gopls。Goplsの「準備状況」は両セッションの主要な焦点でした。この答えは実質的に、エディタ統合者に対して「goplsの最初の良いバージョンができました」と伝えるべき時期を決定し、その後、goplsで動作することが知られている「承認された」エディタ統合/プラグインのリストをまとめることに帰結しました。エディタ統合/プラグインのこの「認証」の中心となるのは、ユーザーがgoplsで経験する問題を報告するための明確に定義されたプロセスです。パフォーマンスとメモリは、この最初の「リリース」の妨げにはなりません。前日のコントリビューターサミットで始まったgoplsの拡張方法に関する議論は、本格的に続きました。goplsを拡張することには多くの明白な利点と魅力がありますが（カスタムgo/analysisチェック、リンターサポート、リファクタリング、コード生成…）、これをスケーラブルな方法で実装する方法については明確な答えがありません。集まった人々は、これを最初の「リリース」の妨げと見なすべきではないが、引き続き取り組むべきであることに同意しました。goplsとエディタ統合の精神に則り、GoツールチームのHeschi Kreinickがデバッグサポートのトピックを提起しました。DelveはGoの事実上のデバッガとなり、良好な状態にあります。今、デバッガとエディタの統合の状況を確立する必要があります。これはgoplsと「承認された」統合と同様のプロセスに従います。

Go Discovery Site。2番目のgolang-toolsセッションは、GoツールチームのJulie QiuによるGo Discovery Siteへの素晴らしい紹介と、簡単なデモから始まりました。JulieはDiscovery Siteの計画について話しました。プロジェクトのオープンソース化、検索ランキングで使用されるシグナル、godoc.orgが最終的にどのように置き換えられるか、サブモジュールがどのように機能するか、ユーザーが新しいメジャーバージョンをどのように発見できるかなどです。

ビルドタグ。次に、gopls内でのビルドタグサポートに話が移りました。これは、明らかに理解を深める必要がある領域です（現在、issue 33389でユースケースが収集されています）。この議論を受けて、セッションはJetBrains GoLandチームのAlexander Zolotovが、GoLandがすでに多くの経験を積んでいることから、goplsとGoLandチームがこの分野や他の分野で経験を共有すべきであると提案して締めくくられました。

参加しませんか！ ツール関連のトピックについては何日も話し続けることができたでしょう！朗報は、golang-toolsの呼び出しが今後も続くことです。Goツールに関心のある方はどなたでも大歓迎です。wikiに詳細が記載されています。

エンタープライズ利用（Daniel Theophanesによるレポート）

あまり発言しない開発者のニーズを積極的に尋ねることは、Go言語にとって最大の課題であり、最大の成果となるでしょう。Goコミュニティに積極的に参加しないプログラマーの大きなセグメントが存在します。ビジネスアソシエイト、マーケター、または品質保証の担当者でありながら開発も行う人もいます。経営者の立場に立ち、採用や技術決定を行う人もいます。また、単に仕事をこなして家族の元に戻る人もいます。そして最後に、これらの開発者の多くは、厳格なIP保護契約を持つ企業で働いていることが多いです。これらの開発者のほとんどは、オープンソースやGoコミュニティの提案に直接参加することはないでしょうが、Goを使用できるかどうかは両方に依存します。

GoコミュニティとGoの提案は、あまり発言しない開発者のニーズを理解する必要があります。Goの提案は、何が採用され、使用されるかに大きな影響を与える可能性があります。例えば、vendorフォルダやその後のGoモジュールプロキシは、ソースコードを厳密に管理し、通常、Goコミュニティとの直接的な会話が少ない企業にとって非常に重要です。これらのメカニズムがあることで、これらの組織はGoを使用できるようになります。したがって、現在のGoユーザーだけでなく、Goを検討したが採用しなかった開発者や組織にも注意を払う必要があります。これらの理由を理解する必要があります。

同様に、Goコミュニティが「エンタープライズ」環境に注意を払えば、Goを利用できる組織がさらに多く解放されるでしょう。アクティブディレクトリ認証が機能するようにすることで、別のエコシステムの使用を余儀なくされていたユーザーがGoを検討し続けることができます。WSDLがそのまま機能するようにすることで、一部のユーザーはGoをツールとして選択できます。誰もGo以外のユーザーをなだめるために盲目的に変更を加えることを提案したわけではありません。むしろ、Go言語とエコシステムにおける未開拓の可能性と認識されていない障害を認識すべきです。

外部からこの情報を積極的に収集するためのいくつかの異なる可能性が議論されましたが、これは根本的に皆さんの助けを必要とする問題です。Goを検討したにもかかわらず使用していない組織にいる場合は、Goが選ばれなかった理由をお知らせください。Goがプログラミングタスクの一部にしか使用されておらず、他のタスクには使用されていない組織にいる場合は、なぜもっと使用されていないのでしょうか？採用に具体的な障害はありますか？

教育（Andy Walkerによるレポート）

今年のコントリビューターサミットで私が参加した円卓会議の1つは、Go教育、特に新しいGoプログラマーにどのようなリソースを提供し、それらをどのように改善できるかというトピックでした。非常に情熱的な主催者、エンジニア、教育者が多数参加しており、それぞれが、自分で設計したツール、書いたドキュメント、またはあらゆる種類の開発者に行ったワークショップを通じて、このテーマについて独自の視点を持っていました。

早い段階で、Goが最初のプログラミング言語として適しているかどうかという話になりました。私は確信が持てず、反対しました。Goは最初の言語としては良くない、と私は主張しました。なぜなら、そう意図されていないからです。Rob Pikeが2012年に書いたように、「この言語は、大規模なソフトウェアシステムを記述し、読み、デバッグし、保守する人々のために、そしてその人々によって設計された」のです。私にとって、この指導理念は明確です。Goは、経験豊富なエンジニアが使用するプロセスにおける認識された欠陥に対する意図的な反応であり、理想的なプログラミング言語を作成しようとする試みではありません。そのため、プログラミング概念に関するある程度の基本的な知識が前提とされています。

これは、golang.org/docの公式ドキュメントで明らかです。言語のインストール方法からすぐに始まり、ユーザーはC言語ライクな言語にすでに慣れているプログラマーを対象としたツアーに進みます。そこから、彼らは古典的な非モジュールGoワークスペースへの非常に基本的な紹介を提供するGoコードの書き方に進み、すぐにライブラリの記述とテストに移ります。最後に、Effective Goと、仕様を含む一連の参照があり、いくつかの例で締めくくられています。これらはすべて、C言語ライクな言語にすでに慣れている人にとっては適切なリソースですが、まだ多くの改善点があり、まったくの初心者やPythonのような言語から直接来た人向けのものは見つかりません。

アクセスしやすくインタラクティブな出発点として、ツアーは言語をより初心者フレンドリーにするための自然な最初のターゲットであり、それだけで多くの進歩が見込めると私は思います。まず、golang.orgのトップバーの最初のリンクでなくても、ドキュメントの最初のリンクとして、目立つように配置すべきです。好奇心旺盛なユーザーにすぐに飛び込んで言語を使い始めてもらうように促すべきです。また、他の一般的な言語から来る場合のオプションの入門セクションや、Goで遭遇する可能性のある違い、インタラクティブな演習を含めることも検討すべきです。これは、新しいGoプログラマーがすでに慣れている概念をGoにマッピングする上で大いに役立つでしょう。

経験豊富なプログラマー向けには、ツアーのほとんどのセクションにオプションのより深い解説が与えられ、Goにおける良いアーキテクチャの設計上の決定原則を列挙したより詳細なドキュメントやインタラクティブな演習を掘り下げることができます。彼らは次のような質問への答えを見つけるべきです

• ほとんどの場合、intを使用するように勧められているのに、なぜこんなに多くの整数型があるのですか？
• 値レシーバーを選択する良い理由はありますか？
• なぜ単純なintはあるのに、単純なfloatはないのですか？
• 送信専用チャネルと受信専用チャネルとは何ですか、そしていつそれらを使用しますか？
• 並行性プリミティブを効果的に構成するにはどうすればよいですか、そしてチャネルを使用したくないのはどのような場合ですか？
• uintは何に役立ちますか？ユーザーを正の値に制限するために使用すべきですか？なぜですか？

ツアーは、最初の実行を終えた後、言語設計におけるより興味深い選択肢のいくつかをより深く掘り下げるために再訪できる場所であるべきです。

しかし、もっとできることがあります。多くの人々は、アプリケーションを設計したり、特定の不満を解消したりする方法としてプログラミングを求め、最も慣れ親しんだインターフェースであるブラウザをターゲットにしたいと考えるでしょう。Goにはまだ良いフロントエンドのストーリーがありません。JavaScriptは、フロントエンドとバックエンドの両方の環境を真に提供する唯一の言語ですが、WASMは急速に第一級のプラットフォームになりつつあり、それを使ってできることはたくさんあります。The Go Play Spaceでvectyのようなものを提供したり、あるいはWASMをターゲットにしたGioを提供したりして、人々がすぐにブラウザでプログラミングを開始できるようにし、想像力を刺激し、プレイグラウンドからターミナル、そしてGitHubへの移行パスを提供することができます。

では、Goは最初の言語として良いのでしょうか？正直なところ、私にはわかりません。しかし、Goを起点としてプログラミングの専門職に就く人がかなりの数いるのは確かに事実であり、私は彼らと話し、彼らの道のりやプロセスについて学び、彼らの意見を取り入れてGo教育の未来を形作っていくことに非常に興味があります。

学習プラットフォーム（Ronna Steinbergによるレポート）

Goの学習プラットフォームがどのようなものであるべきか、また、言語を効果的に教えるためにグローバルなリソースをどのように組み合わせることができるかについて議論しました。視覚化を用いると教育と学習が容易になること、そしてREPLが非常に満足感が高いという点で、概ね意見が一致しました。また、Goを用いた視覚化のための既存の解決策として、テンプレート、Go WASM、GopherJS、SVGおよびGIF生成についても概観しました。

新しい開発者にとってコンパイラエラーが理解できないという点も提起され、それをどのように処理するか、おそらくエラーのバンクとその有用性に関するアイデアを検討しました。一つのアイデアは、コンパイラをラップして、例と解決策とともにエラーを説明するというものでした。

その後、新しいグループが2回目のラウンドのために集まり、Go学習プラットフォームがどのようなUXを持つべきか、そしてコミュニティから既存の資料（講演、ブログ記事、ポッドキャストなど）を収集し、人々が学習できるプログラムにどのように組織化できるかについて、より焦点を当てました。そのようなプラットフォームはこれらの外部リソースにリンクすべきでしょうか？埋め込むべきでしょうか？引用すべきでしょうか？外部リソースへのリンクのポータル型ソリューションではナビゲーションが困難になり、学習体験が損なわれるという点で意見が一致し、そのような貢献は受動的であってはならず、貢献者はプラットフォームに自分の資料を掲載するためにオプトインする必要があるという結論に至りました。その後、プラットフォームに投票メカニズムを追加するというアイデアに大きな興奮があり、学習者も貢献者に変え、貢献者が自分の資料をプラットフォームに掲載するインセンティブを与えることになりました。

（Goの教育活動にご興味のある方は、Carmen Andoh candoh@google.comまでメールでお問い合わせください。）

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

コントリビューターデーでの素晴らしい議論に参加してくださったすべての皆様に感謝申し上げます。特に、これらのレポートを作成するために時間を割いてくださったLynn、Paul、Daniel、Andy、Ronnaに心より感謝いたします。