The Go Blog

Go チームとの対話

2013年6月6日

Google I/O 2013 で、Go チームのメンバー数名が「炉端談話」を開催しました。Robert Griesemer、Rob Pike、David Symonds、Andrew Gerrand、Ian Lance Taylor、Sameer Ajmani、Brad Fitzpatrick、そして Nigel Tao が、聴衆と世界中の人々から Go プロジェクトの様々な側面について質問を受けました。

昨年も I/O で同様のセッションを開催しました: Go チームに会う.

Google Moderator からの質問は、40分間の短いセッションで答えられるよりもはるかに多くありました。ここでは、ライブセッションで見逃した質問のいくつかにお答えします。

gc ツールチェーンのリンク速度（とメモリ使用量）は既知の問題です。 1.2 サイクル中にこれに対処する予定はありますか？

Rob: はい。私たちは常に、言語やライブラリだけでなく、ツールの性能を向上させる方法を考えています。

Go が急速に普及しているのを見て、非常に嬉しく思っています。 Google 内外で他の開発者と仕事をしてきた経験について教えてください。 残っている大きな問題点はありますか？

Robert: Go を真剣に試した多くの開発者は、Go に非常に満足しています。多くの人が、より小さく、より読みやすく、したがって保守しやすいコードベースになったと報告しています。C++ から移行した場合、コードサイズが 50% 以上削減されるのはよくあることです。Python から Go に切り替えた開発者は、例外なくパフォーマンスの向上に満足しています。典型的な不満は、言語の小さな不整合性についてです（そのうちのいくつかは、いずれ解消されるかもしれません）。私が驚いたのは、ジェネリクスの欠如についてほとんど誰も文句を言っていないことです。

Go はいつ Android 開発の第一級言語になるのでしょうか？

Andrew: それは素晴らしいことですが、今のところ発表することはありません。

Go の次期バージョンのロードマップはありますか？

Andrew: 私たちには、そのような機能ロードマップはありません。貢献者は、自分が興味を持っていることに取り組む傾向があります。活発な開発分野には、gc と gccgo コンパイラ、ガベージコレクタとランタイム、その他多くのものがあります。私たちは、刺激的な新しい追加の大部分は、ツールの改善という形で行われると予想しています。golang-dev メーリングリスト でデザインの議論やコードレビューを見つけることができます。

タイムラインについては、具体的な計画があります。2013年12月1日に Go 1.2 をリリースする予定です。

Go を外部で使用してもらいたい場所はどこですか？ Google 以外での Go の採用にとって、大きな成功は何でしょうか？ Go はどこに大きな影響を与える可能性があると思いますか？

Rob: Go がどこに展開されるかは、私たちではなく、ユーザー次第です。私たちは、Go が役に立つところならどこでも普及するのを見るのは嬉しいです。Go はサーバーサイドソフトウェアを念頭に置いて設計されており、そこで有望視されていますが、他の多くの分野でも強みを見せており、物語はまだ始まったばかりです。これから多くの驚きがあるでしょう。

Ian: スタートアップ企業は、既存のコードベースと連携する必要がないため、Go を使いやすくなっています。そのため、Go の将来の大きな成功は2つあると考えています。1つは、Google 以外の既存の大規模ソフトウェア企業による Go の大幅な利用です。もう1つは、Go を主に使用するスタートアップ企業の大規模な IPO または買収です。これらはどちらも間接的です。プログラミング言語の選択は、企業の成功には非常に小さな要素であることは明らかです。しかし、Go が成功したソフトウェアシステムの一部になり得ることを示すもう1つの方法となるでしょう。

Go のパッケージやオブジェクトを動的にロードする可能性と、Go でどのように機能するかについて、（さらに）考えてみましたか？ 特にインターフェースと組み合わせると、これは非常に興味深く表現力豊かな構成要素になる可能性があると思います。

Rob: これは活発な議論の的となっています。私たちは、この概念がどれほど強力であるかを理解しており、それほど遠くないうちに実装する方法を見つけられることを願っています。設計アプローチと、それを移植性を持たせる必要があることに、深刻な課題があります。

