ここ2年くらい、仕事では大体 Go を書いている。jmuk さんが
Go言語は、なんというか「ちょうどいい」言語だな、と思っている。異論は認める。
と書いていたけれど、私はやっぱり Scala や Kotlin あたりが好きで、これは変わらなそう。
例えばコレクションを map しているのをみると、私は「なるほど、ここではコレクションの要素数は変わらないんですね」と思う。filter だったら「コレクションの要素数は変わるけど、個々の要素は変わらないのか」ということを、あるいは Result を map していたら「ここではエラーのほうは触らないのね」ということを読みとっている。
こういう意図が、素朴な for ループと、if err != nil だと読みきれなくて、いや真面目に字面を追っていけばわかるんだけど、私が「map するか」と思いながら for ループを書いて、その for ループを誰かが読んで「これは map だね」と理解していることを考えると、それソースコードに map って書けたほうがいいんじゃない、と思ってしまう。
同様に、このコレクションに要素は追加されませんよとか、この変数はここから先では再代入されませんよとか、あの参照は nil になるけど、この参照は nil にはなりませんよ、みたいな「意図」がプログラミングには色々とあって、私はこれをプログラミング言語の語彙で、immutable なコレクションや、val と var の違い、Option[T] なんかにエンコードしている。意図に反することが起きたら、コンパイラにはエラーにしてほしい。
こういう関係をプログラミング言語に求める私にとって、Go はちょっと違う。「この参照は int* なので int しか指しませんよ」をコンパイラに教えるのと「この参照は nil になりませんよ」のを教えることの間にそこまで差はないので、どこで立ち止まるのか、立ち止まることで何が得られるのか、というところについて Go が好きな人々とは見解の相違があるんだろうと思う。
自分の語彙にない表現
一方で、私の知っているプログラミング言語の語彙は、過去の経験からくるバラバラな機能のセットでしかなくて、それが Scala や Kotlin のところで止まっていることには一抹の不安もある。
Idris にある依存型とか、Cats や Scalaz が提供する色々とか、Rust のオーナーシップとか、存在を知っているけど使い道がわかっていないものは色々あって、どうしたものかなあと思う。Idris なら Seven More Languages in Seven Weeks に出てくるので、そこだけでも読むといいのかもしれない。
語彙を増やすことの反対にある、Go の人々の素朴さへの渇望はあまり理解できていない。多機能な言語の、その機能を使いまくって大変なことになっているコードをさわる機会があるといいのかもしれないけれど、正直いって体験したくはないなあ。