NewsInsight

いよいよ始まるRuby 1.9への移行

開発コアメンバが語るRubyの今とこれから（前編）

2009/07/24

　2009年1月にリリースされたRuby 1.9.1は、1つのマイルストーンとなるバージョンだ。バージョン1.8系から1.9系へのアップデートでは、評価器という処理系にとって大きなモジュールが入れ替わったほか、文法が洗練され、クラスも大幅に拡充される大きな変更となっている。その1.8系から1.9系への移行の準備が整った初めてのバージョンがRuby 1.9.1という。

　Rubyはどう進化し、これからどう変わろうとしているのか。Rubyの生みの親、まつもとゆきひろ氏に加えて、Ruby 1.9系で採用されたVM「YARV」開発者の笹田耕一氏、Ruby 1.9系のリリースマネージャを務めるyugui（園田裕貴）氏の3人に話を聞いた（聞き手：＠IT編集部 西村賢）。

Ruby 1.9は移行準備オッケー

＠IT　yuguiさんは、2009年2月のDeveloper's Summitの講演で、そろそろRuby 1.8系から1.9系への移行を始めるべきだと主張されてましたね。

yugui　ええ、一般のRubyユーザーはRuby 1.9への乗り換えは慎重にという立場の人もいますけど、私はそろそろ移行を考える時期だと思います。

＠IT　もう1.9に移行してもオッケーだと。

yugui　もう根本的な仕様が変わることはないという意味でオッケーです。2007年12月に出た1.9.0は、仕様が煮詰まっていなかったので、必ずしもお勧めできませんでした。後になってRuby本体が「こっちのほうが良かった」と仕様変更して、それまでのスクリプトが動かなくなる恐れもあったからです。その状態で移行をしていたとしても、2度手間になっていたかもしれません。でも、2009年1月の1.9.1リリースで、そういう恐れがなくなりました。今後、もし変更があるとしても上位互換性を保った小さな変更になります。ですから、Ruby 1.8から1.9への移行という意味では、これが最初で最後になるはずですから、みなさんそろそろ資産を移行してください、と。プロダクションレベルで1.9を使わなければ話にならないという状況になって慌てて資産を移行するのでは遅いので、それを始めるなら今からと言いたいんですね。

1.9を使うと、もう1.8に戻れない

＠IT　ライブラリの互換性はいかがですか？

yugui　対応は進んでいると思います。ただ、一口に互換性と言っても何段階かあっていろいろです。いちばん望ましいのは、何もしないでもそのまま動くパターン。次にいいのがアプリケーションやライブラリを再インストールすれば動くという状態。それより少し悪いのはスクリプトに細工をしないと動かない状態。それよりさらに悪いのは、バイナリレベルの互換性が破れて再コンパイルしないと動かない状態。最悪なのはライブラリで、あちこち型をいじらないといけないようなものですね。スクリプトも拡張ライブラリも根本的に書き直しが必要となるものは最悪です。

＠IT　そういう最悪のパターンって、1.8から1.9のときにはあったんですか？

yugui　エンコーディング周りで結構ありました。エンコーディング・アウェアじゃないライブラリとか。それに、スレッド周りも変わってますから、標準のデバッグは動くけど、Rubyデバッグは動きが怪しいとか、そういうのはあります。

＠IT　なるほど。互換性が理由だと思いますが、プロダクションレベルで使う人で、1.8.6以外のバージョンは不要とっている人もいるようです。

ささだ　1.9系は要らないっていう人は、いっぱいいますよね。

yugui　私も1.8.6を使っていたことがあるので、悪い言語だとは思いません。でも、一度Ruby 1.9で便利な機能を使うと、今さら戻れませんね。

＠IT　例えばどんな機能？

yugui　文字コード変換がごくごく自然にできるとか。

まつもと　ああ、iconvとかnkfなんとかが不要というね。

yugui　Ruby 1.9ではバイト表現を気にせず、文字は文字として扱えます。あと、標準ライブラリも整理されてますよね。

まつもと　1.9にあって1.8にないメソッドも結構あるよね。あれ、これは1.8になかったんだっけとか。

yugui　イテレータがEnumeratorオブジェクトを返すのが意外と便利ですね。

＠IT　これまでブロックを書かなきゃいけなかったところにメソッドをつなげていってメソッドチェーンが書きやすくなったとかもありますよね。

