転校生の本歌取
書き直しの必要に迫られることも、たまにはある。それはオリジナルが手に入らないとき。転職先で前の職場にあった内製ツールが使いたい。慣れたプログラミング言語にあったライブラリが新しい言語に欲しい。そんなときは自分の新しい環境でオリジナル相当品を書き直したいかもしれない。再発明、移植なんて呼ぶこともある。
この書き直し、再発明は、必ずしもオリジナルを超えなくていい。越えるべきオリジナルを使えない事情があってのコードだから。スポーツの試合で怪我をしたエースのかわりに急遽投入された補欠の立場に似ている。ベストを尽くし役割を果たせばいい。補欠系書き直しとでも呼ぶことにしよう。
Bazel と補欠たち
一応の役目は果たすものの、オリジナルほどはぱっとしない。そんな補欠系書き直しはたくさんある。
プログラミング言語をまたいだ補欠系書き直しとして真っ先に思いつくのは Node.js 用のビルドツールたち。Grant にしろ Gulp にしろ、たしかに Node のライブラリを直接呼び出せるぶん JavaScript 専用ツールならではの仕事をしている。けれど素晴らしい出来とも言い難い。 かつて GNU Make がつとめた決定版としての貫禄を欠いている。
職場をまたいだ再発明はどうか。
少し前、 Google は Bazel というプロジェクトをオープンソース化した。クロス言語の汎用ビルドシステム。Google 社内のコードは大半が Bazel でビルドされている。公開こそ最近だけれど内製ツールとしての歴史は長い。大規模コードベース相手にも動作が速いと社内外にファンが多く、会社をまたいで何度も再発明されている。
Facebook は Buck という Android と Java 用のビルドツールを作った。Buck は Bazel の強い影響下にある。DSL の文法があまりにそっくりなので、Buck の存在を明かした講演ではサンプルコードが画面に現れた途端に会場が Google 社員の笑いに沸いた。Bazel と同じく Buck は巨大ツリーのビルドを得意とする。加えて Android 向けの高速インクリメンタルビルドというキラー機能がある。一方で制限も多く、用途も Android と Java に限られる。そのためか今のところ普及しているとは言えない。
Twitter には Pants と呼ばれるビルドシステムがある。これも Bazel の仲間。文法もよく似ている。Pants は Scala や Python など複数のプログラミング言語および Thrift コンパイラのようなコード生成ツールを標準でサポートする。Twitter の Polyglot な性格をよくあらわしている。そして Bazel や Buck 同様大きなコードベースを扱うのが得意。Twitter の Scala エコシステムに集う企業を中心に使われてはいるものの、やはり普及の兆しは弱い。
Google 自身も Bazel の亜種を持っている。Chrome は GN というビルドシステムへの移行を進めている。GN は高速低機能な make 代替品 Ninja の設定ファイルを出力するメタビルドシステム。だから Buck や Pants とは少しちがう。それでも Bazel からいくつかのデザインを引き継いでいる。GN は前身の GYP より高速で文法も簡潔なのがウリ。でも現状の Chrome ビルドが複雑すぎてまだ移行が終わっていない。Chrome 以外で使う話も聞かない。
みな Bazel を使えばいいじゃん、といえるほど簡単な話でもなかろう。表舞台に現れるのが遅かった上にまだオープンソース化がおわっていない。今となっては Buck や Pants の得意分野で同じだけの力を発揮できるのかすら怪しい。贔屓目に言っても膝に矢を受けている。
内製ツールとしての Bazel は補欠でない書き直しの成功例だ。表現力を絞り厳密さを強いる DSL にビルドシステム本体の拡張性を組み合わせる優れた設計を起点に分散ビルドまでを備え、社内の GNU Make を置き換えた。けれどその成功はより広い世界に届いていない。書き直された補欠達もどこかぱっとしない。これはビルドシステムの呪いなのか、それとも書き直しの宿命なのか。いずれにせよ冴えない。
これらのツールを使ってる当人たちは困ってないだろうから、補欠よわばりが失礼なのはわかっている。でも Makefile を書いては自己嫌悪に陥り GNU Make を呪う身の自分はがっかりしてしまう。誰かあいつをやっつけてくれよ・・・。
転校生 Git
落ち込んできた・・・明るい話をしよう。補欠が思わぬ活躍をすることもある、とかね。
ある人は補欠系書き直しの金字塔として Git の名を挙げる。Linux カーネルのバージョン管理システムとしてうまれた Git は、ライセンスの変更に伴い使うことが難しくなった商用の分散バージョン管理システム BitKeeper の穴を埋めるために生まれた。分散バージョン管理がまだ珍しい 21 世紀初頭のことだから、Git の開発者が分散バージョン管理について多くを BitKeeper から学んだであろうことは想像に難くない。
今や Git はバージョン管理ソフトウェアの代名詞となり、一方の BitKeeper はユーザを探すのすら難しい有様。
Git を補欠よわばりするのはいくらなんでも畏れ多い。もうちょっと妥当な例えはないものか。転校生なんてどうかしら。ある土曜日、決勝戦当日の朝。エースストライカーが交通事故で骨折との報が届く。自分ら人数ギリギリだったのにどうすんの。青ざめるチームメイト達。そんな中、オレを出せと歩み出たのはウチのクラスの転校生だった。名前はたしか… Linus Torvalds…
Git の素晴らしさに異論はないし Linus Torvalds のことは尊敬している。でも転校生がロックスターだったこのストーリーに自分はあまり胸踊らない。転校生モノの面白さってそこじゃないでしょ。
Finagle
別の転校生 Finagle の話。Finagle は Twitter で開発された Scala の PRC フレームワーク。Twitter の Microservices 基盤の中核ともいえるコンポーネントだ。プロトコルは Thrift を話す。
Finagle の元ねたシステムの一つは Google の内製 RPC フレームワークだろう。GRPC の前身たるそのシステムは C++ で書かれ Protobuf を話す。
直列化フォーマットとしての Protobuf は以前からオープンソースだけれど、当時その RPC 実装は公開されていなかった。Protobuf のライバルたる Thrift にはいちおう PRC もあったが、多重化も非同期 API もないしょぼい代物。本気の RPC 実装は Twitter の Microservices 化に不可欠。でも使えるコードがない。そこで Finagle が生まれた・・・と自分は理解している。
Finagle は単なる補欠ではない。Scala の言語機能や Netty の拡張性をとりこみ、同世代には類のないフレームワークとなった。Future ベースのスマートな非同期 API。Zipkin に代表される様々なプラグイン。派生元の C++ RPC 実装にこのカッコ良さはなかったに違いない。(あったらごめんなさい。)
Finagle 開発者の一人 Marius Eriksen はもともと Google でインフラまわりのコードを書いていた BSD ハッカー。良いプログラマには違いない。一方で件の内製 RPC を作っていたわけではない。それでも前職の経験と Twitter の Scala 力、それに彼自身の技術を組み合わせて Finagle を作り上げた。
大企業からスタートアップに移って活躍をするエンジニアは、都会の私立高校から田舎の公立校にやってきた転校生とどこか似ている。都会のクラブでは当たり前の殺伐とした厳しさがここの部活にはない。田舎の公立で Rails なんて・・・。最初は馬鹿にしていた主人公。それでも段々と心を開いて練習に打ち込み、ついには全国大会へと進出する。会場で彼を待っていたのは一昨年まで在籍していた検索学園だった。「おまえ Ruby 使ってるんだって？クラッシュしない言語は楽だよナァ」ビッグデータだクラウドだとプロプリエタリな C++ コードをちらつかせつつ主人公を嘲笑するかつてのチームメイト達。でも今の俺には Scala がある！ノンブロッキングの未来が俺を待っているんだ！！逐次型マシン語と関数型バイトコードの戦いの火蓋がいま切って落とされた！！！
というストーリーの方が転校生モノとしては面白いとおもうのだよ。なおこの投げやりな物語はフィクションであり、実在の人物・団体とは一切関係ありません。
Finagle をめぐる俺たちの RPC (仮題)には続きがある。少し前、Uber 高校は TChannel という RPC フレームワークを公開した。やはり Thrift を話し、Python, Node, Go をサポートする。TChannel は Finagle の影響を隠さない。Finagle みたいのが欲しかったけど Scala を使っていないから自分たちの使う言語で書いたよと言っている。組織ではなく言語の壁が書き直しを促すパターン。Finagle に限らず GRPC など他の選択肢も増えた昨今、オープンソースプロジェクトとしての TChannel にどれだけ魅力があるのかはわからない。コードを軽くひやかしたかんじさほど意欲的にも見えない。地味な幕開けの第二部。行方は暇なときにでも見届けたい。
本歌取
単なる書き直しには身構える自分だけれど、補欠系、転校生系の書き直しはけっこう好きだ。転校生系書き直しは本歌取でもある。舞台を変え、新しい制約や文脈の中で古いアイデアを再発見する。その歌の核が何なのか、何が偶然で、何が時代の要請なのか。本歌取の歌い手に助けを借りながら、自分も答えに近づくことができる。そんな期待がある。
期待は叶わない事も多い。それでもカバー曲を聞く楽しみは残されている。新しい時代の風をうけ軽やかに歌う姿はそれだけで励まされる。羨ましくもある。オリジナルの隣で書き直すとなかなかこうはいかない。本家のプレッシャーが強すぎて息苦しい。
あるソフトウェアが再発明なのかオリジナルなのか、その境目は必ずしもはっきりしない。たとえばプログラミング言語の実装なんて繰り返されるアイデアのるつぼだ。だから何かを再発明だモノマネだと非難するのは気が乗らない。同じものになったらむしろ大したものだけれど、そもそもカバーはモノマネと違う。そっくりじゃなくていい。書き直しでなくても、新しいソフトウェアに潜む耳慣れたモチーフに気づくと得をした気分になる。わかるよ、僕もそれ好きだよ、なんて頬が緩む。
そういうの、たまにはいいじゃん。
草稿にコメントをくれた @karino2012, @jmuk ありがとう。