Message Passing

何故プログラムの再利用というのが難しかったのか、という話をしていたら、「えっ？別に難しくないですよね？」とkzysに言われて、ちょっとその辺の話をしてみたくなった。

我ながら若者らしい発言。

ただ C/C++ でも、Linux だと pkg-config　や so ファイルの名前づけルール、apt-get とかのパッケージマネージャーのおかげである程度ビルド周りの話は解決していて、結果として他ライブラリを色々使うソフトウェアがあった気がする。GNOME なアプリを入れたら依存で色々入ったりしませんか? クロスプラットフォームだと確かに大変そう。

私は、アルバイトじゃない最初の仕事がミクシィで、ソーシャルネットワーキングサービスのミクシィはいわゆる LAMP (Linux + Apache + MySQL + Perl) スタック、そのあとも全体的に C/C++ とかは使わず、Linux だけを気にするサーバーサイド仕事が多かったので「再利用できない」という感覚はあまりない。MySQL や memcached みたいなオープンソースなミドルウェアと、CPAN ないし、その言語についてるパッケージマネージャーからダウンロードできるライブラリを組み合わせてソフトウェアを作るのが普通。

ライブラリの再利用と、フレームワークの再利用

ミクシィ世代の会社には、それでも自社 Web アプリケーションフレームワークというものを見かける機会がまだあって、オープンソースになっているものだと、例えばライブドアには Sledge, はてなには Ridge, GREE には、これは CTO の藤本さんがもともと開発していたものなので、自社フレームワークと呼ぶのは語弊があるけれど、Ethna があった。

その後のクックパッド世代になると、Rails や Django といった既製のフルスタックなフレームワークを使うのが普通になってしまって、Web アプリケーションフレームワークを自作するのは、よっぽどわかっているか、よっぽどわかっていないか、どちらかじゃないとやらない、普通じゃない選択肢になってしまったという感がある。

とはいえこれも一昔前の話で、最近のモバイルアプリとシングルページアプリケーション世代の「サーバーで生成するのは JSON だけでいいですよ」という人々が何を使っているのかというと、うーん、なんなんだろう。私はここらへんの仕事をしたことがないのでコメントは控えます。

最近にみかけた再利用

自分のいまの仕事の周辺でいうと、例えば containerd には ttrpc というオレオレ RPC を使っているんだけど、これはセマンティクスは gRPC で、IDL もそのまま proto3 を再利用している。Firecracker の API は RPC ではなく REST だけど、IDL は OpenAPI で定義されている。みんな色々と再利用できていてえらいなーという感じ。