まつもと　便利だから1.8系の最新バージョン、1.8.7にもバックポートされて入ったんだよね。

yugui　あと何といってもRuby 1.9は処理が速いですよね。1.9に慣れると、1.8でイライラして耐えられないことがあります。

ささだ　素晴らしいことを言いますね！（笑） 1.9ではイライラしませんか？

yugui　私が扱うデータ量ではイライラしない程度に結果が返ってきます。

まつもと　ささだくん、がんばったね。ここでプログラマとしての腕の差が出てくるよね。1.8を作ったぼくと、1.9のVMを書いたささだくんの（笑）

ささだ　いやまあポリシーの問題ってことではないですか（編注：Ruby 1.8系と1.9系では、処理系としての設計が大きく変わり、抽象構文木をたどりながら実行する方式から、いったんバイトコードにコンパイルしてから実行する方式になっている。ささだ氏は1.9系で採用されているVMの「YARV」を設計、実装した。1.8以前は、速度性能よりも安定性をとっていたため、速度に関する優先度は低かった）。

関数型っぽくなったRuby 1.9

＠IT　1.9の目立った変更には、ほかにもブロック変数のスコープがローカルになったとか、Procリテラルの導入とかもありますよね。

yugui　私も最初はぎょっとしましたけど、慣れたら使いやすいですね。

＠IT　lambda式を端的に表現できる新記法の「->」は賛否あるみたいですが、やっぱりタイプ数が少ないと使いやすくて利用が増えるんじゃないでしょうか。あとブロックが閉じてる感じが強くするんですが、あれって関数型っぽくなってるってことなんでしょうか？

まつもと　そうなんですよ。やっぱり関数型の影響受けてますよね。

＠IT　1.8系でのブロック変数のスコープの扱いは、関数型から来た人の間では、むしろ「何でこうなってるんだ？」という意見もありましたよね。

まつもと　それは、Rubyが最初から関数型言語としてスタートしてないからであって、言語が違うからですよね。

ささだ　やっとまともになったと言ってた人もいましたよね。

まつもと　あ、そう？ そういう観点から見れば、そうかもね。

yugui　私もそう思いますよ。

まつもと　申し訳ない。そういうバックグラウンドで育ってこなかったもので（笑）

＠IT　ブロック変数のスコープの変更で発見されづらいバグが増えたりしないのですか？

まつもと　発見されにくいってことはないですね。添付ライブラリで問題があるか探さないといけないんですけど、Warningオプションを付けてコンパイルすると、ぼこぼこ見つかりますしね。

ささだ　これまで書けていたのが書けなくなるっていうのがいくつかあるので、それは厳しいかもしれません。例えば今まではブロックパラメータに、いろんな変数が置けましたが、今後はパースエラーになっちゃうとか。ライブラリ作者とか、知らないとつらいかも。このへん、まつもとさんは躊躇なかったんですか？

まつもと　（大きな仕様変更は）ほめられたスタイルではないですけど、まあいっかって（笑） そのへんの判断ってユーザーが増えても昔から変わってないよ。

大胆な仕様変更はRubyの仕様!?

ささだ　以前から、これをまつもとさんに聞きたかったんですけど、互換性を破る仕様変更について、いつまで今と同じ方針が続くんですか?

まつもと　ずっと（笑）

ささだ　こんなこと言ってますけど（笑）

yugui　いや、まあいいんじゃないですか。

＠IT　互換性が破れるのって日本のRubyistの間では驚く人は少ないのかもしれませんけど。

yugui　私は1.4から使ってるので、最初のバージョンの移行のときは驚きました。ビックリする仕様変更もありました。

まつもと　大きな仕様変更は昔よりは減っているんですけど、日本でも初めて使ったのが1.8.6という人はいるので、1.9への仕様変更で驚く人はいるみたい。

ささだ　海外だと1.8.6じゃないと嫌だと言ってる人もいて、特にRailsユーザーがそうですよね。

yugui　彼らは1.8.6しか知らないんだと思います。

まつもと　1.9は、彼らにとっては最初の大きいバージョンアップだったからかなー。

＠IT　でもRailsの人たちは、むしろRailsがどんどん変わるからRubyだって変わっても平気そうなもんですけどね。なんででしょう。

