F# に思うこと

F# http://journal.mycom.co.jp/articles/2009/09/16/vs2010/001.html

OCaml に似た関数型言語。.NET フレームワーク上で動作する。つーか誰が作ってんだろ。
.NET 上、というところが魅力でもあり、ガッカリなところでもあるという気がした。

性能/電力：
性能/電力が重視されるこの時代に .NET や Java 等の VM を使ったソリューションは適合するのだろうか。.NET はともかく Java の VM の性能はかなり高くなっているので、JIT コンパイルのコストはあるとはいえ、ピーク性能時の性能/電力には大差はない（いや、あるだろうけど理想論で考えよう）。JITコンパイルコストも、低負荷時の低電圧動作時にあらかじめコンパイルとかすれば良さそうだ。Java だと VM 自体を起動するコストは馬鹿にならないので、複数のVM間でリソースを共有できる仕組みは必要だろう。JRuby は起動が遅くてがっかりする。

結局のところ、複数のアプリケーション間のリソースの共有がポイントな気がする。VM自体もリソースなので、VMのコストの低減・共有は重要そうだ。でもなあ、Android とか見てると、VM はやっぱ遅い（性能／電力が悪い）気もするな。まあ、用途によるが。

リソース共有：
Go (golang.org) とかを見ていると、VM のコストがない世界というのも魅力的に思える。VM がないと言っても、リソースの共有や基盤の共通化はした世界だ。例えば、GC、リフレクション、ライブラリ等のランタイムは共有する。Objective-C が近いかもしれない。ランタイムと言語は分離する。さらに上に VMが乗ってもかまわないし、スクリプト言語が乗ってもかまわない。

強力な（モダンな）ランタイムを持った高効率な言語があり得るのなら(Goとか)、こういう世界もありかもしれない。VMを捨てる以上、sandbox 的機能はあきらめるか、言語で実現しないといけない。いや、iPhone とかを見るに、言語というよりOS, APIレベルで実現するという感じか。でも、言語が Go だけじゃダメだけど。


まあ、ようするに、F# は言語として魅力的だけど、ランタイムとかの実装は Go みたいなのが良いなあと思った。Go のランタイム・リフレクションは OO, generic, exception が弱そうだけど。