AntflyがGoからZigへ全面書き換え、依存ゼロで検索エンジンを再構築
A search-and-inference database from scratch in pure Zig
Antflyはv0.1でGoによる検索エンジンをリリースしたが、v0.2では同じエンジンをZigでゼロから書き直した。理由は移植性、C相互運用、速度、テスト容易性の4点。ZigはCコンパイラを内蔵し、CUDAやONNX、Wasmtimeとの連携が容易で、アロケータやSIMD、comptime特殊化がデフォルトで使える。さらにstd.Ioによりシミュレーションテストを全パッケージに組み込み、RaftやLSM、全文検索、HTTP/3まで自前で実装。依存関係を完全に掌握し、AIやセマンティック検索向けの基盤を築いた。
Rustにはボローチェッカーがあり、Zigにはない。しかし私を悩ませるバグはuse-after-freeではない。遅れたレプリカ、二度届いたメッセージ、嘘をつくfsyncだ。ボローチェッカーはそれをカバーしない。
- thefogman
新しいエンジンおめでとうと言うべきなのは分かっているけど、正直に言うと、どうやってやったのかをもっと聞きたい。
つまり、シミュレータが機能するには「正しい」とは何か、そしてコードにどんな種類の失敗を投げかけるかを知っている必要があるよね？その2つは誰が決めたの？コードを書いたのと同じエージェントだった？それとも人間が書いた？あるいは形式仕様から導き出された？
「これが正しい」と言えるものが3つあったわけだ。エンドツーエンドテスト、形式モデル、そして古いGo版の振る舞い。それらが食い違ったとき、どれを信頼した？テストのほうが間違っていたということはあった？
リリース前にシミュレータが何かを捕まえたとき、間違っていたのは普通コードのほうだった？それとも「正しい」の定義のほう？
エージェントとコーディングする際のベストプラクティスについて、すごく役立つ洞察がありそうだ。Bunチームが同様のアプローチを取っていたら、それでも切り替えていただろうか。