私もみなさんと同じで、自分でハイテクを書く機会というのはほとんどない。隣のチームの Firecracker はハイテク感があるけれど、QEMU の Tiny Code Generator の話 なんかに比べるとずっと平和で、別のアーキテクチャのエミュレーションをがんばったりはしない。
社内を見渡すと、EBS の Physalia なんかは、自分のチームとの距離の遠さも手伝って、だいぶハイテク感がある。これは morrita さんの書いていた「巨大製品の中で使われる、ドメインに特化したものを作る、組織戦のハイテク」だと思う。
2000年のハイテクと、2020年のハイテク
「Berkeley DB のようなものを再実装」と言われて思い出すのは Tokyo Cabinet のことで、そう考えると2000年初頭にミクシィで働いていたころには、C/C++ なミドルウェアが突如としてプロダクションに導入されることが時折あった。
ミクシィの全文検索は Hyper Estraier そのままではなかった気がするけど、KVS の Tokyo Tyrant はそのまま使っていたし、非同期実行の仕組みは、MySQL を分散キューにする Q4M がベースになっていた。GREE には KVS の Flare が、DeNA には MySQL の SQL 部分を迂回して NoSQL 風に使う HandlerSocket があった。
2020年代にこういうソフトウェアを作る機会はなかなかない。これには、オープンソースの既存実装の充実にあわせて、クラウドの発展もあると思う。自分で MySQL を運用していた人が、改造された MySQL を運用するときのギャップに比べると、Aurora みたいなマネージドなデータベースを使っていた人が、改造された MySQL を運用するときのギャップは大きくて、だいぶ頑張らないと説得しきれない。
アプリケーションを作る人々がビジネスロジックに集中できるのは良いことだし、私は AWS 勤務なので滅多なことは書けないけれど、でもまあちょっとの寂しさは感じる。
新しいプログラミング言語と再実装
そういえば、containerd では Berkeley DB の代わりに bbolt というのを使っている。
新しいプログラミング言語とそのコミュニティでは、C/C++ を呼び出さない “pure XXX” な実装が欲しいという需要がある。Ruby や Python だと、そういう実装は「遅いけれど、インストールが簡単」くらいのところに落ち着きがちだけど、Go なら十分に速い実装を書けるかもしれないし、Rust なら C/C++ から呼び出されるのも夢じゃない。Rust のパーサコンビネーターである nom の作者の論文、Writing parsers like it is 2017 (PDF) でも、VLC の FLV パーサーを Rust で置き換えたりしていたし、curl には Rust バックエンドが入るらしい。
というわけで、ハイテクに飢えている我々は Rust 書くのが良いんじゃないでしょうか。ベタに C/C++ から移植しただけでも「俺の実装はメモリセーフである」と主張できます。多分。