Goブログ

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

サム・ホワイトド
2017年8月3日

はじめに

GopherConの前日、Goチームメンバーとコントリビューターのグループがデンバーに集まり、Goプロジェクトの未来について議論し、計画を立てました。これは、Goプロジェクトにとって重要なマイルストーンとなる、初めてのイベントでした。イベントは、テーマに沿った集中的な議論を中心とした午前中のセッションと、少人数のブレークアウトグループによる円卓会議で構成される午後のセッションで構成されていました。

コンパイラとランタイム

コンパイラとランタイムのセッションは、gcおよび関連ツールをインポート可能なパッケージにリファクタリングすることについての議論から始まりました。これにより、コアツールと、コンパイラ自体を埋め込んで迅速な構文チェックを行うことができるIDEのオーバーヘッドが削減されます。コードはメモリ内で完全にコンパイルすることもでき、ファイルシステムを提供しない環境や、開発中にテストを継続的に実行して破損のライブレポートを取得する場合に役立ちます。この作業の方向性を追求するかどうかについてのさらなる議論は、今後メーリングリストで取り上げられる可能性が高いです。

最適化されたアセンブリコードとGoとのギャップを埋めることについても、多くの議論がありました。Goのほとんどの暗号コードは、パフォーマンスの理由でアセンブリで記述されています。これは、デバッグ、保守、および読み取りを困難にします。さらに、一度アセンブリの記述を始めると、多くの場合、Goに戻って呼び出すことができず、コードの再利用が制限されます。Goでの書き換えにより、保守が容易になります。プロセッサ固有命令と128ビット算術のより良いサポートを追加することで、Goの暗号パフォーマンスが向上します。1.9で追加される新しいmath/bitsパッケージをこの目的で拡張することが提案されました。

コンパイラとランタイムの開発にあまり詳しくない私にとって、これはその日の最も興味深いセッションの1つでした。現在の世界の状況、問題点、そして人々がこれからどこに行きたいのかについて、多くのことを学びました。

依存関係管理

depチームからのプロジェクトの状況に関する簡単なアップデートの後、依存関係管理セッションは、dep（またはdepに似たもの）がパッケージ管理の主要な手段になった後のGoの世界の動作方法に重点を置きました。Goを使いやすくし、depを使いやすくするための作業はすでに開始されています。Go 1.8では、GOPATHのデフォルト値が導入されたため、ユーザーはdepを使い始める前にGoのbinディレクトリを$PATHに追加するだけで済みます。

depによって可能になる可能性のあるもう1つの将来の使いやすさの向上は、Goを任意のディレクトリ（GOPATH内のワークスペースだけではない）から動作させることができるようにすることで、人々が他の言語で使用することに慣れているディレクトリ構造とワークフローを使用できるようにすることです。また、ユーザーをパスへのbinディレクトリの追加プロセス、またはプロセスの自動化を通して案内することで、将来go installをより簡単にできる可能性もあります。Goツールの使いやすさを向上させるための多くの良いオプションがあり、メーリングリストで議論が続く可能性があります。

標準ライブラリ

Go言語の将来に関する議論のほとんどは、Russ Coxのブログ投稿:Toward Go 2で取り上げられているため、標準ライブラリセッションに進みましょう。

標準ライブラリとサブリポジトリへのコントリビューターとして、このセッションは私にとって特に興味深いものでした。標準ライブラリとサブリポジトリに何が含まれ、どれだけ変更できるかは、明確に定義されていないトピックです。Goチームにとって、特定の専門知識を持つ人がいない場合もある多数のパッケージを維持するのは困難な場合があります。標準ライブラリのパッケージに重要な修正を加えるには、新しいバージョンのGoがリリースされるまで6か月待つ必要があります（セキュリティの問題の場合はポイントリリースを出荷する必要があり、チームのリソースが枯渇します）。より良い依存関係管理により、一部のパッケージを標準ライブラリから独自のプロジェクトに移行し、独自のリリーススケジュールを設定できるようになります。

標準ライブラリのインターフェースでは達成が難しいことについても、いくつかの議論がありました。たとえば、ブロッキング読み取り操作をキャンセルできるように、io.Readerがコンテキストを受け入れることができれば便利です。

標準ライブラリで何が変わるかを判断するには、さらに多くのエクスペリエンスレポートが必要です。

ツールとエディター

エディターが使用する言語サーバーは、ツールセッションでホットトピックであり、多くの人がIDEとツールの開発者がコードとパッケージに関する情報をインデックス化して表示するための共通の「Go言語サーバー」を採用することを推奨していました。MicrosoftのLanguage Server Protocolは、エディターとIDEでの幅広いサポートがあるため、良い出発点として提案されました。

Jaana Burcu Doganは、分散トレーシングに関する彼女の仕事と、ランタイムイベントに関する情報を取得してトレースに添付する方法を容易にする方法についても説明しました。統計を報告するための標準的な「カウンター」APIを提案しましたが、そのようなAPIを設計する前に、コミュニティからの具体的なエクスペリエンスレポートが必要です。

コントリビューターエクスペリエンス

その日の最後のセッションは、コントリビューターエクスペリエンスに関するものでした。最初の議論は、現在のGerritワークフローを新しいコントリビューターにとってより簡単にする方法に関するものでした。これは、いくつかのリポジトリのドキュメントの改善につながり、数日後の新しいコントリビューターワークショップにも影響を与えました。

作業するタスクを見つけやすくすること、ユーザーが問題トラッカーでガーデニングタスクを実行できるようにすること、レビューアを見つけやすくすることなども検討されました。今後数週間から数か月で、これらの多くの貢献プロセスの分野が改善されることを期待しています。

ブレークアウトセッション

午後は、参加者がより小規模なグループに分かれて、午前中のセッションのいくつかのトピックについてより詳細な議論を行いました。これらの議論には、より具体的な目標がありました。たとえば、あるグループは、エクスペリエンスレポートの有用な部分と、Goユーザーエクスペリエンスを文書化する既存の文献のリストを特定することに取り組み、エクスペリエンスレポートwikiページを作成しました。

別のグループは、Goにおけるエラーの将来について検討しました。多くのGoユーザーは、最初はerrorがインターフェースであるという事実を混乱したり、理解しなかったりし、io.EOFなどのセンティネルエラーをマスクせずにエラーにもっと多くの情報を添付するのが難しい場合があります。ブレークアウトセッションでは、今後のGoリリースでこれらの問題を解決できる具体的な方法、そしてGo 2でエラー処理を改善できる方法について議論しました。

コミュニティ

技術的な議論以外にも、サミットは世界中から集まった人々のグループが、多くの場合初めて顔を合わせて会う機会を提供しました。異なるバックグラウンドとアイデアを持つ多様なグループが単一のコミュニティで協力するために、相互の尊敬と友情感を育むために、直接顔を合わせる時間には代えがたいものがあります。休憩時間には、Goチームメンバーがコントリビューターの間で分散し、Goと一般的な社会化の両方について議論しました。これは、毎日私たちのコードをレビューする名前の顔を見つけるのに本当に役立ちました。

RussがToward Go 2で説明したように、効果的なコミュニケーションには、対象者を知る必要があります。Goコントリビューターの幅広いサンプルを1つの部屋に集めることで、Goの対象者をよりよく理解し、Goの将来に関する多くの生産的な議論を開始することができました。今後、このようなイベントをより頻繁に行い、議論とコミュニティ感を促進することを目指しています。

写真：Steve Francia