Scalaを始めて早5年、今一度冷静にScalaと向き合ってみた

今年は2015年で、社会人になってプログラマとしてデビューしたのがディープインパクト*1がまだ現役だった2006年で早9年。そして自分がScalaという言語に出会ったのが2010年なので、なにげにキャリアの半分くらいをScalaを触って過ごしてるということになる(もちろん他の言語もやってるが)。

というわけでScalaを始めて5年ということで、今一度冷静にScalaと向き合ってみようというエントリでたいした内容ではありません。

(注:自分はたいしたScalaプログラマではありません)

はじまり

過去を掘り起こせば、Scala始めた宣言をしたのはこのエントリらしい。たぶんtwitterでも宣言してる気がするけど、2011年くらいまでの発言までしか遡れなかった。

このエントリの通り、Scalaを始めたのは現在糖質制限でお馴染みの@j5ik2oにそそのかされたからというのが一因です(そのやりとりのメールは紛失した)。手始めにコップ本を始めたわけですが、言語に対する感動と共にその言語仕様の膨大さに打ちのめされます。というわけで、もう少し易しい本があったのでそれから始めることにした。それが「ボクらのScala」。

ボクらのScala ~ 次世代Java徹底入門
ボクらのScala ~ 次世代Java徹底入門

この本はボリューム・難易度共にすごく読みやすくて、JavaからBetter Javaにステップアップするベースになったことは間違いです。これやってなかったらコップ本をうまく消化することができなかったと思う。

正直コップ本は紛れも無いScalaバイブルだと思うけど、あの内容てんこ盛り感で挫折してしまった人も一定数生み出してしまったんじゃないかという気がします。

所感:入門書じゃなくとも、コップ本に行くまでの踏み台教材に出会えるかというのが成功のカギじゃないかと

初のScala実戦投入

2011年にジョインしていたスタートアップでScalaを実戦投入した。まだScala2.9?が出たくらいで、LiftでAPIサーバを書いた。ビジネスロジックは良いけど、Controller層や永続化層もScalaでやるのは実質初めてだったので、色々なお作法とか癖に苦戦したし、Liftのソースを見ようにもimplicitが出てくると途端に追いづらくなるとか最初はかなり苦労した記憶がある。

そういやこの年の夏にはScala会議でLTスピーカーとして引きずり出された。業界的にも結構盛り上がり始めてて、Scala元年みたいな年だったと思う。とはいえ当時Scalaを実戦投入するのってそれなりにチャレンジングで、「トラブったり、メンテできなくなったらどうするの?」とかはよく言われたけど、そんなの枯れた技術であってもあるし結局は当事者のやる気次第だと思ってる。

所感:巻き込む以上は、ちゃんとメンバーをサポートしよう。そして教育の力を偉大。

Akka

2012年にサイバーエージェントにジョインしてからは、試験的な機能だったけどakka-actorとakka-kernelでサービスのNPCユーザーを制御する常駐botを書いた。この時まだakka-clusterとまだ無かったんじゃなかったかな?(うろ覚え)。実際にサービス本体に投入するには難しいけど、このケースみたいに本系統に副作用を起こしにくい性質のものであれば結構採用されてる感ある。

所感:スポットだとかなり入れやすい。あと管理画面とか。もちろん自己責任で。

MonadやScalaz

よく「モナドは象だ」とか言われますが、その説明は未だになかなか腑に落ちない。今となっては意図せずともMonadicなコードもそれなりに書いているし、活用もできてると思うけど理論をちゃんと説明できるかと言われれば難しいと言わざるを得ない・・・

プログラミングにおいては「理論もちゃんと理解しないと負け」みたいな固定観念があって、これはそれなりに正しいと思う。ただ、Monadに関しては理論をちゃんと理解するのは潔く諦めた。そればっかりで何も進まなくなるし、やるべきことはプログラムで価値を出すこと。理論が怪しくても、使いどころをわきまえて、有用であればそれでいいと開き直ってる

Scalazも最近は開き直りながら取捨択一をしていて、Validation\/とかはめちゃくちゃ有用なので使ってる。Aeromockでも使ってるが、もう一段階スマートに書きたい。

所感:無理は禁物。自分とその周りのメンバーのレベルにおいて、有用性を見いだせたものに関しては取り入れよう。

Scalaでの競技プログラミング

社内でISUCONっぽいのが3部門(インフラ・フロント・サーバサイド)で開かれたのでサーバサイド部門で出た。 どうせやるなら新進気鋭のakka-httpを使ってストレージはAerospikeでウェェイってやろうと目論んでたが、実際問題出たら完全に物量の勝負だったし、そもそもAerospikeにデータ移行してる暇とかまったくなかったし全然勝負にならなかった。肝心のakka-httpは細かいところがわからなくて、コード読んでばっかりになってしまった。玉砕である。

所感:競技プログラミングには基本向かないし、Scalaの新技術は麻薬。

トレードオフ

Scalaは好きな言語であるが、書いていてとても憂鬱に感じるときもある

黒魔術に苦戦することもあるし、GCによって殺されることもある。コンパイルが遅くて、切羽詰まった状況では精神を試される。eclipseやIntelliJが時に意味不明なエラーを吐いたりもする。

これらは全てトレードオフだと思うけど、ネガティブな面と引き換えに堅牢な型システムだったり、副作用の起こりにくい並列処理だったり、短いコードによる可読性やメンテナンス性を手に入れた(これはどう書くかにもよるが)。このような利点によって多くを解決できる見込みがあるのであれば、利用を躊躇わなくても良いと思ってる。ただし、そぐわないケースで無理して使うべき言語ではないと。

所感:デメリットから目を背けず、Scalaによって価値を出せるかを見極めよう。あくまで適材適所。

Scalaの今と今後

Scalaを始めた頃に比べるとだいぶ枯れつつあると思うし、Play Frameworkはもはや定番で、Akkaの利用も増えてきてるし、最近はSkinny Frameworkも盛り上がってる。Scala Matsuriが開催されれば、マークシティのセミナールームがあっという間に埋まるし、もはやマイナーな立場ではなくなった。何か困ったことがあっても、Scala界隈のモヒカンエバンジェリストが助けてくれることも多い。

このような状況を作り上げた方々には本当に頭が下がります。自分も微力ながらScalaに還元していきます。

さて、Scalaはこの先どうなっていくのか?というのを考えると、それなりに不安もあると考えている。

Javaが8になってそれなりに辛さが解消されたし、Better Javaっていう位置付けだけではScalaを採用されにくくなっていく気がする。他の言語との比較で言えば、GoLangの勢いはやっぱりすごい。言語仕様的にはまだまだ辛い面も多いけど、コンパイルは速くてScalaとは対局にある。

Scalaはこれからも進化していくけど、言語仕様的にはもう十分すぎるくらいに十分すぎるし、利用する側もいかにストレス無く良いコードを書くってことに拘っていかなくちゃいけないと思っている。それなりに長いことやってるので、どういうコードによってコンパイルが遅くなるのかもだいたい把握してる。とはいえ出来る限り表現力は落としたくないので、中長期的には新しいコンパイラであるdottyには期待しかない。

所感:これからもコンパイラと仲良くしつつ、Scalaを使っていきましょう。

*1:JRA史上6頭目のクラシック三冠馬