Goブログ

コントリビューターサミット 2019

Carmen Andohとコントリビューター
2019年8月15日

はじめに

3年連続で、GoチームとコントリビューターはGopherConの前日に集まり、Goプロジェクトの将来について議論し、計画を立てました。イベントでは、ブレイクアウトグループへの自主的な編成、午前中の提案プロセスに関するタウンホール形式の議論、そしてコントリビューターが選択したトピックに基づく午後のブレイクアウトラウンドテーブルディスカッションが行われました。今年は5人のコントリビューターに、サミットでのさまざまな議論における彼らの経験について書いてもらいました。

（Steve Francia氏による写真）

コンパイラとランタイム（Lynn Boger氏による報告）

Goコントリビューターサミットは、Goに貢献している他の人々と出会い、トピックやアイデアについて議論する絶好の機会でした。

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

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

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

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

ほとんどのターゲットでは、暗号、ハッシュ、数学などの標準パッケージに重要な関数があり、最高のパフォーマンスを得るためにはアセンブリの使用が必要になります。ただし、アセンブリで記述された大きな関数は、サポートと保守が難しく、ターゲットプラットフォームごとに異なる実装が必要になる場合があります。1つの解決策は、マクロアセンブリまたは他の高レベルの生成手法を使用して、ベクトルアセンブリを読みやすく理解しやすくすることです。

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

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

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

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

一般的な最適化。x86以外のプラットフォームにとってより有益な特定の最適化について議論されました。特に、不変式の巻き上げや強度削減などのループ最適化を行うことができ、一部のプラットフォームでより多くのメリットが得られます。潜在的な解決策が議論され、実装はおそらくそれらの改善を重要と考えるターゲット次第でしょう。

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

**保留中の提出物**。グループの何人かのメンバーは、彼らが取り組んできた変更について言及し、まもなく提出する予定であると述べました。これには、makesliceの改善とrulegenの書き換えが含まれます。

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

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

**コミュニティ**。コミュニティで活動していて、同じような興味のある分野を持っている人々とつながるという点で、この1日は非常に有益だと感じました。問題やメーリングリスト、CLにユーザー名が表示されているだけで知っている多くの人々と会うことができました。いくつかのトピックや既存の問題について話し合い、オンラインでの回答を待つ代わりに、直接対話型のフィードバックを得ることができました。私が見てきた問題についてissueを書くよう勧められました。これらのつながりは、この日の間だけでなく、この最初の日に紹介された後、カンファレンスを通して他の人々に会うことで起こり、多くの興味深い議論につながりました。うまくいけば、これらのつながりは、より効果的なコミュニケーション、そして将来の問題やコード変更の改善された処理につながるでしょう。

ツール（Paul Jolly氏による報告）

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

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

セッションは（時間的制約から）2つの領域に焦点を当てました: goplsと可視化です。 Gopls（「ゴー プリーズ」と発音します）は、Go用の言語サーバープロトコル（LSP）サーバーの実装です。 goplsのリードオーサーであるRebecca Stamblerと、Goツールチームの他のメンバーは、goplsに関する人々の経験、つまり安定性、不足している機能、エディターとの統合の動作などについて意見を聞きたいと考えていました。一般的な意見としては、goplsは非常に良好な状態にあり、大多数のユースケースで非常にうまく機能しているというものでした。統合テストのカバレッジを改善する必要がありますが、これはすべてエディターで「正しく」動作させるのが難しい問題です。ユーザーがエディターで遭遇するgoplsエラーを報告するためのより良い手段、テレメトリ/診断、goplsパフォーマンスメトリクスについて議論しました。これらはすべて、主要なカンファレンスの日に行われたgolang-toolsセッションでより詳細に扱われたテーマです（下記参照）。議論の重要な領域は、goplsを拡張する方法、例えば、追加のgo/analysis vetのようなチェック、lintチェック、リファクタリングなどの形式での拡張でした。現在、良い解決策はありませんが、積極的に調査中です。会話は可視化という非常に幅広いトピックに移り、Anthony Starks（ちなみに、彼はGopherCon 2018で情報表示のためのGoに関する素晴らしい講演を行いました）によるデモベースの紹介が行われました。

カンファレンスの日。主要なカンファレンスの日に行われたgolang-toolsセッションは、GopherCon 2018でのグループ発足以来行われている月例電話会議の続きでした。1日目と2日目のセッションの完全なメモが利用可能です。これらのセッションには、各セッションに25〜30人が参加し、今回も盛況でした。Goツールチームは（この分野への支援の表れとして）強力な体制で参加し、Uberプラットフォームチームも参加しました。コントリビューターサミットとは対照的に、これらのセッションの目標は、具体的なアクションアイテムを持ち帰ることでした。

