00:08
こんにちは、OSSのレキシラジオです。このポッドキャストでは、エンジニアであり、最近イチゴ狩りに行きたいhentekoが、毎週一つのOSSプロジェクトを取り上げて、そのプロジェクトにまつわる歴史を紹介していく番組です。
実はですね、次男がイチゴ大好きなんですけど、イチゴ狩りに行きたいなと思っているんですが、長男がなんとイチゴ嫌いでして、なかなか家族みんなで行くのが難しくてですね、おばあちゃんと一緒に行こうかなんて、今計画しているところです。
Rubyの誕生と特徴
さて、それは置いておいて、今週のテーマは、Rubyの歴史についてです。日本初のプログラミング言語として世界的に有名なRubyですが、その誕生から現在までの道のりっていうのは、いくつものドラマがありました。
それでは見ていきましょう。
時代は1993年、日本のバブル崩壊後の頃まで遡ります。
当時ソフトウェアエンジニアをしていた松本幸寛さん、通称松ですね、松本さんはですね、当時既存のスクリプト言語に不満を持っていました。
システム管理やテキスト処理の分野では、パールが支配的だったんですけど、パールの構文はどうしても問い言語、つまりおもちゃの言語としての側面が強くてですね、大規模なプログラミングには適さないと松本さんは考えていました。
一方のPythonなんですけど、そちらもオブジェクト思考言語として設計をされていましたが、松本さんが理想とするスモールトークのような、すべての値がオブジェクトであるというような純粋な世界観とは異なっていました。
そこでですね、1993年の2月に松本さんは同僚のエンジニアとのオンラインチャット中に新しい言語の開発っていうのを決意しました。
で、面白いのがですね、この時点ではまだ行動や一行も書いていなかったんですけど、先に名前を決めるっていうことになりました。
後方としてコーラル、つまりサンゴとか、あとはルビーなどが上がりましたが、最終的にはルビーが選ばれました。
これの意図というのが、パールが6月の誕生石である真珠っていうのを意味していたためですね、その次をいく言語という意味を込めて7月の誕生石であるルビーが選ばれたというようなエピソードでした。
そして、ルビーの設計思想としてはですね、松本さんが影響を受けた複数の言語の特徴をブレンドしてバランスを取ったものになっています。
言語の格闘なる部分に関してはLispの柔軟性を取り入れられています。
特にですね、ブロックと呼ばれるクロージャーの概念はルビーのイテレーターや制御構造の根幹を成しているんですが、そちらに関してはLisp分解の経緯っていうのが込められています。
またですね、全てがオブジェクトであるというような純粋なオブジェクト思考モデルっていうのは、スモールトークに由来していてプリミティブ型とオブジェクト型の区別がない一貫した操作性っていうのが実現されています。
さらにですね、実用性を重視して正義表現のリテラル表記やテキスト処理に特化した組み込み変数など、パールの強力な機能というのもしっかり継承しております。
これによってですね、ルビーというのは純粋でありながら実用的なツールとして設計されたという経緯があったりします。
そしてですね、1995年12月にルビーは0.95として初リリースがされます。
当初はですね、ドキュメントやメーリングリストというのは全て日本語のみでした。
そのためですね、日本国内のユニクスユーザーや研究者の間で普及していきました。
そしてこれがですね、逆に構想してルビーは英語系のトレンドに左右されることなく独自の文化としてプログラミングの楽しさの追求だったり、
あとはコミュニティの優しさみたいなところの調整するということができるような形になっていました。
世界への展開とRailsの影響
さてそんなルビーなんですけど、2000年代に入るとですね、大きな転換点を迎えます。
2000年にですね、デイブ・トーマスさんらによって通称ピッケルマンと呼ばれるようなプログラミングルビーというものが出版されました。
これによってですね、体系的な英語のドキュメントというのが作成されて、欧米のハッカー文化圏にルビーというものが紹介されました。
そしてルビーの直感的な文法と強力なメタプログラミングの能力によって、パールやJavaに代わる選択肢として世界中で認知され始めたというところがこのタイミングになります。
そしてですね、2004年にデンマークのエンジニアであるデイビート・ハイネマイヤ・ハンソンさん、通称DHHですね、によってRuby on Railsがリリースされます。
このRailsはですね、Rubyの持つ既存のクラスを動的に拡張できる機能だったり、あとはメタプログラミングというところをフル活用して設定より規約といった哲学を具体化した画期的なウェブフレームワークでした。
そしてこのRailsの登場によってですね、Rubyはニッチなスクリプト言語からウェブスタートアップにおける標準的な言語というものへ大進化というものを遂げます。
TwitterとかあとはGitHub、Airbnbといった後の巨大テック企業がですね、初期の技術スタックとしてRubyを採用して世界を設計していくということにつながります。
そういった形で世界に広まったRuby、元にRailsなんですけど、Railsなどの普及によってRubyというものが急速に広まっていったんですが、
反してですね、パフォーマンス面でのデメリットというところが露呈してきます。
Ruby 1.8系においてですね、実行速度とメモリー効率の限界ということが原因で、Railsを採用していたTwitterで頻繁なサービスダウンというのが発生していました。
あと有名なですね、鳥を鯨が持ち上げているというようなエラー画面を見たことがある人も多いかなと思うんですけど、
原因はRuby 1.8系がコード応応抽象構分機、ASTですね、に変換して、それを直接実行するインタプリタ方式というものを採用していたことに一旦あります。
この方式はですね、実装は容易なんですけど、速度が遅くメモリー効率が悪いというような欠点があります。
これが原因で、Rubyのパフォーマンスというところが批判の対象になってしまうということになりました。
パフォーマンスの向上と進化
そしてこれを解決するためにですね、2007年末にリリースされたRuby 1.9では、YARVと呼ばれる新しい仕組みというものが導入されます。
YARVはですね、Rubyコードをバイトコードにコンパイルし、仮想マシン上で実行するような方式で、
これによってですね、従来のインタプリタ方式と比べて2倍から5倍の高速化というところが実現されました。
しかしですね、このRuby 1.9なんですけど、高速化だけではなくて、言語仕様の大幅な変更というものも含まれていました。
この変更の大きさによって、Rubyコミュニティは安定と互換性を重視する1.8系と、高速で新機能を含む1.9系に数年間分断されてしまうというような危機を迎えます。
ただですね、最終的には、Railsがバージョン3.0以降でRuby 1.9の利用を強く推奨して、
その後必須としたことで、1.8から1.9への移行というものは実質的に完了して、この分裂の危機というものは収束していきました。
そして現代です。Rubyというものはパフォーマンス面でさらなる高みを目指しています。
2015年にはですね、Ruby 3はRuby 2の3倍早くあるべきという目標を掲げたRuby 3x3というプロジェクトが開始されました。
最初の主要なアプローチとしては、Ruby 2.6で導入されたMJITというものがあります。
これはですね、実行時にRubyメソッドをC言語のコードに変換し、GCCやCLangといった外部コンパイラーを呼び出してネイティブコードを生成するというような手法でした。
一定のタスクではですね、この方式で劇的な高速化というものを実現したんですけど、
レイリズのような巨大なアプリケーションではコンパイル時間のオーバーヘッドやメモリ消費量の増大によって
実用的な性能向上というものが得られにくいということが分かりました。
そしてこの状況を打破する、打開するためにですね、ECプラットフォームのShopifyのエンジニアチームによって開発されたのがYJITというものです。
こちらのYJITはベーシックブロックバージョニングという技術を用いて、
実行時の型情報に基づいて最適化されたマシンコードというものをメモリ上に直接生成するというような手法をとっていました。
このYJITはRuby 3.1で実験的にマージされて、Ruby 3.2ではYJITの実装言語がC言語からRUSTに書き換えられたことで、
開発効率をメモリ安全性が向上しました。
そしてさらにRuby 3.3では最適化が進んで、Railsアプリケーションにおいてもインタープリタ比で50%以上の高速化というものを達成して、
メモリ使用量も同時に削減されました。
そしてこれによってですね、明日ともに3x3の目標が現実のものになりました。
またですね、パフォーマンスの面と並んでRuby 3の柱となったのが平行処理の強化です。
従来のRubyのスレッドはですね、マルチコアCPU上でも同時に一つのスレッドしか実行できないというような制約がありました。
しかしこのRuby 3.0で導入されたRactorというものによって、マルチコアCPU上でも複数のスレッドを平行実行するということが可能になりました。
さらにですね、Fiber Schedulerというものが導入されたんですが、
こちらに関してはAsyncGemなどのライブラリを使用することで、
Node.jsのようなコールバック地獄に陥ることなく、通常の同期的なRubyコードのように非同期処理というものを期日実行できるようになりました。
そして加えてですね、大規模開発において重要な型安全性の需要に応えるためにRBSというものも導入されます。
これはですね、タイプスクリプトの型定義ファイルのように、Rubyコードとは別の.rbsというファイルに型情報を記述するというような機能になっています。
これはですね、コード自体に型定義を書くというものを嫌うRubyの文化を尊重しつつ、
IDEによる補完や静的解析のOKを受けるための設置案として見事に実現されたという形になります。
さてここまでいかがだったでしょうか。
松本幸寛さんの個人プロジェクトとして始まり、日本国内で愛されてプログラミングの楽しさとコミュニティの情勢がうまくいったRuby。
レールズの登場によってですね、世界的に注目されましたが、パフォーマンスの問題が発生し、1.8Kから1.9Kへの移行というものは困難を極めました。
しかしですね、そうした困難も乗り越えて、さらなるパフォーマンスと開発効率を求めて日々現在も進化を続けています。
さて今回のお話は以上となります。
もし少しでも今回の話がためになったなと思ったら、お聞きのプラットフォームでの高評価とフォローの方をお願いします。
また、XなどでハッシュタグOSSの歴史ラジオをつけて感想をつぶやいてもらえるとモチベーションになりますので、ぜひよろしくお願いします。
次回はですね、当時のツイッターからの移行先として一度は聞いたことあるんじゃないかなと思われるマストドンの歴史について見ていけたらなと思っております。
それではまた次回お会いしましょう。バイバイ。
