[翻訳] Elixir - 次に来る大物Web言語 #Elixir

Lau Taarnskovさんの2015年4月19日付のブログ記事、Elixir - The next big language for the webの翻訳です。
ElixirはErlangのVM上で走る、Rubyにちょっと似た(というのも作者(José Valim)がRuby on Railsのcoreチームメンバーなので)関数型言語です。
2012年に登場していてQiitaでもAdvent Calendarなどが既にあるようですがまだあまり知られていないですね。ElixirとPhoenix Frameworkを組み合わせたものがマイクロ秒のオーダーで反応が帰る爆速だそう(ホントかな～)で興味を持ちました。
しかしほんの10年前ぐらいの話がもう遥かな昔話に聞こえますね…。

(追記：実際にプログラムを書いてみました →　Elixirで試しに何か書いてみる(その1)
Elixirで試しに何か書いてみる(その2)
Elixirで試しに何か書いてみる(その3) - Elixirのアプリケーション
 Elixirで試しに何か書いてみる(その4) - Taskを使って簡単にする)

この記事で私がなぜElixirをWeb開発の世界に大きなインパクトを与えるであろう、と考えるかを述べます。

無名からデフォルトの選択肢へ(From obscurity to the default choice)

まず他の、ほとんど無名だったある言語がとてもよく知られたものになったという短い話から始めましょうか。

2003年に私はRubyを使い始めました。大学のクラスメートがRuby用のWebフレームワークをリリースしようとしていた頃です。それを使うとJavaで書くよりはるかに少ない行数のコードでソフトを書けました。Rubyとこの新しいフレームワークの組み合わせは私がそれまで使っていた…PHP…に比べすごくよいものに感じられました。

それで、あるクライアントがeコマースサイトを再構築するとき私は彼らにその書き換えにはRubyと今ではRailsと呼ばれているこの新しいフレームワークを使うことを納得させました。これ以来私はずっと仕事ではRubyでプログラムしています。

その当時にRailsのダウンロード数のグラフを見れば明らかにRailsがRubyのダウンロード数を引っ張っていたことがわかったでしょう。RailsはRubyを無名の言語からその後数年のうちに非プログラマーの間でさえこのWebフレームワークの名前が語られるほど有名にしました。

Railsがいかに早く、ほんの一握りの人たちが使っていたものから「ITフレームワーク」に、Webベースのソフトウェアを必要とするスタートアップのデフォルトの選択肢になっていったかを見るのは非常に興味深いことでした。そのスタートアップのうちのいくつかは今では株式市場で何十億ドルもの時価総額になっています。

そのうちのひとつがTwitterです。2009年にTwitterはユーザー数とトラフィックの驚異的な増加を経験していました。彼らはインフラのコア部分をRubyからScalaに変更することを決意しました。Scalaの並行処理手法によりTwitterはより簡単にシステムを拡張できるようになりました。

Erlang

関数型言語でかつ大量の並行処理を更に長年行ってきた言語がもうひとつあります。Erlangです。ErlangはEricssonで1980年代に作られ電話用アプリケーションのより良い開発を可能にしました。

もしあなたが4Gのデータを電話の上で使っているのならおそらくそのデータはEricssonの機器を通ってやってきています。その機器ではErlangが走っています。今までに電話事業者が誰の通話も切断することなくどうやってソフトウェアを更新しているか考えてみたことがありますか？Erlangは電話交換機システムの常時稼働とホットスワッピング:ソフトが走っている状態を維持しつつ更新する、を可能にしました。

Whatsapp¹は何億人ものユーザーを抱えています。他の大半のプラットフォームでは1万以上の同時コネクションを1台のマシンで処理するのはチャレンジングだと見られていますが、Whatsappは1サーバーあたり2百万の同時コネクションをこなしています。2百万コネクションをErlangが走る1台のサーバーで。

Erlangはゲームサーバーとしても人気があります。何百万ものユーザーがマルチプレイヤーゲーム、例えばCall of DutyやGame of WarをErlangで動くゲームサーバーインフラでプレイしています。

Erlangのプラットフォームは信頼性の高いスケーラブルなインターネットアプリケーションを運用するのに多くの優位性を持っています。実績は折り紙つきで何十年も使われてきています。でもじゃあどうしてWeb開発の選択肢にあんまり入ってこないのでしょうか。

私が考えるにその原因のひとつはErlangを使って新しいWebサイトを立ち上げて運用するのはそれほど簡単ではないからです。Erlangは覚えるのがとても大変だからと思いま……そうは思いませんが、人は往々にして抵抗感の少ない道を選ぶものです。もしC、Java、JavaScript、PHP、Ruby、Perlなどを見慣れていたならErlangはちょっと変な文法に見えます²。

また、パッケージマネジメントやビルドツール、メタプログラミング、Unicodeの扱い³、そしてWebフレームワークもRubyに比べると一筋縄では行かないのです。

Elixir

しかしこれらの領域は全てElixirで対処されています。Elixirの作者 José Valimは「Erlangで経験したことはみんな気に入ったけど、見つけられなかったものがあるってことが嫌なんだよね」⁴と言っています。Elixirは独自のパッケージマネジメントシステム、マクロ、そして使いやすいビルドツールとUnicode対応機能を持っています。

ElixirはErlangのVM上で動作する言語です。ですからこなれた、数々の戦歴によって保証されたシステムの全ての有益性を持っていますし、既存のErlangのライブラリをパフォーマンスを損なうことなく使えます。さらにElixirにはよいものがあれこれ追加されています。例えばパイプ演算子(|>)もそうです。

