シェア
はてブ
1993年の誕生以来、根強い人気を誇るRuby。近年は、Rubyの思想をベースとして開発されたElixirへの注目が少しずつ高まっており、海外製のサービスでは、SlackやSpotifyなどが同言語で作られていることも有名です。しかし日本では事例が少なく情報が不足しており、国内でどの程度浸透していくのかについて未知数の言語でもあります。
Elixirが拡まると想定して今から勉強しておくべきか、圧倒的なサービス事例のあるRubyを追求するべきか──。バックエンド領域に携わるエンジニアが今後学ぶべき言語とは何なのか？
本イベントでは、各言語の有識者である松田さん、森さん、中尾さん、齋藤さんの4名をお招きし、RubyとElixirについてそれぞれが持つ特徴や2つの言語が共存する方法について語っていただきました。
RubyとElixirの使い分けについても触れているので、技術選定を行っている方もぜひご一読ください！
パネリスト
松田明さん(@a_matsuda)
日本人として唯一RubyおよびRuby on Railsの両プロジェクトのコミッターを務める、オープンソース・プログラマー。kaminari、active_decorator、action_argsなど、数多くのOSS作品を手がけるライブラリ作家。地域Rubyユーザーグループ「Asakusa.rb」の主催。国際カンファレンス「RubyKaigi」のチーフオーガナイザー。最後のRubyHero。
森正和さん(@piacere_ex)
39年前からプログラマ。書ける言語は158言語で、Elixirを「至高の言語」とした2017年以降、実務/趣味/OSSはほぼElixir製。大学で独自OS/コンパイラを開発後、大手SIerでPMと事業部長を経て、国民の約1/4が使う超大規模基盤開発の性能統括中にElixirと出会う。現在、(株)DigiDockConsultingのファウンダー兼CTOとして、VR・AR/D2C/DXによる事業指南を行いつつ、他3社のIT企業経営と、3社の技術顧問を兼任。国際カンファレンス「ElixirConfJP」および「fukuoka.ex」の創設者。「Elixir|>College」「DD.Academy」「AIジョブカレ」の3校と、北九州市立大学、北九州工業高等専門学校でプログラミングとElixirを教えている。
中尾瑛佑さん(@YOSUKENAKAO)
グローバルでも通用するエンジニアの育成を掲げ、自らも講師として、エンジニア育成の教材・カリキュラムの開発・講義を通して2014年からの7年間で延べ5000名以上、4歳から社会人まで幅広い年齢層に教育を行う。これからの日本を発展させる為には、オブジェクト指向から関数型へのパラダイムシフトに加え、従来型のマネジメントからスクラムでのマネジメントへのパラダイムシフトが重要と考えている。マネジメントと新しい言語の２つを軸に、VUCA時代と呼ばれる先行き不透明な時代に、PMF（プロダクト・マーケット・フィット）に到達するエンジニアの育成を実現する研修を提供。
齋藤和也さん(@mokichi_s12m)
福岡県出身、九州工業大学情報工学部卒。フリーランスとして2年ほど、Webサービスやスマートフォンアプリの受託開発を中心に活動。アジャイル開発を実践し、保守性・拡張性の高い設計を得意とする。独立前は研究用ソフトウェアの開発に従事しており、機械学習や自然言語処理といった分野にも明るい。2015年1月、株式会社スマートアルゴリズムを設立、代表取締役に就任。2016年10月より株式会社VookのCTOも兼任し、その他複数社で技術顧問としても活動中。
モデレーター :佐藤将高(ファインディ株式会社) (@ma3tk)
東京大学情報理工学系研究科創造情報学専攻卒業後、グリーに入社し、フルスタックエンジニアとして勤務する。2016年6月にファインディ立上げに伴い取締役CTO就任。
各言語の有識者が語る、Ruby／Elixirとの出会い
──まず、「RubyとElixirで開発を始めたきっかけ」というテーマで、皆さんがそれぞれの言語で開発を始められたきっかけをお聞かせいただけますか？
齋藤さん： 私はどちらの言語も触っているのですが、Rubyを触り始めたきっかけは仕事です。会社勤めをしていた時はWeb系の会社ではなかったのでCやC++が多かったのですが、ちょっとしたクローラーやデータ処理をする際にRubyを単体で使っていました。独立してWebに転向したことをきっかけにRuby on Railsの存在を知って、当時はVersion4とかで仕様の移り変わりもなくなってきて、安定しているようだったので使い始めたという流れです。
Elixirについては存在を知ったのが2016年くらい。Ruby on Railsで開発している際に開発環境が重い、メモリを消費するなどの課題が生まれてしまい、解決策を探していたらQiitaに「次に来る大物Web言語」という内容の翻訳記事が上がっていて、その記事でElixirを知りました。当時はScalaが使われ始めるなど関数型が流行っていた時期で、Rubyに似ていて関数型の言語って面白そうだなと思い、2018年くらいから実務でElixirを使い始めて今に至ります。
──どちらの言語も仕事がきっかけだったのですね。続いて松田さんお願いします。
松田さん： 私はもともとフリーランスとして受託開発をしていて、いわゆる“職業プログラマー”でした。Ruby on Railsがリリースされた直後に「Ruby on Railsを仕事でやってみよう」という熱意のある企業と出会ったことがきっかけで、それ以来Rubyの仕事ばかりしています。
本当に初期の頃は、Ruby on Railsは今ほどソフトウェアとしてまともに動いていなかったので、ある程度自分たちで手を入れながら使っていくしかなかったんです。自分たちが気持ちよく使っていくために、RubyやRuby on Railsにパッチを書いたり、ライブラリを書いたり、足りないものは全部自分たちで作っていました。あとは自分で本を執筆してみたり、コミュニティを立ち上げてみたり、国際カンファレンスの運営をしてみたり……。単に「Rubyを使った」というより、「Rubyを使っていく土壌みたいなものを俺達が耕した」という感覚です。それができるのがOSSコミュニティの醍醐味なんですよね。
Elixirについては個人的に触ったことがあるものの、仕事ではまだ使ったことがないので、今日は皆さんの話を拝聴し、勉強させて頂きます。
──ありがとうございます。中尾さんは、松田さんとは反対にRubyを使われた経験がないそうですが、Elixirとの出会いはどのようなものだったのでしょう？
中尾さん： 昔話になってしまうのですが、高校生にC言語を教えに行っていた時期があったんです。その後Unityが主流になってきたため、C♯なども教えていたのですが、「高校生たちをどのレベルまで引き上げて行ったらいいのか？」という疑問が湧いてきてしまい。高校生たちよりも上の世代の現状を見れば疑問が解消されると考えて、新入社員研修会を開催している団体にJavaの講師として応募しました。
そこでカリキュラムを見ると、私が新入社員の時と変わらないことを教えていたんです。20年前とやっていることが同じでは良くないですし、「今から教えるものとして、新しくてこれから流行っていく関数型の言語ってなんだろう？」と探している中でErlangに出会いました。しかしながらErlangは、高校生に教えるには少しハードルが高いと感じたため、もう少し分かりやすい言語がないか探し、Erlang VM上で動くものがあるというので教えてもらったのがElixirでした。
──ありがとうございます。森さんはいかがですか？
森さん： 今回のイベントではElixirについて話す側の人間として呼ばれていると思うのですが、私自身はJavaやC++など、さまざまな言語を触ってきています。もちろん、RubyとRuby on Railsも使ったことがあり、Ruby on Railsが一番最初にリリースされたくらいから触り始めて、仕事で使い出したのは2007年以降くらい。そこから2017年ぐらいまで案件で使っていました。
Elixirとの出会いは2015年くらいです。当時、国民の4分の1ほどの人数が使用する大規模なシステム開発をしていたのですが、GWに全部出勤しなきゃいけない、夜間休日のコールで深夜に叩き起こされる……という経験をしたことがあって。そのことをきっかけに、ダウンしない言語を探してElixirに出会いました。
似ている言語でありながら異なる特性。それぞれが抱える魅力と課題
──続いては「開発現場で使ってみて感じたRubyとElixirの魅力と課題」と題して、開発現場で使って感じたそれぞれの魅力、課題をお話しいただければと思います。こちらは松田さんいかがでしょう？
松田さん： 開発現場で使ってみて感じたことという質問からは少しずれてしまうかもしれないのですが、Rubyの最大の魅力って、“楽しい”ということなんですね。そもそも作者であるMatzが、Ruby言語を設計するにあたって何にフォーカスしていたかっていうと、“楽しい言語を作る”ということ。プログラマーがコードを書いていて、ハッピーになる“デベロッパーハピネス”を指標として作っているんですね。
それまでのプログラミング言語って、コンピューターリソースを効率よく使うために、コンピューターに人間が寄り添うというスタイルだったんです。マシン語のようなものを頭の中でイメージして、コンパイルされた後のバイトコードに思いを馳せながらコードを書く。コンピューターが速く動くように人間が頑張るという形です。一方、Rubyは言語設計において、“人間の言葉になるべく近いもの”というコアな思想があって、速く動くように頑張るのはRubyのほう、というスタイルなんです。つまり、Rubyの登場はパラダイムが逆転した瞬間で、「デベロッパーハピネスにフォーカスしています」と明言した初めての言語でもあります。
Rubyがリリースされた当時は、コンピューターのスペックも低く、多くの人がインターネットに触れない状態でしたが、その時からMatzは「コンピューターのリソースは今後余っていく」と言っていました。そういった先見の明があったという点についても、Rubyの大きな魅力だと思います。
──ありがとうございます。齋藤さんはいかがでしょう？
齋藤さん： 他のスクリプト言語でも言えることなのですが、Rubyはメモリ管理も気にせず使えるし、型も書かなくていいし、手軽に使えるところがいいなと。小中規模の開発において、手軽に楽しくプログラミングができるというのはとても魅力的だと思っています。ただ、RubyやRuby on Railsで大きめのプロジェクト開発をやろうとした時に、並列処理の部分が課題だと感じるところがありますね。
その反面Elixirは並列処理に強い。関数型言語でオブジェクト指向の要素が一切なく、イミュータブルなデータを扱うことになるので、「クラスでメソッドの実行をしていて内部状態がどう変わったかわからなくなる」といった現象が発生しにくいのもポイントです。あとはパイプライン演算子を使うと、データがパイプラインを流れていく感じが面白いと感じたのを強く覚えています。課題としては、利用者が少なく情報が少ないというところですね。
──お二人ともRubyについて“楽しい”とお話しされているのが印象的です。Elixirについても深掘りしていきたいのですが、森さんいかがでしょうか？
森さん： まず齋藤さんがお話しされていた情報が少ないという点について補足させてください（笑）。Elixirの情報が少ないのは事実ですが、コミュニティ活動を頑張っていて、実は毎月20件も国内で勉強会が開催されています。これはきっとどのコミュニティよりも多い部類になるんじゃないかなと。あとはelixir.JPのSlackで聞けば数分で回答があるので、疑問点をすぐ解消できるのは、Elixirのいいところだと思います。
──魅力という点ではいかがですか？
森さん： なんと言っても高い安定性があるという点は魅力ですね。安定性については、“ダウン頻度の少なさ”、“メモリ利用の健全さ”、“正常系／異常系が書きやすい”という3つがポイントなのだと考えています。
ダウン頻度の少なさについてはメモリの利用と密接に関係があるのですが、Elixirなら数年単位でダウンしないケースも珍しくありません。メモリ利用の健全さに関しては、イミュータブルが影響しています。イミュータブルについて軽く解説すると、変数を一度定義すると変更不可で、いつでも値が参照できるということが保証されるということです。ちなみにイミュータブルであることは、メモリ利用の健全さだけに留まらず、Elixirの並行並列処理にも有利に働いています。
もう一つはGCをせずにメモリを解放できる、返却できるというところも魅力です。Elixirはオブジェクト指向言語でいう、クラスのインスタンスを立ち上げるかのような感覚でプロセスを立ち上げて、プロセスをマルチで動かしてプログラムを組みます。もし、メモリが何か悪さをしたり、例外状態みたいになったりすると、プロセスを落としてクリアします。そのため、プロセスが落ちた時点でメモリがきれいになる。不整合な状態でメモリをつかみっぱなしとか、メモリが延々とリークして増えていくといった事態を回避するためのメカニズムが標準で入っているので、メモリを健全に使えるわけです。
正常系／異常系の書きやすさについては、関数パターンマッチで書いていくと、「これが正常系で、そこに書いてないものが異常系」というのが一目でわかるんです。コード上で正常系／異常系をきれいに書ける言語って、私はあまり出会ったことがなく、最初は驚きました。
あと、私はElixirを関数型としては見ていません。関数型という属性よりも、データ処理に強い言語だと思っています。データ処理や分散並行並列を書くための言語という立ち位置で捉えているため、関数型である必要もないかなと。
その属性がどこに活かされるのかというと、例えばマシンラーニングやAIを開発するときの前処理やデータサイエンスを書くことに向いています。また、フロントエンドのAPIをバックエンド側でまとめて、PCやアプリでAPIを使い分けずに済むようにできる「BFF（Backends For Frontends）」という作り方があるんですが、こういうデータをまとめたり、分割したりする処理に強いのもElixirの特徴です。
高速に並行処理が作れるため、大量アクセスを捌くAPIとかサーバーも作りやすく、いつでもマイクロサービス化できる機能が標準で備わっている。この辺りはやはり強いところだと思っていて、こういうのがありながらも、WebやWeb+DBはRuby on Railsとほぼ同じ感覚で作れて、GemやBundler、routerなどに相当するものも大体揃っています。
──ありがとうございます。中尾さんにも語っていただければと思うのですが、いかがですか？
中尾さん： 色々な言語を触ってきて、今Elixirにどっぷりはまっている理由としては、やはり楽しいということですね。それはどの言語でも同じなのですが、Elixirについてはまた別の楽しさがあるんです。
一つは、先ほど森さんがおっしゃっていたように、データ変換に強いというところ。データ変換をする際、パターンマッチを使ってサクサク書いていけるのですが、それがパズルを解いてるような楽しさがあるんです。
うまく設計ができたとか、オブジェクトを綺麗にできたなど、ある程度“塊をきれいに作れた”時って、楽しさを感じられると思うのですが、Elixirの場合は他の言語では楽しさに到達するまでの前処理ですら楽しめる。そこはとても魅力だと思っています。
2つの言語が共存していく方法は「部分的な使用」
──Rubyだと楽しくプログラミングができて、一方のElixirでは、通常のプログラミング言語が少し苦労するような領域すら楽しんで作れるという。どちらの言語も楽しさ、良さがあるのだなと、非常に勉強になりました。続いては「Ruby・Elixirの共存、展望」というテーマでお話をお伺いしていきます。まずは中尾さんからお話いただけますか？
中尾さん： Rubyについてあまり知らないので、薄い回答になってしまうかもしれないのですが……。 僕が実際に体験して感じたことでお話しすると、まず前提として今年の新入社員研修では、C言語、Java、Elixirと3つの言語について、それぞれ別の企業で教えていたんですね。そこで驚いたのが、C言語もしくはJavaを2ヶ月間学んだ人と、Elixirを1ヶ月学んだ人のレベルを比較した時に、Elixirで学んだ人の方がトータルで2段階ほど高い技術レベルに到達していたんです。
その結果だけを見ると、Elixirから学習を始めるのがいいのではないかと思ってしまうのですが、今はオブジェクト指向の言語で開発されているものがたくさんあるので、そちらの学習もしないといけない。じゃあどうするかというと、Elixirで関数型やオブジェクト指向前のところを一通り学び、その後にRubyでオブジェクト指向を学ぶという順番がベストなのではないかと。
個人的にはオブジェクト指向言語は非常に学習コストが高いですが、オブジェクト指向言語の中でもRubyは学習コストが低い言語だと考えているので、「①Elixir ②Ruby」という順番で学習すれば、コストが抑えられるとともに、両方のパラダイムを学べる。そういう共存の仕方もあるのかなと思っています。
──言語を学ぶ上で共存できるというのは面白い視点ですね。森さんは、ElixirとRubyの共存といったテーマではどうお考えですか？
森さん： Ruby on Railsは調達容易性が高く、プロジェクトを開始したとして、すぐに人を集められるという点が強いですよね。あとは機能数の多い領域とライブラリーの豊富さはElixirにはないところです。そのため、利用者数や規模が限定的であれば、活躍の場はこれからもずっと続くのではないでしょうか。
ただ、スタートアップで資金調達が難しい場合にはElixirの方が適しているような気がします。例えばRuby on Railsで開発して、サービスがグロースしてから性能問題が発生したという時に、スタートアップだと再開発の予算がないことが多いので、後々苦しむかもしれません。そのため、学習する時間を確保するのが難しい企業や、スケーラビリティが近々に求められる事業などについては、Elixirが活躍するのではないかと考えています。スタートアップや新規事業、リーンやスクラムといったアジャイルの文脈に持って行きたいとか、グロースと品質を両立したいとかっていう時には、Elixirの安定性が適しているのかなと。
また、エッジコンピューティングや5Gではクラウドを使えないことも多いのですが、Elixirなら“クラウドもどき”のようなことができます。クラウドを使えない開発におけるElixirは、別世界の強さですね。
──なるほど。齋藤さんはいかがですか？
齋藤さん： 共存するという観点でいうと、Ruby on Railsで作ったあと、一部をElixirで実装するというのも有効なのかなと考えています。
Ruby on Railsはフロントも絡んだライブラリが多い印象があるのですが、Elixirには私が知る限りそういったものはあまりありません。そのため、フロントなども含めて全てRuby on Railsで作って性能問題にぶち当たった時に、APIだけElixirやPhoenixで実装するというのも一つの方法です。
ElixirのライブラリでO/Rマッパーみたいなものがあるので、既存データやデータ構造とかを活かしつつ、その部分だけ切り出してElixirで実装するというのが、私が考える共存方法ですね。
──Ruby on RailsとかだとActiveRecordが強いイメージがあるのですが、ElixirにもO/Rマッパーで有名なものがあるのでしょうか？
齋藤さん： Phoenixでプロジェクトを作るとデフォルトで入ってくるEctoというライブラリがあるのですが、それがデファクトスタンダートなのかなと。ActiveRecordと違ってリポジトリパターンなので使い勝手は異なりますが、SQLのように書けるんです。SQLを書いたり読んだりする人であれば、特に問題なく使えるのではないかと思います。
──ありがとうございます。最後に松田さんからRubyの使い方についてお伺いできればと思います。
松田さん： 森さんのお話と少し重複するのですが、Ruby on Railsでビジネスを始めてスケールしたところで全部捨ててElixirでセカンドシステムを作り直す、というのはだいたい悪手です。「from Ruby to ◯◯」みたいな話は昔からあって、例えば有名なRuby on Rails企業にTwitter社があります。Twitterは、最初はRuby on Railsモノリスとして作り初めているんです。Ruby on Railsの初期から使っていて、ユーザーが数億人ほどの規模になってから初めてバックエンドのデータストレージをScalaで分散させたと。マイクロサービス的なアプローチを、数億人規模になってやっと始めたわけです。
そこで彼らが実証してくれた事っていうのは、「Rubyは遅い」ということではなく「Rubyは数億ユーザーぐらいまでは耐えられる」という、先行事例を示してくれたのだと僕は思っています。
おそらく多くのアプリはTwitterほどは大きくならないため、規模について心配する必要がないんです。Ruby on Railsで作れば数億ユーザーまでは耐えられるため、実際にそれ以上の規模になった時に考えればいいと思います。今の時代のRuby on Railsであれば、AWSに多めにお金を払ってサーバーの台数を増やせば、水平方向にいくらでもスケールするように作れます。一般的なWebサービスであれば、Ruby on Railsで事足りるはずです。
Webの文脈でRuby on RailsとElixirが絡むとしたら、いわゆるマイクロサービスの話が出てくるのかなと。その場合は、先ほど齋藤さんがおっしゃっていたように、組織やアプリケーションが複雑化してきた時の対応として、部分的にElixirを使うのが良さそうですね。
結論としてリスナーの皆さんにお伝えしたいことは、「明日からRuby on Railsはやめて全部Phoenixに乗り換えるぞ」といったやり方ではなく、最初は部分的に、たとえばデータ処理のバッチからElixirを導入していって手触りを試してみるというのがおすすめです。僕も機会があったらやってみたいです。
前編では、各言語の特徴やメリット・デメリット、2つの言語が共存していく方法について語っていただきました。後編では、イベント当日に行われたQ&Aの様子をお届けします。Rubyコミッターの裏話や、Elixirが誕生したきっかけについても触れているので、ぜひチェックしてみてくださいね！
後編は明日9月8日(水)公開予定！