しばらく前に、最高級の database/sql ドライバをより中心的な場所に集めることについての議論がありました。 しかし、反対意見を持つ人もいました。 database/sql とそのドライバは来年どうなるのでしょうか？

Brad: データベースドライバ用の公式サブリポジトリ（"go.db"）を作成することもできますが、特定のドライバを過度に優遇してしまうことを懸念しています。現時点では、異なるドライバ間の健全な競争を見守りたいと考えています。SQLDrivers wiki ページ には、いくつかの優れたドライバがリストされています。

database/sql パッケージは、ドライバの不足のため、しばらくの間あまり注目されていませんでした。現在ではドライバが存在するため、パッケージの使用量が増加しており、正確性とパフォーマンスのバグが報告されるようになりました（そして修正されています）。修正は継続されますが、database/sql のインターフェースに大きな変更は計画されていません。パフォーマンスの向上や一部のドライバの支援のために、必要に応じて小さな拡張が行われる可能性があります。

バージョン管理の状況はどうですか？ GitHub からコードをインポートすることは、Go チームが推奨するベストプラクティスですか？ GitHub リポジトリに依存するコードを公開し、依存先の API が変更された場合はどうなりますか？

Ian: これはメーリングリストで頻繁に議論されています。私たちが社内で行っているのは、インポートされたコードのスナップショットを取得し、そのスナップショットを時々更新することです。こうすることで、API が変更されても、コードベースが予期せず壊れることはありません。しかし、私たちは、ライブラリを提供している人にとっては、このアプローチはあまりうまく機能しないことを理解しています。この分野では、良い提案を歓迎します。これは、言語自体ではなく、言語を取り巻くツールの側面であることを忘れないでください。これを修正する場所は、言語ではなくツールです。

Go とグラフィカルユーザーインターフェースはどうですか？

Rob: これは私にとって非常に興味深いテーマです。非常に初期の先行言語である Newsqueak は、グラフィックプログラム（当時はアプリと呼んでいました）を作成するために特別に設計されました。状況は大きく変わりましたが、Go の並行処理モデルは、インタラクティブグラフィックスの分野で多くのものを提供できると思います。

Andrew: 既存のグラフィックライブラリのバインディング や、Go 固有のプロジェクトがいくつかあります。有望なものの一つは go.uik ですが、まだ初期段階です。ネイティブアプリケーションを作成するための Go 固有の優れた UI ツールキットには大きな可能性があると思いますが（チャネルから受信することでユーザーイベントを処理することを考えてみてください）、本番品質のパッケージを開発するにはかなりの労力が必要です。いずれは実現すると確信しています。

それまでの間、Web はユーザーインターフェースにとって最も広く利用可能なプラットフォームです。Go は、バックエンドのみではありますが、Web アプリの構築に大きなサポートを提供します。

メーリングリストで Adam Langley は、TLS コードは外部グループによってレビューされていないため、本番環境で使用すべきではないと述べています。 コードをレビューする予定はありますか？ 並行 TLS の優れた安全な実装は非常に役立つでしょう。

Adam: 暗号化は、微妙で驚くべき方法で失敗しやすいことで有名であり、私は人間に過ぎません。Go の TLS コードに欠陥がないことを保証することはできないと感じており、それを誤って伝えたくありません。

コードにサイドチャネルの問題があることがわかっている箇所がいくつかあります。RSA コードはブラインドされていますが、一定時間ではありません。P-224 以外の楕円曲線は一定時間ではなく、Lucky13 攻撃が機能する可能性があります。後者の2つは、Go 1.2 のタイムフレームで、一定時間の P-256 実装と AES-GCM を使用して対処したいと考えています。

しかし、TLS スタックのレビューを行うために名乗り出た人はいませんし、Matasano などにレビューを依頼できるかどうか調査していません。それは Google が資金を提供するかどうかによって異なります。

GopherCon 2014 についてどう思いますか？チームの誰かが参加する予定はありますか？

Andrew: とても楽しみです。私たちの何人かはきっと参加するでしょう。