BunのRustポートの監査：13,000のunsafeブロックをナビゲート

ハイパフォーマンスランタイムを一つのシステム言語から別のシステム言語に移行することは、めったに単純な作業ではありません。元々Zigで書かれていたBunは、Rustへのポートを進めており、これは包括的だが議論を呼ぶコードベースの監査がリリースされた後に注目を集めています。

リリースビルドにRustポートが出荷される前に、Bunチームはunsafeブロックの使用量を定量化・分類するためのプリリリースパスを実施しました。その結果は目を引くもので、現在のポートには13,365のunsafeブロックが含まれています。数は多いですが、この監査はコードが本番ユーザーに届く前にこの技術的負債を削減するロードマップを提供することを目的としています。

13,365のunsafeブロックの内訳

Rustコードベースにおけるunsafeブロックの膨大な量は、コンパイラの安全保証が停止される場所であるため、開発者に警報を鳴らすことがよくあります。ただし、Bunの監査では、これらのブロックの大半は固有の欠陥ではなく、ポートプロセスの artefactual（人工物）であると主張しています。

ルート原因

監査によると、unsafeサイトの3分の2が以下の3つの主要なソースから派生しています：

Zigポート: 元のZig実装から直接持ち越された所有権のイディオムとパターンが多数あります。
FFI境界: C/C++ライブラリや外部エンジンとインターフェースするために必要なunsafeブロック。
パフォーマンス: unsafeブロックのごく一部（約3%）は、最大限のパフォーマンスを引き出すために意図的に使用されています。

安全への道筋

Bunの目標は、すべてのunsafeコードを排除することではなく、それを最小限に抑えることです。低レベルのシステムAPIとやり取りするランタイムでは、すべてのunsafeコードを排除することはほぼ不可能です。監査は、ブロックを以下の2つの主要な結果に分類します：

置換可能（約9,300サイト）: これらのブロックは安全なRustコードに変換できます。監査では、raw *mut Selfステートマシンや&selfから&mutへのキャストなどのパターンが削除の主要なターゲットとして特定されています。
永続的（約4,000サイト）: これらのブロックはunsafeのまま残りますが、安全な抽象化でラップする計画があり、これにより安全なRustから未定義動作（UB）がトリガーされることを防ぎます。

サウンドネス vs. カウント

監査の最も重要な発見の一つは、根本的にunsoundである5つの関数の発見でした。これらは、安全なRustから未定義動作に到達可能なケースであり、13,365のunsafeブロックとは独立して存在する実際のバグです。監査の第一優先事項は、これらのサウンドネスホールを修正することであり、unsafeブロックの総数に取り組む前に行います。

コミュニティの反応："AI Slop"と技術的懐疑

詳細な内訳にもかかわらず、この発表はHacker Newsの開発者コミュニティから大きな反発を招いています。批判の多くは、監査ページ自体が「AI generated」とラベル付けされていることに焦点を当てており、これがポート自体が手動のエンジニアリングではなくAI駆動の翻訳による産物である可能性があるという非難につながっています。

批判者は、このように巨大なクリーンアップ作業を必要とするポートにどれほど信頼を置けるかについて懐疑심을示しています。あるコメント者は次のように述べています：

"The port is AI slop, littered with 13k unsafe blocks. and this blog post is more AI slop, claiming to present a 'plan' for how to reduce that number.""

他の開発者は、複雑なシステムの全体移植の賢明さに疑問を呈し、個々のコンポーネントを本番環境に移行し、隔離してテストするピースミールアプローチの方がより安定した戦略だったと提案しています。

結論

BunのRustポートは、言語移行における大規模な実験を表しています。unsafeブロックの数について透明性を持ち、公開監査を提供することにより、BunはRustの安全保証へのコミットメントを示そうとしています。ただし、高いunsafe数と「安全」な実装の間のギャップは依然として広く、コミュニティの反応から、ポートプロセス中に蓄積された技術的負債が克服すべき重要な障害となる可能性が示唆されています。