はじめに

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のデフォルト値が導入され、ユーザーはGoのbinディレクトリを$PATHに追加するだけでdepを使い始めることができるようになりました。

depが実現する可能性のあるもう1つの将来の使いやすさの改善は、Goが任意のディレクトリ（GOPATH内のワークスペースだけでなく）から機能できるようにすることです。これにより、人々は他の言語で使用しているディレクトリ構造とワークフローを使用できます。また、binディレクトリをパスに追加するプロセスをユーザーに案内するか、プロセスを自動化することで、将来的にgo installを容易にすることも可能かもしれません。Goのツールを使いやすくするための多くの良い選択肢があり、議論はメーリングリストで継続される可能性が高いです。

標準ライブラリ

Go言語の将来に関する議論のほとんどは、Russ Coxのブログ記事「Go 2へ向けて」でカバーされているため、標準ライブラリのセッションに移りましょう。

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

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

標準ライブラリで何が変更されるかを決定する前に、さらに多くの経験レポートが必要です。

ツールとエディタ

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

Jaana Burcu Doganは、分散トレースに関する彼女の作業と、ランタイムイベントに関する情報をより簡単に取得してトレースにアタッチする方法についても議論しました。統計を報告するための標準的な「カウンター」APIが提案されましたが、そのようなAPIを設計する前に、コミュニティからの具体的な経験レポートが必要になるでしょう。

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

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

作業するタスクを見つけやすくすること、ユーザーがIssueトラッカーで整理タスクを実行できるようにすること、レビュアーを見つけやすくすることも検討されました。今後数週間から数か月で、これらの貢献プロセスの多くの分野で改善が見られることを願っています！

分科会

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

別のグループは、Goのエラーの将来について検討しました。多くのGoユーザーは、errorがインターフェースであるという事実を最初に混乱したり理解できなかったりし、io.EOFのようなセンチネルエラーをマスクせずにエラーにさらに情報を付加することは困難です。分科会では、今後のGoリリースでこれらの問題の一部を修正できる具体的な方法について議論しましたが、Go 2でエラー処理を改善できる方法についても議論しました。

コミュニティ

技術的な議論以外にも、サミットは、世界中から集まった人々が、多くの場合初めて顔を合わせ、互いに話したり協力したりする機会を提供しました。相互の尊敬と友情の感覚を築く上で、少しの対面時間はかけがえのないものであり、異なる背景とアイデアを持つ多様なグループが1つのコミュニティで協力するために集まる際には不可欠です。休憩中、Goチームメンバーはコントリビューターの中に散らばり、Goについてだけでなく、一般的な交流についても議論し、毎日私たちのコードをレビューする人々の名前と顔を結びつけるのに本当に役立ちました。

RussがGo 2へ向けてで議論したように、効果的にコミュニケーションするには、聴衆を知る必要があります。Goコントリビューターの広範なサンプルが1つの部屋に集まることで、私たち全員がGoの聴衆をよりよく理解し、Goの将来について多くの生産的な議論を開始するのに役立ちました。今後、私たちは言論とコミュニティの感覚を促進するために、このようなイベントをより頻繁に行いたいと考えています。

写真：Steve Francia