ハクソク

世界を動かす技術を、日本語で。

Bunの実験的なRust書き換えがLinux x64 glibcで99.8%のテスト互換性を達成

2026年5月9日原文(twitter.com)

概要

Zig から Rust への移植ガイドについて解説。 Zig と Rust の違いと注意点を要約。 主な移植手順と推奨ツールを紹介。 よくある課題とその解決策に言及。 参考リンクとコミュニティ情報も掲載。

ZigからRustへの移植ガイド

  • Zig と Rust はどちらも モダンな低レベル言語 だが、設計思想や型システムに違い。
  • 安全性重視 のRustと、 柔軟性重視 のZig。
  • Zigの ポインタ操作 や メモリ管理 はRustの 所有権システム と異なるため、移植時に注意。
  • Rustでは unsafeブロック を必要とするコードが増える場合あり。
  • Zigの エラーハンドリング （error union型）はRustの Result型 にマッピング可能。
  • ビルドシステム ：Zigのbuild.zigはRustのCargo.tomlに変換。
    • 依存関係やビルド設定の記述方法が異なる。
  • 標準ライブラリ のAPI差分に注意。
    • 例：ファイル操作、スレッド管理、フォーマット処理など。
  • FFI （Foreign Function Interface）を使う場合、Rustのexternやbindgenの活用推奨。
  • ツールチェーン ：Zigのzig buildと、Rustのcargoコマンドの違い。
  • ドキュメントコメント や テスト記法 も書き換えが必要。

よくある課題と解決策

  • 所有権とライフタイム の違いによるエラー発生
    • Zigの生ポインタ利用コードはRustで所有権を明示的に管理
  • エラーハンドリング の変換
    • ZigのtryやcatchはRustの?演算子やmatch文で対応
  • Cとの相互運用
    • ZigのCインターフェースは、Rustのbindgenやcbindgenでラップ
  • ビルドスクリプト変換
    • ZigのビルドロジックはRustのbuild.rsに移植

参考リンク・コミュニティ

  • Zig → Rust Porting Guide (Hacker News)
  • Zig公式ドキュメント
  • Rust公式ドキュメント
  • Zig/Rust両言語の GitHubリポジトリ
  • 移植経験者による ブログ記事 や フォーラム投稿

Hackerたちの意見

これをやるのに6日もかかるんだ。意味がなくても、トークンと作業が今後どう結びつくかを示してるよね。計算能力が多い人や会社と競うのは大変だと思う。彼らは、君ができないことを簡単にやっちゃうから。

└

従業員が少ないからね…。

└

蒸気力や電気についても同じことが言えたよね。これはただの比喩じゃなくて、これらのものの魔法は普遍的な情報エンジンであることにあるんだ。資本を使って、よく理解されたスケーラブルな技術でそれを作り、電気に接続すれば、価値が生まれる。要するに、「持つ者」と「持たざる者」が出てくる可能性はゼロだよ。電気が現代社会でそうなったわけじゃないからね。

└

これがアンスロピックから標準料金で支払った場合、いくらかかったのか気になってしょうがない。誰か大体の価格を教えてくれない？

└

良いテストスイートを含むプロジェクトを別の言語に翻訳するのは、LLMがうまく機能する素晴らしいケースとして知られてる。完全なコードベースを例として使い、すべてをチェックするためのテストスイートがあれば、目指すゴールに向かって反復するのがずっと楽になる。LLMはすでに目標が何で、どう実装されているかを見ているから、仕様から始めるよりもずっと簡単な問題なんだ。

└

いや、これらのエージェントはローカルで動かすのがどんどん簡単になってきてるよ。Qwen 3.6 27b試してみた？サイズに対してできることがすごすぎる。コンテキストをうまく管理すれば、小規模プロジェクトには100%合ってる感じ。

業界はプログラミング言語として英語に移行してる気がするし、ソフトウェアを作るためのフレームワークとして仕様・コンテキスト・TDDが使われるようになってる。これを嫌がる人もいれば、解放感を感じる人もいるよね。自分を英語で表現することとC++みたいな言語で表現することの感じ方に広く関連してると思う。ちなみに、非英語モードでLLMを使ってプログラミングしてる人っている？中国語を使ってる人が結構いると思うけど、誰か実体験をシェアしてくれないかな。

└

中国語がLLMベースのプログラミングにどれくらい効果的か気になるな。一方では、中国語の文字は意味が濃いからトークン効率がいいけど、逆に曖昧さが増すかもしれないね。

└

私は50%英語（個人プロジェクト）/50%ポーランド語（職場）で使ってるけど、正直、出力や曖昧さにあまり違いを感じてないよ。ポーランド語のプロンプトは動詞の形が多いから短くなる傾向があるし、「壊れた」と言う時に使う言葉がちょっと不気味でストレートすぎて、時々笑っちゃうことがある。

└

同意するよ。特定の言語のコード生成にあまりにも焦点を当てているものは、もう過去の戦争を戦ってる感じがする。UMLモデリングの復讐だね。最終的には、エージェントの作業から出てくるものが正式な仕様の問題になるくらい、十分に良くなると思う。コードが実際に必要で、純粋なエージェントオーケストレーションのワークフローでは達成できない場合を前提にして。

└

英語とアルバニア語で使ってるけど、実際あんまり違いはないよ。すごいね。

└

自然言語はシステムを構築するために必要な精度がないよ。システムを正確に指定するための言語はもうあるんだから。それは「コード」と呼ばれてる…

Hacker Newsで議論の続きを見る