ささだ　確かにそうですね。Railsが変わっても文句を言わないのにRubyが変わったら文句を言いますよね（笑）

まつもと　Rubyが変わって困ると苦情をいう人がいます。1.9で取り入れた機能を1.8系にバックポートした1.8.7についても、「1.8.6と違う！」と言う人がいますけど、あれはFUD的な感じですよね（編注：FUDとはFear（恐れ）、Uncertainty（不確実性）、Doubt（疑い）の頭文字で、マーケティング上の戦略。漠然とした情報で利用者に不安を感じさせることで購買行動に影響を与える手法）。実際にトラブルがあってRailsが動かなかったというのはありますけど、せいぜい2個所ぐらいのバグ。印象が悪かったのかな。

yugui　初めから1.9の上にRailsができていれば誰も困らなかったわけです。1.8に機能が欠けてたので、Railsががんばってしまった。それでRailsと1.9とで機能が衝突してるってところがありますよね。でも、むしろそれは1.9を使おうというモチベーションにしてほしいですね。

RailsがRubyに与えた影響

yugui　Railsが、Webアプリ向けの拡張を基本クラスにするのはいいとして、「chars」のようなWebに依存しない基本的なクラスを追加しないといけないこと自体がRuby 1.8の言語としての敗北であって……。

まつもと　あー、それはどうかなぁ。「2.weeks.ago」と言われても、ぼくは困っちゃうんだけどなぁ（笑）

yugui　それは別としてですね、charsですよね、まず。

まつもと　そうか、charsね。

yugui　あとシンボルをProcに変換するSymbol#to_procですよね。あの発想はなかったですけど、言われてみたら、とっても自然で、言語として本来サポートしているべきものだったんですよ。

まつもと　うん、1.9に入れましたよ。

＠IT　ほかにRailsを見て1.9に入れたものは？

まつもと　そのto_procぐらいかな。おかげで「＆：method名」で、各要素に対してメソッドを適用することができるようになりましたね、それもRails由来。Railsの基本ライブラリのActiveSupportも一通り見ましたけど、一般的なものでRuby本体に入れても問題なさそうなのって、to_procぐらいしかなかったってことです。

yugui　Railsががんばらないといけなかった部分を直したのがRuby 1.9なので、1.8より言語として完成度が高いですよね。私は1.9でようやくRubyは使えるようになったという感じがしますね。

リリースマネージャとしての仕事

＠IT　yuguiさんは1.9系のリリースマネージャということで、どういうお仕事をされてるのですか？

yugui　以前通りRuby本体のパッチを書いて送ったりしもしていますが、マネージャとして私がやってることといえば、ドキュメントを書いたり、タスクをまとめて、みんなにハッパをかけるためにメールを書いたり、誰もやらない部分をパッチを書いたりという感じです。まあ、Cの読み書きができる事務係みたいな感じですね。

ささだ　レポジトリの運用ポリシーを考えるとか、事務係以上のものと思いますけどね（笑）

まつもと　誰かがやってくれないと困る仕事で、誰もやりたがらないものってあるんですよね。yuguiさんには、そうしたところもやっていただいています。

PerlとRubyの印象

＠IT　yuguiさんはRuby暦7、8年ぐらいですか？

yugui　ええ、もともとはC++とPerlを使っていました。

＠IT　PerlとRubyを比べると印象はいかがですか？

yugui　Perlも使いこなせばスゴイんですけどね。私が今Perlを知っているぐらいに当時からPerlを使いこなしていたら、Rubyを使おうと思わなかったかもしれませんね。ただ、Perlってプロフェッショナルレベルとラクガキレベルで、ものすごく落差があるので、下のレベルでぐちゃぐちゃやってると訳が分からなくなるんです。だから入門はRubyのほうが楽でした。自分がC++で覚えたオブジェクト指向が使えるといいなと思ってRubyを使い始めました。

まつもと　Perlってすごい幅広いよね。Perl4の頃から使い回してますというCGI掲示板もあるし、モダンPerlもある。違う世界。

yugui　当時はネットワークが遅かったので、標準でいろいろ付いているRubyのほうが使いやすかったというのもあります。PerlだとTimeクラスが標準でないし。

C言語による拡張が容易なRuby

yugui　拡張ライブラリを気楽に書きたいというのがあったんですが、その後、私がなかなかPerlに足を踏み入れなかった理由の1つはXSがイヤだったからです。

