インフィニティソリューションズ株式会社ブログ

GO言語の評価

GO言語とは、Googleが開発したオープンソースの新しいプログラミング言語。コンパイルの遅さ等CやC++が持つ問題点を克服しつつ、Pythonのようなプログラミングの容易さを実現しようとしたもの。GO言語のバージョン1が3月末にリリースされ、Linux、FreeBSD、Mac、Windows版が提供されている。

このGO言語をどう評価するのか。SD TimesLarry O’Brien氏の記事をみてみよう。

Code Watch: On the Go

golang.org

‘The Go language, originally designed by Robert Griesemer, Rob Pike and Ken Thompson, dares speak that heresy. The three chief distinguishing characteristics of Go are fast compilation, garbage-collected memory, and concurrency via Communicating Sequential Processes.’

「GO言語は、元々Robert Griesemer氏、Rob Pike氏、Ken Thompson氏(全員Google)によって設計されたもので、(ハイパフォーマンスシステム用のプログラミング言語としては、CとC++以外にないということに)あえて異論を唱えいるもの。GO言語の際立った3つの特徴は、高速コンパイル、ガベージ・コレクション、逐次プロセスを通信しながらの並列処理だ。」

‘Walter Bright, designer of the D language, has said that it takes seven passes just to tokenize C++ text! In the same post, he lists non-parallelizable dependencies, preprocessor semantics, overuse of “#include,” and the lack of context-independence as other insuperable obstacles.’

— この中でもO’Brien氏は、高速コンパイルに注目する。何しろ大規模になればコンパイルに一晩なんていうのもザラだからだ。ところがこの高速化が難しい。

「D言語の設計者であるWalter Bright氏によれば、C++テキストをトークン化するだけで、7パス使っているとのこと。またその記事の中で、その他の避けがたい障害としては、並列化できない依存性、プリプロセッサのセマンティック、「#include」の使いすぎ、コンテキスト依存性の欠如などをあげている。」

— それほど得がたい高速コンパイルとは言っても、大規模システム向けとしてGO言語に飛びつく人はいまい、とO’Brien氏。

‘While it’s sensible to explore Go with a pilot project or two, it would be foolish to fully commit to a language with such a short track record and so few developers.’

「パイロットプロジェクトの1つか2つでGOを試してみるというのはあるだろうが、歴史も浅く、開発者も少ないため、この言語一筋に行くのはおろかであろう。」

‘Garbage-collected memory is not a surprising language feature in mainstream development, but relying on it at the systems level is one of Go’s bolder design decisions. The current garbage collector in Go is stop-the-world, non-generational and non-compacting, so it’s not a state-of-the-art leap forward. On the face of it, there is no easy way to use manual memory management with Go short of linking in a C-based module, so I could definitely see scenarios where that would seem to disqualify Go from consideration.’

「メモリガベージコレクションは、メインストリームの開発向け言語の機能としては驚くにあたらない。しかし、システムレベルのものに依存するというのは、GOの大胆な設計方針の1つだ。現在のGOのガベージ・コレクションは、stop-the-world(世界を止める:フルガベージ・コレクション)で、世代別GCでも、再配置(compact化)もない。従って、先進的な飛躍というわけではない。さらに、GOでは、Cベースのモジュールにリンクがないため、マニュアルのメモリ管理を使うのが用意ではない。従って、恐らくGO言語は考慮からはずされるだろう。」

‘The concurrency model of Go seems solid, derived from Hoare’s“Communicating Sequential Processes,” which, as you’d guess, is a message-passing model. The runtime is charged with handling the details of mapping your code’s very large number of conceptually concurrent entities to the relatively few and heavyweight OS-level threads; that removes an entire category of effort. However, although one is encouraged to use channels and “goroutines” (coroutines), Go has clearly left “enough rope to hang yourself with” when it comes to deadlocks and consistency pitfalls.’

「GOの並列処理モデルはHoares氏の「逐次プロセスの通信」、すなわちメッセージ・パッシングをベースとしており、確かなもの。実行時には、膨大な数の概念的な並列エンティティを比較的少なく、重いOSレベルのスレッドにマッピングする煩わしさがない。苦労しなくてもすむのだ。しかしながら、チャネルや「goroutines(coroutines)」を使いたいと思うかもしれないが、GO言語は、デッドロックや一貫性の落とし穴になると、「自分のことは自分がやれ」となってしまう。

‘Do I think Go’s concurrency model makes many core development easier? Definitely. Do I think it makes it as easy as, say, Erlang? I don’t think so.’

「Go言語の並列モデルは、コアな開発の多くを楽にできると思うか?その通り。Erlangなどと同じぐらい楽か?そうは思わない。」

— GO言語のどきゅめんとは、www.golang.orgに掲載されているが、O’Brien氏は入門として、David Chisnall氏の「The Go Programming Language Phrasebook」を薦めている。