Gopls。Goplsの「準備状況」は、両方のセッションの主要な焦点でした。この回答は、事実上、エディターインテグレーターに「goplsの最初の適切なバージョンができました」と伝える時期を決定し、goplsで動作することが知られている「承認済み」エディター統合/プラグインのリストをまとめることに要約されました。エディター統合/プラグインのこの「認定」の中心となるのは、ユーザーがgoplsで経験する問題を報告できる明確に定義されたプロセスです。パフォーマンスとメモリは、この最初の「リリース」の障害にはなりません。前日のコントリビューターサミットで始まったgoplsの拡張方法に関する会話は、本格的に続けられました。goplsを拡張することには多くの明らかな利点と魅力がありますが（カスタムgo/analysisチェック、linterのサポート、リファクタリング、コード生成など）、スケーラブルな方法でこれを実装する方法については明確な答えがありません。参加者は、これは最初の「リリース」の障害と見なされるべきではなく、引き続き取り組むべきであることに同意しました。goplsとエディター統合の精神に基づき、GoツールチームのHeschi Kreinickは、デバッグサポートのトピックを取り上げました。DelveはGoのデファクトスタンダードのデバッガーとなり、良好な状態にあります。 désormaisは、goplsおよび「承認済み」統合と同様のプロセスに従って、デバッガーとエディターの統合の状態を確立する必要があります。

Goディスカバリーサイト。2回目のgolang-toolsセッションは、GoツールチームのJulie QiuによるGoディスカバリーサイトの優れた紹介と簡単なデモから始まりました。Julieは、ディスカバリーサイトの計画、つまりプロジェクトのオープンソース化、検索ランキングで使用されるシグナル、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の提案は、何が採用され、使用されるかに大きな影響を与える可能性があります。たとえば、ベンダーフォルダー、そして後にはGoモジュールプロキシは、ソースコードを厳密に管理し、通常はGoコミュニティとの直接の会話が少ない企業にとって非常に重要です。これらのメカニズムがあることで、これらの組織はGoをまったく使用することができます。したがって、現在のGoユーザーだけでなく、Goを検討したが選択しなかった開発者や組織にも注意を払う必要があります。これらの理由を理解する必要があります。

同様に、Goコミュニティが「エンタープライズ」環境に注意を払うことで、Goを利用できる多くの組織の門戸が開かれるでしょう。Active Directory認証が確実に機能することで、別のエコシステムを使用せざるを得ないユーザーはGoを使い続けることができます。WSDLが確実に機能することで、一部のユーザーはGoをツールとして選択できます。Go以外のユーザーをなだめるために盲目的に変更を加えることを提案した人はいません。むしろ、Go言語とエコシステムにおける未開拓の可能性と認識されていない障害を認識する必要があります。

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

教育（Andy Walkerによる報告）

今年のContributors Summitで私が参加したラウンドテーブルの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は何に適していますか？ユーザーを正の値に制限するために使用すべきですか？なぜダメなのですか？

ツアーは、最初の run-through が終わった後に再訪し、言語設計におけるより興味深い選択肢のいくつかに深く掘り下げることができる場所である必要があります。

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

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

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

Goの学習プラットフォームはどうあるべきか、そしてどのようにすれば世界中のリソースを結集して効果的にGo言語を教えることができるかについて話し合いました。視覚化によって学習が容易になり、REPL（Read-Eval-Print Loop）は非常に満足感を与えるという点で、概ね意見が一致しました。また、Goの視覚化のための既存のソリューションについても概要を説明しました。テンプレート、Go WASM、GopherJS、そしてSVGやGIFの生成などです。

初心者の開発者にとってコンパイラエラーが理解しにくいという問題も提起され、その対処方法について検討しました。例えば、エラーのバンクとその有用性などが考えられます。コンパイラのラッパーを作成し、エラーの説明、例、解決策を提供するというアイデアもありました。

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

（Goの教育活動にご協力いただける方は、Carmen Andoh（candoh@google.com）までメールでご連絡ください。）

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

コントリビューターデーでの素晴らしい議論に参加してくださった皆様に感謝いたします。特に、Lynn、Paul、Daniel、Andy、Ronnaの皆様には、レポート作成にご尽力いただき、ありがとうございました。