まつもと　XSは難しいよね。

＠IT　XSとは？

まつもと　Cのライブラリを書くときのコード規約ですね。

ささだ　Pythonはどうなんですか？

まつもと　書けるよ。まあ簡単といえば簡単だけど、「リファレンスカウント」だけはめんどくさい。特定の関数から来たリファレンスは、カウントを増減しないといけないというのは決まってるんだけど、ドキュメントに書いてあったりなかったり、忘れちゃったりね（笑）

＠IT　Rubyは簡単なほうなんですか？

yugui　簡単ですよ。

まつもと　史上最強に簡単ですね。RubyだとふつうのCで書けるところが、Perlだとマクロの塊みたいなので補足的情報を追加しないといけないんですよ。

ささだ　必要なおまじないが多いってことです。

yugui　私はRubyを見て、これなら必要なライブラリはいつでも足せるなと思いました。それもPerlじゃなくてRubyを選んだ理由として大きいですね。

ささだ　そういう意味ではやっぱりグルー（糊）としての役割が重要だったんでしょうね。

まつもと　ぼく自身がCのライブラリをいろいろ呼びたいわけで。

＠IT　もしかしてRubyが好きな人って、Cが好きだけど、素のCでオブジェクト指向をやりたくないっていう人も多いのでは？

まつもと　一般論は分かりませんけど、ぼくはそうですね。Cで書く時間のほうが長いんですけど、Rubyのランタイムがないと書けないんですよね（笑）

Rubyの拡張性がコミュニティの性質に影響

yugui　簡単に拡張できるというのはRubyのコミュニティの成長に貢献したと思うんですよ。拡張の方法って2つあります。1つは拡張ライブラリを作ることで、もう1つはオープンクラスという性質を利用することです。Rubyを使う人って、ライブラリで何か良くないものがあったら自分で変えればいいと思っているんです。それでRubyは発展してきた面があります。

まつもと　Rubyって、例えば「こういうメソッドがあったらきっといいに違いない」みたいな提案は採用しないんですよ。実際にやって良かったよというほうが説得力が強いわけです。世の中、みんないろんなメソッドがほしいわけで、それを全部入れると破綻しますよね。入れる、入れないの線をどこかで引かないといけないんだけど、そのときに実際にこうだったと言ってくれないとなかなか入れられないんですよ。このオブジェクトを、このオブジェクトに変換するメソッドがあるときっといいに違いないと言われても……、「そうかもね」としか言えません。机上の空論なんです。

yugui　Rubyの処理系本体に手を入れられない人であっても、Rubyレベルなり、拡張ライブラリなりで、自分で気軽に試してみることができます。オープンクラスという特徴を使ってメソッドを足したり書き換えてみたり、それをCで実装したり、ということです。それで実際に新機能を使ってみて良かったらRuby本体に入れてくれって言えばいいんです。Rubyコミュニティでは、そういう流れがずっとありました。

＠IT　Linuxのリーナス・トーバルズがGitのような分散バージョン管理システムの利点は、実験実装と、その取り込みが容易になることだと言ってますが、ちょっと似てますね。

yugui　ええ、Gitではネット上に各自のレポジトリがあって、みんなそれぞれ自分がいいと思うものを試してみることができるっていう話ですよね。もともとRubyコミュニティにはそういう雰囲気があったんですよね。だからGitを採用すれば、たぶんもっと良くなると思うんです。

＠IT　あれ？ RubyでもGit採用するのですか？

まつもと　ぼくはyuguiさんにバトンを渡したつもりです。

yugui　Gigのリポジトリにミラーはするという方針は決まったんですが、時間が取れなくて。

＠IT　少なくともGitで取ることはできるようになる？

yugui　ええ、ただ、そこからコミットができて、メインストリームに積極的にマージができないとあんまり意味がありません。この辺り、いろいろと案を練っているんですが、そこを詰めて実行する時間が誰も取れていないという感じです。

Rubyコミュニティの「象徴」

＠IT　Gitを使うとコミッタの権限が弱くなるということもあるかもしれませんが、その辺は問題ないのですか？

yugui　開発コミュニティに、いっぱい人が入ってくるのはいいんじゃないですか。

まつもと　ぼくはすでに「コミット権を取り上げます」って脅されてるぐらいだし（笑）

