「あの人も読んでる」略して「も読」。さまざまな寄稿者が最近気になった情報や話題をシェアする企画です。他のテックな人たちがどんな情報を追っているのか、ちょっと覗いてみませんか？
みなさんこんにちは。
「あの人も読んでる」、第9回目の投稿です。maguro (X @yusuktan)がお届けします。
今回は雑多に
いつもは何かしらのテーマに沿ってコンテンツを紹介していることが多いのですが、今回は特にテーマを決めずに、最近気になった情報を雑多にお届けしようと思います。
1つのOSSに継続的に貢献する
最初に紹介するのは、Findyメディアに掲載されている あなたの知らないOSSの裏側 - tokio-rsで気付いたOSS運営の"リアル"3選 です。Rustの非同期ランタイムであるTokioプロジェクトのメンテナとして活動されているmox692さんによる寄稿です。
TokioはRustエコシステムにおいてかなり重要な立場にあるクレート（ライブラリ）です。非同期プログラミングを行う際はほぼ間違いなくお世話になります。このような重要なプロジェクトがどのようにメンテナンスされているのかを知ることのできる興味深い記事でした。
記事の中で特に印象的だったのは、OSSプロジェクトの貢献者パターンに関する話です。Tokioプロジェクトには約850人の貢献者がいますが、その半数以上は1回のコミットのみで参加を終えているとのこと。多くの人が短期的に関わり、その後は離れていくという現実があります。
mox692さんが強調しているのは、OSSにおいて「インパクトのある変更を行う」ことよりも、「長期的に貢献し続ける」ことの価値です。たとえ小さな変更であっても、長期的に続けることでメンテナから認知され、プロジェクトの運営の進め方が分かってきたりもします。OSSのメンテナになりたいと考えている人は、継続的に貢献することを目指すと良いのかもしれません。
2025年のNode.js、こんなことできる
次に紹介するのは、Node.js 2025 というブログ記事です。Node.jsは歴史的な経緯から、昔ながらの書き方とモダンな手法が混在する複雑な状況です。特に最近のNode.jsを積極的には追っていない方や、初学者の方にとっては、「ナウでイケてる書き方」をキャッチアップすることすら大変かもしれません。そのような方におすすめの記事です。
具体的には、以下のような項目がまとめられています。
- CJSではなく、ESM
- 最新のWeb APIを使う
- 組み込みのテスティングフレームワーク
- より洗練された今どきのasync/awaitの使い方
- Web標準のStreamを使う
node:worker_threadsを使った真の並列プログラム--watchと--env-fileを使った、より良い開発体験- 細かなパーミッション制御とパフォーマンスのモニタリング
- アプリケーションの配布（シングルバイナリ）
- 今どきのエラーハンドリングと
node:diagnostics_channelの利用 - 今どきのパッケージ管理とモジュール解決
僕自身、Denoの開発に携わっていることもあり、Node.jsについてもそれなりに追っているつもりでしたが、それでも知らない情報がいくつかあり、勉強になりました。
金融向けデータベースTigerBeetleから学ぶ
最後は、YouTubeで見つけたTigerBeetleに関する動画です。RustのLanguage Server rust-analyzerの作者であり、現在TigerBeetleという金融向けデータベースの開発に携わっているmatklad氏へのインタビューです。
TigerBeetleの設計で特に衝撃的だったのは以下の点です：
動的メモリ割り当ての完全排除
起動時にコマンドライン引数で指定されたメモリを全て確保し、その後は一切mallocやfreeを呼ばないという徹底ぶり。これはNASAの The Power of 10 Rules から着想を得たとのこと。
シングルスレッド処理
水平スケーラビリティを捨て、単一スレッドで超高速に処理する設計が採用されています。この設計の採用背景として、Scalability! But at what COST?が引用されています。この論文によれば、「無限のスケーラビリティがあったとしても、永遠にシングルスレッドの性能を超えることができないシステムが存在する」ということが示されています。つまり、並列化による性能向上が、オーバーヘッドにより相殺され、並列化を行わないほうが結果として高性能を示すケースが多くあったということです。
具体的には、分散グラフ処理フレームワークと、筆者らが実装したシングルスレッド実装のグラフ処理ライブラリの性能を比較した結果、基本的にはシングルスレッド実装のほうが分散グラフ処理フレームワークよりも優れた性能を示す、という結果が述べられています。
このことから、性能向上を目的として水平スケールを行う場合は、本当にそのスケールが意味のあるものなのかを検証する必要性があるということが分かります。TigerBeetleではこのような事実に基づき、単一スレッドによる実装を採用するに至ったということです。
なぜZigを選んだのか？
言語選択の議論も興味深いものでした。matklad氏はrust-analyzerの作者でもあり、その他にもRustエコシステムの発展に多大な寄与をしているスーパーエンジニアです。そんなスーパースターがいながら、TigerBeetleチームはRustではなくZigを選択しました。その理由として以下が挙げられています。
- メモリ管理の直接制御: 動的メモリ割り当てなしという制約と相性が良い
- 根本的なシンプルさ: Rustの借用チェッカーやトレイト、マクロなどの複雑さがなく、「赤ちゃんでも書けるようなコード」が書ける
- 依存関係ゼロ: TigerBeetleは外部依存を一切持たず、全て自前実装。当時のZigにはパッケージマネージャすらなく、自然と依存を避ける文化と合致
おわりに
今回は、広く使われるOSSプロジェクトのメンテナの視点からの気づき、Node.jsの進化、そしてRust界のスターmatkladさんが最近開発に携わっているZig製の金融向けデータベースTigerBeetleについて熱く語るYouTube動画という、雑多な3トピックを取り上げました。どれも興味深いトピックで学びがあると思いますので、ぜひチェックしてみてください。
また次回、おすすめコンテンツを紹介していきます。お楽しみに！
maguroさんの「も読」過去記事
- AIエージェント時代のセキュリティ - 隔離・パーミッション制御(6月30日公開)
- Rustの実践的な採用事例をながめる(6月13日公開)
- DockerなどのコンテナにおけるSIGTERMの取り扱い(5月30日公開)
- ライブコーディング視聴のすすめ(5月19日公開)
- 生成AIを使うか、使われるか - 学習を加速するための活用(5月8日公開)
- Rustの学習の難しさと取るべきルート(4月17日公開)
- MCPことはじめ / MCPサーバーのセキュリティリスク(4月4日公開)
- n月刊ラムダノート、実用Raft(3月21日公開)