ErlangとElixirの違いは文法だけではありません。でも文法は決め手になります。特にRubyのプログラマーにとってはElixirの文法は馴染みやすいでしょう。

不変性と関数型プログラミング(Immutability and functional programming)

Elixirは不変性を持った関数型プログラミング言語です。

しばらく不変性データを使って作業してみて私は「これはすごく役に立つ」とわかりました。シングルスレッドのプログラムでも変更可能性はプログラムがどう実行されるかについて不確定さをもたらします。私には変更可能性がなくてもなんともありませんでした。関数型プログラミングと不変性は物事をクリアにしコード解析を容易にします。

並行処理 (Concurrency)

Elixirのもうひとつの強力な機能は「並行処理」です。並行処理はいくつかの理由から単なる流行りではなく今後も定着するものです。端的にいうと: ハードウェアの傾向としてより多数のCPUコアを持つようになってきているからです。CPUベンダーは以前と同じ速度では単体コアの性能を上げることはしなくなりました。代わりにより多数のコアをCPUに入れてきています。そもそも世界は同時並行的に動いているので、あなたのシングルスレッドプログラムが重いからってユーザーや他のサービスが反応を不必要に待ってくれると期待してはいけません。

ErlangやElixirで並行処理を行うやり方を他の言語の場合と比較すると、ちょうどgitとsubversionでブランチ周りの作業をするときの違いのようなものがあります。Subversionではとても複雑で…私はやったことがありません。Gitだと簡単なのでしょっちゅうやっていました。

Elixirでは新しいプロセスの生成は非常に簡単でパフォーマンスも高いです。ですから必要になった場合にはプロセスを使うのが素直な解でしょう。これはプラットフォームに統合された機能の一部であり別のライブラリを必要としません。Erlang/Elixirの「プロセス」はネイティブプロセスではないことには留意してください。プロセスはもっと軽量でErlangの仮想マシンBEAMでスケジュールされています。

Webフレームワーク

今のところPhoenixがElixirでもっとも人気のあるWebフレームワークです。Elixirの作者はRailsのコアメンバーで、Phoenixの作者もまたRailsで作業していたという背景があります。単純にRailsをElixirで書きなおして、という要望はない一方で、簡単に使い始められるという点においてRailsはある程度の最低基準を満たしているのでPhoenixもそこそこ簡単に始められるようになっています。

Phoenixのもっともわくわくする新機能のひとつに、クライアント側のJavaScriptとクラスタ内のいずれかのサーバー上のElixirのチャネルを通じてのリアルタイム処理があります。あるWebサイトへの各個のビジターが、専用のプロセスをサーバー上に持ち、専用のリアルタイム接続を行うのです。これは現状の伝統的なWebフレームワークにはない可能性を開きます。

ところで、反応時間が1ミリ秒以下のため、Webサーバーのログ上にμs(マイクロ秒)の表示が出るのを見るのはすごくいいですね;)。効率と速さはエンドユーザー体験にとても大切ですし、ひいてはサーバーのエネルギー消費と運用費の節約にもなります。

プログラマーの幸せと美しいコード (Programmer happiness and beautiful code)

Rubyより高速な言語はいくらでもありますが、例えばRubyをJavaの代わりに使うべき十分な理由があります。Rubyは使いやすく、簡明なコードを相対的に早く書けるのです⁵。Javaのコードは多分より速く動作するでしょうが、多くの場合、Javaのコードは楽しくないし早くも書けないし、メンテナンスも簡単ではないのです。そのためにより強力なサーバーを買って欲しいという主張のためだけなら、意味のあるトレードオフとなることもあるでしょう。でもそのような選択をしなくてもよかったとしたら…？

Elixirなら私は高速開発の楽しさをErlang VMのもたらすパフォーマンスや信頼性、並行処理のために手放さなくてもよさそうです。ElixirはErlangの全ての利点、例えばパフォーマンスや信頼性などをRubyでの開発時のメリットをあきらめることなく使えるようにします。

既視感 (Déjà vu)

ちょうど12年前にRubyで感じたのと同じように私はこの新プラットフォームが他のソリューションより格段に優れたものだと感じています。これが単なる勘ではありません。それを支持する合理的な論拠がいくつかあります。もう一つ、同様なのはDave Thomas⁶もElixirについてワクワクしていてこの言語に関する本を書いたのです。

まるで全てがElixirが次のWeb開発の大物になるためにお膳立てされているようです。過去10年間はRubyとPythonがWebのための人気のある選択肢でした。私は数年のうちにそれらに代わってElixirが新しいWebプロジェクトにおいて魅力的な選択肢になるかもしれない、と考えています。

Whatsappはスマートフォン向けのリアルタイムメッセージングサービス。2014年にfacebookに買収された。 ↩
もし「第5世代コンピュータ」の頃にPrologをいじっていた人が見たら「昔、どこかで会いませんでしたっけ？」的な印象を持つかもしれません。Prolog+ML-あれこれ+OTP = Erlangかな。 ↩
Version 17からデフォルトエンコーディングがUTF-8になったのでかなり改善されています。周辺ライブラリもそのうち対応するでしょう。 ↩
原文は“I liked everything I saw in Erlang, but I hated the things that I didn’t see”. それでElixirにはプロジェクト管理ツールmixやレポジトリhexを早い段階から追加したということでしょう。 ↩
この記事の筆者はガチのRailsプログラマーなんでこのあたりの記述は大目に見てあげてください(笑)。 ↩
"達人プログラマー"や"プログラミングRuby"などのRuby関係の本を多数書いている人。 ↩