＠IT　JRubyの人たちも含めて、広い意味でのRubyコミュニティの中で、まつもとさんはご自分の立ち位置を現在どうご覧になっていますか。

まつもと　なん……、でしょうね。ぼくは「象徴」か何かじゃないかと。日本国の象徴みたいな（笑） コードを見てても最近は知らないコードがいっぱい入っているんですね。なんだこれは、みたいな。yuguiさんが整理したライブラリもあるし、評価器はYARVですし、“田中哲スペシャル”がいっぱい入ってるし。はっはっは。

＠IT　コードレベルではそうであっても、機能やメソッドのデザイン面ではまつもとさんの管理下ですよね。

まつもと　そうですね、あるメソッドを入れるかどうかとかね。

＠IT　そのときの判断がRuby界隈（かいわい）全体で守られるっていうのは紳士協定というか、みんながそういうものと思っているだけですよね。

まつもと　まあそうですね。

＠IT　それって怖くないんですか。

まつもと　いやまあ……、怖いってことはないですね。フォークしてくれてもいいですけど、あまりオリジナルと違ってしまったら、それはRubyと呼ばないほうがいいかな、とは思いますけどね。

yugui　Gitが中心にあってネットワークを張るようになれば、マイナーな、特定機能を持つRubyというのが出てくるとは思うんですけど、それがまつもとさんの設計と根本的にフォークしていったら、それはRuby以外の言語ですよね。

ささだ　たくさん増えたときに困ったりしないんですか？

yugui　結局、取捨選択じゃないですか。Git上であれば、「あっち」のラインの機能を、「こっち」に気軽に持ってこられるので。

Fork Ruby発言は歓迎？

＠IT　Ruby関連書籍で知られるデーブ・トーマス氏が2008年のRubyConfの基調講演で「Fork Ruby」（Rubyをフォークさせよう）と提言しています（動画）。関数型Rubyだとか、並列Rubyとか、最小限の機能しかないRubyLiteとか、いろいろ実験しようじゃないかという発言でした。あの提言について、まつもとさんのご意見は？

まつもと　それはそれでいいと思うんですよ。やってみないと分からないことってあるんです。特にプログラミング言語の新しい概念みたいなものって、作ってみてなんぼみたいなところがあるんですよね。そういうのを確かめるためにも、Rubyの思想を継承した新しい言語がどんどん出てきて、その中でRuby本体で対応できるものがあれば、取り込んでいくというのもありだと思うんですよ。ぼくは多様性を善だと思っていて、Rubyに似た何かの言語がいっぱい出てくるのは、それはそれで万々歳だと思ってるんですね。

＠IT　かなり違ったRubyが出てくるかもしれません。

yugui　並列して言語が発展していく分には、それらの距離はそう変わらないじゃないですか。

まつもと　知見とか共有できるものがあるかもしれませんしね。

ささだ　そういうのは否定はしないですよね。ただ、「まつもとのRuby」とは呼ばないでね、ということですよね。

まつもと　そう、「このRuby」を取られてしまうとちょっとイヤなので、それだけは守りたい気がします。それと、純粋に効率の観点だけから言うと、1つのRubyにみんなの力を集約して、RubiniusもJRubyも要らないというふうになったほうが、より短い時間で、より速い、より良いRubyを手に入れられるのに、という気持ちは正直あります。だけど、それが正しくないことも多いので、まあフォークしたければフォークしたほうがいいし、多様性があったほうが、一見、効率は悪くてもいいんじゃないかなと思います。

＠IT　もっと速くCRubyが良くなるのも見てみたいですけどね。

まつもと　そうなんですよね。だからもっとたくさんの人を“こっち”に集めたいという気持ちもあるんですよね（笑）

＠IT　前回お会いしたときにはRuby開発メンバが意外と増えないという話でしたが。

まつもと　増えないですねぇ。コミット権をくれっていう人はあんまりいないですよね。

＠IT　メーリングリストで挨拶をしてパッチを投げて、というのはハードルが高いんじゃないですか。Gitでそういう壁がなくなるとリーナスが言っています。

まつもと　かもしれないねぇ。

yugui　開発参加へのハードルは下げたいですね。そのためにGitにネットワークを移行したいというのはありますね。

開発コアメンバが語るRubyの今とこれから（後編）

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）