昨日Goプロジェクトは4周年を迎えた(Go1がリリースされたのは2012年3月。4周年はプロジェクトの立ち上げからの計算)。GoはGoogleでRobert Griesemer氏、Rob Pike氏、Ken Thompsonwas氏によって開発され、オープンソースになる前にIan Taylor氏とRuss Cox氏が加わった。FAQによれば、
Goはシステムプログラミング向けの既存言語と環境に対する不満から生まれました。プログラミングは難しくなりすぎました。原因のひとつは言語の選択です。効率的にコンパイルでき、効率的に実行できて、プログラミングが簡単な言語を選ぶ必要がありますが、メインストリームの言語でこの3つを同時に満たす言語はありませんでした。安全性と実行の効率性よりもプログラミングしやすさを選ぶ開発者はC++やJavaよりもPythonやJavaScriptのような動的型付け言語を選びました。
Goは動的言語のプログラミングしやすさと静的言語の効率性と安全性を合体させる試みです。また、ネットワークコンピューティング、マルチコアコンピューティングをサポートしたモダンな言語にすることも目標です。そして、高速に動作することも目指しています。つまり、単一のサーバで大きな実行可能ファイルをコンパイルするのにも数秒しかかからないことです。これらの目的を達成するには、多くの言語的課題を解決する必要があります。例えば、表現豊かでかつ軽量な型システム、並列処理とガベージコレクション、堅牢な依存定義などです。これらはライブラリやツールでは解決できない課題です。新しい言語が必要だったのです。
Goの最新のリリースは1.1。2013年5月にリリースされている。Go 1.2は今月後半に発表される予定。互換性ドキュメントはGo 1によって将来かかれるプログラムの互換性を押し進め、互換性に対して積極的に取り組むようだ。これはほかの静的言語にない特徴だ。
最初にリリースされてから、Goを使う企業が増えている。パッケージアプリケーション用軽量コンテナツールを提供するDocker、マシンイメージを自動作成するツールPacker、分散メッセージングプラットフォームであるBitlyのNSQ、インフラ自動化システムであるCanonicalのJuJu、その他にも多くのプロジェクトで使われている。Free Software Foundationでさえ、デフォルトの言語としてGoでJavaを置き換えることについて議論している。DockerチームはなぜGoに移行したかについてのプレゼンを提供している。
運用側にとってGoの魅力はGoのプログラムはターゲットプラットフォーム上にある単一の実行ファイルに静的にリンクされていることだ。システムは追加のバイナリを事前にインストールしておく必要はない。また、衝突なしでサイドバイサイドで異なるバージョンを実行することも特に心配する必要はない。LinuxやJavaのようにライブラリをばらまいて、特定のセットアップ方法や事前にパスを構築するためのリゾルバが必要になるのとは大違いだ(すべてのプログラムで静的バイナリが重複してしまうのが欠点だが、ディスク容量は安い。大量のプロセスが立ち上がる環境では、メモリの圧迫の方が現実的な心配事だろうが、デブオプのツールは長時間は実行されない傾向がある)。
高可用性を持つマルチスレッドプログラムはGoのgoroutinesの恩恵を受けるだろう。goroutinesはマルチスレッド実行がErlangやOccamと似た方法でリクエストを処理できるようにする。これらの仕組みはHoare氏のCommunicating Sequential Processes(CSP)をベースにしている。メモリやスレッディングアクセスに対処する代わりに、CSPはそれぞれメッセージ/タスクのキューを持ち、これらのメッセージ/タスクをほかのCSPへ送信する。この処理はブロッキングで非同期の処理で各(ブロッキング)CSPは返却メッセージとして返却値をオリジナルのCSPへ送り返す。
Cloud FoundryはRubyからGoへ移行した。コマンドラインツールを事前設定なしに動作させるためだ。実際、バックエンドのサービスと通信する軽量なツールになった。もはやツールを頻繁に更新する必要はなく、小さなツールになっている。
数週間のうちにリリースされる予定のGo 1.2では、3つのインデックスを使ったスライスができるようになっている。例えば、a[1:10]という表現では、配列aの要素の1から10まで取り出せるが、a[1:2:10]という表現でスライスのキャパシティを定義できる。また、 will slice out every other value. A minor clarification on where nilが使われている部分が少しきれいになったことで参照時に混乱が生まれるかもしれない。その他の変更はリリースノートに記載されている。
Goに対する批判として、Goが古いリターンコード方式を採用していることが挙げられる。現在広く普及している例外をベースとした方式ではないのだ。そして、Erlangと違い、goroutinesはデフォルトでは同期ではないマップを受け渡すことができるため、メモリを汚染する場合がある。明らかなのはGoはニッチなユースケースに適用しやすいということだ。また、JavaやErlangのような言語と比べて、Cの軽量で安全な代替となるのはGoだろう。