2010年06月15日
Go 言語は組み込みに向く ? 向かない ?
Go の言語仕様は、マルチコアサポートや GC など、今後組み込みソフトウェア開発でもトレンドとなってくるような機能を一通り押さえている上に、既存の C ライブラリともリンク可能※です。
※ 正確には、cgo という一種のトランスレータを通し、リンク可能な形に変換するというしくみだったと思います。（最後に確認してからだいぶ時間が経っていますので、現在は変わっているかもしれません。）
参考: Google Go の歴史
しかしこの記事によると、Google 社の開発者たちは、Go による組み込みソフトウェア開発という可能性はあまり考慮して無いようです。
「組み込み」と一口に言いましても、それこそ人類初の小惑星間往復 60 億 km に成功したはやぶさのように、極めてリソースが制限された環境もあれば、デジタルテレビや HDD レコーダのように、ほとんど PC と遜色無いような環境まで、さまざまなものがあります。
もちろん、リソースが厳しく制限された環境において不向きというのは間違いでは無いのでしょうが、ここで言う「不向き」というのは、どのレベルの環境を念頭においての発言なのか、少し疑問があります。
Apple 社は iPhone などの開発言語に、Objective-C を採用しています。Objective-C は GC こそ標準ではありません※が、事実上の動的型付け (id 型) やリフレクションなどを含む、非常に柔軟なプログラミング言語です。 そのため、比較的大きなランタイムが必要となります。
(私は Apple 社の製品を一度も使ったことが無く、Objective-C 環境でプログラミングをした経験が全く無いので、具体的なバイナリサイズなどはピンとこないのですが。)
※ GC を採用した Objective-C 2.0 言語仕様や、GC モードを持つ GNU による実装なども存在するそうです。
また（私は組み込み Java にも疎いのですが）Java はもともと VM が必要で、さまざまな情報を含んだクラスファイルにコンパイルされ、GC やリフレクションなども備えたリッチな言語ですが、現在では携帯電話を初めとして広く組み込みソフトウェア開発でも使われていると思います。
これらの点を考えると、Go が特別バイナリサイズや速度面で不利とも思えないのです。
もちろん、iPhone や Android のように（比較的）リッチなハードウェアの上にモダンな OS が乗っているような組み込み開発は例外という認識なのかもしれません。
しかし、今後伸びる組み込みソフトウェア開発は、むしろそのようなリッチな分野なのではないかと思われます。
※ 正確には、cgo という一種のトランスレータを通し、リンク可能な形に変換するというしくみだったと思います。（最後に確認してからだいぶ時間が経っていますので、現在は変わっているかもしれません。）
参考: Google Go の歴史
しかしこの記事によると、Google 社の開発者たちは、Go による組み込みソフトウェア開発という可能性はあまり考慮して無いようです。
将来、GoでAndroidのアプリを作るといったことは？
組み込みはGoに不向きな分野です。動的型付けやリフレクションをサポートする上で必要な情報がバイナリの中に入るので、その分サイズが大きくなります。もっとも、組み込みデバイスはどんどん高性能になっているので、いずれ問題にならなくなるかもしれませんが。
「組み込み」と一口に言いましても、それこそ人類初の小惑星間往復 60 億 km に成功したはやぶさのように、極めてリソースが制限された環境もあれば、デジタルテレビや HDD レコーダのように、ほとんど PC と遜色無いような環境まで、さまざまなものがあります。
もちろん、リソースが厳しく制限された環境において不向きというのは間違いでは無いのでしょうが、ここで言う「不向き」というのは、どのレベルの環境を念頭においての発言なのか、少し疑問があります。
Apple 社は iPhone などの開発言語に、Objective-C を採用しています。Objective-C は GC こそ標準ではありません※が、事実上の動的型付け (id 型) やリフレクションなどを含む、非常に柔軟なプログラミング言語です。 そのため、比較的大きなランタイムが必要となります。
(私は Apple 社の製品を一度も使ったことが無く、Objective-C 環境でプログラミングをした経験が全く無いので、具体的なバイナリサイズなどはピンとこないのですが。)
※ GC を採用した Objective-C 2.0 言語仕様や、GC モードを持つ GNU による実装なども存在するそうです。
また（私は組み込み Java にも疎いのですが）Java はもともと VM が必要で、さまざまな情報を含んだクラスファイルにコンパイルされ、GC やリフレクションなども備えたリッチな言語ですが、現在では携帯電話を初めとして広く組み込みソフトウェア開発でも使われていると思います。
これらの点を考えると、Go が特別バイナリサイズや速度面で不利とも思えないのです。
もちろん、iPhone や Android のように（比較的）リッチなハードウェアの上にモダンな OS が乗っているような組み込み開発は例外という認識なのかもしれません。
しかし、今後伸びる組み込みソフトウェア開発は、むしろそのようなリッチな分野なのではないかと思われます。
トラックバックURL
コメント一覧
1. Posted by hik 2010年06月15日 14:44
言い換えにすぎないかと思いますが、java や objective-c が
適用可能な分野は lang. go は向くような気がします。
適用可能な分野は lang. go は向くような気がします。
2. Posted by 若槻 2010年06月15日 16:30
> hik さん
コメントありがとうございます。
言われてみれば、その通りですね。そしてそうなってくると、Go 言語が組み込みに向くか向かないかというよりも、むしろ Go 言語全体のバランスや、マルチコアサポートなどが、Objective-C や Java に比べて移行や採用のインセンティブとなり得るか ? という論点が重要になってくると思います。
コメントありがとうございます。
言われてみれば、その通りですね。そしてそうなってくると、Go 言語が組み込みに向くか向かないかというよりも、むしろ Go 言語全体のバランスや、マルチコアサポートなどが、Objective-C や Java に比べて移行や採用のインセンティブとなり得るか ? という論点が重要になってくると思います。
3. Posted by hik 2010年06月15日 17:56
組み込みというと最近の scale はとてつもなくなっています。
(つまり memory はそこそこあるが、何も環境がない、ようなところから、
UI や webkit が動く組み込みまであるわけで)
c compiler もなく、assembler と linker ぐらいしかないような
最初の環境(16 bit)で、scratch からの 組み込みを検討したことがあります。
そういったところでは、PyMite がよいのではと思いました。
具体的に source をみてみませんでしたが、これぐらいならなんとか
アセンブラでやれるかも、と...
(つまり memory はそこそこあるが、何も環境がない、ようなところから、
UI や webkit が動く組み込みまであるわけで)
c compiler もなく、assembler と linker ぐらいしかないような
最初の環境(16 bit)で、scratch からの 組み込みを検討したことがあります。
そういったところでは、PyMite がよいのではと思いました。
具体的に source をみてみませんでしたが、これぐらいならなんとか
アセンブラでやれるかも、と...
4. Posted by h_sakurai 2010年06月15日 23:21
Objecitve-Cの場合はスピードが必要ならCやC++を使うという手があるので
インターフェイス部分だけObjective-CであとはCでということもあるようです。
JavaもJ2MEではリフレクションなしでベリファイも事前にするいった工夫もしてました。(今は知りませんが)。
Goはソースコードまでバイナリに含んでいたりするみたいですしね。（確認してませんが）
モバイルはDalvik VMとC,C++で開発するだけで十分大変なのでそれ以外の選択肢は無理してまで考えないということなのでしょうね。
インターフェイス部分だけObjective-CであとはCでということもあるようです。
JavaもJ2MEではリフレクションなしでベリファイも事前にするいった工夫もしてました。(今は知りませんが)。
Goはソースコードまでバイナリに含んでいたりするみたいですしね。（確認してませんが）
モバイルはDalvik VMとC,C++で開発するだけで十分大変なのでそれ以外の選択肢は無理してまで考えないということなのでしょうね。
5. Posted by hik 2010年06月15日 23:58
前言を翻すわけではないですが、ある特殊な状況ではまた別な言語が適しているのでは、と思うことがあります。
例えば、以前机上で考えたものを次に示します。
処理系は assembler あるいはそれに加えて linker ぐらいしかない、
c compiler もない、cpu も orginal 16 bit. というような状況の
場合、処理系はどうするか、ということを考えてみました。
16 bit なので memory は 64k byte まぁあっても その 4 倍程度
でしょうか...
tiny c みたいなものを取り敢えず、移植していくか、あるいは昔だと forth とか basic interpreter などがでてくるのかなどを考えて、調べてみました。
source をほどいて検討したわけではありませんが、PyMite がおもしろそう、と思いました。
http://code.google.com/p/python-on-a-chip/
例えば、以前机上で考えたものを次に示します。
処理系は assembler あるいはそれに加えて linker ぐらいしかない、
c compiler もない、cpu も orginal 16 bit. というような状況の
場合、処理系はどうするか、ということを考えてみました。
16 bit なので memory は 64k byte まぁあっても その 4 倍程度
でしょうか...
tiny c みたいなものを取り敢えず、移植していくか、あるいは昔だと forth とか basic interpreter などがでてくるのかなどを考えて、調べてみました。
source をほどいて検討したわけではありませんが、PyMite がおもしろそう、と思いました。
http://code.google.com/p/python-on-a-chip/
6. Posted by 若槻 2010年06月16日 09:28
> hik さん
ツールベンダーの視点から見ると、スケールがとてつもなく広がっているということは、ターゲットの絞り込みが重要になってくるということですね。言語にせよ、ツールにせよ、全ての scale をターゲットにするのは不可能なわけですから。
また、だんだんと「組み込み」という言葉が、scale 感を表す際にはあいまい過ぎてあまり意味を成さなくなってくるのかなとも思います。
弊社は一貫してハイエンドをターゲットとしたツールを提供させていただいています。16 bit MPU で assembler と linker しか無いようなターゲットは、おそらく JTAG デバッガも存在しないでしょうから、もうしわけありませんが私の興味の範疇からは少し外れてしまいますね（苦笑）
それはそうとして、PyMite 面白そうですね。
情報ありがとうございます。
ツールベンダーの視点から見ると、スケールがとてつもなく広がっているということは、ターゲットの絞り込みが重要になってくるということですね。言語にせよ、ツールにせよ、全ての scale をターゲットにするのは不可能なわけですから。
また、だんだんと「組み込み」という言葉が、scale 感を表す際にはあいまい過ぎてあまり意味を成さなくなってくるのかなとも思います。
弊社は一貫してハイエンドをターゲットとしたツールを提供させていただいています。16 bit MPU で assembler と linker しか無いようなターゲットは、おそらく JTAG デバッガも存在しないでしょうから、もうしわけありませんが私の興味の範疇からは少し外れてしまいますね（苦笑）
それはそうとして、PyMite 面白そうですね。
情報ありがとうございます。
7. Posted by 若槻 2010年06月16日 09:34
> h_sakurai さん
中身は全部 C/C++ というのは、Go でも可能そうですよね。
また、理想的には、リフレクションなどの動的な機能はコンパイルオプションなどで on/off できると良いですよね。
あと、確かに Android プラットフォームをプッシュしている Google 的には、Go をモバイルなどの組み込みに向けるメリットがあまりないというのもありますね。
中身は全部 C/C++ というのは、Go でも可能そうですよね。
また、理想的には、リフレクションなどの動的な機能はコンパイルオプションなどで on/off できると良いですよね。
あと、確かに Android プラットフォームをプッシュしている Google 的には、Go をモバイルなどの組み込みに向けるメリットがあまりないというのもありますね。
