LadybirdがRustを採用、AIの支援で移行を加速

 (ladybird.org)
5 ポイント 投稿者 GN⁺ 2026-02-24 | 1件のコメント | WhatsAppで共有
  • Ladybirdブラウザープロジェクトが、C++に代わるメモリ安全な言語としてRustを採用し、移行過程でAIツールを活用している
  • これまでSwiftを検討していたが、C++との相互運用性やプラットフォーム上の制約から限界を感じ、Rustへ方針転換した
  • 最初の移植対象はJavaScriptエンジン LibJSで、Claude CodeとCodexを用いて数百件のプロンプトによる手動指揮の翻訳を実施した
  • 約2週間で2万5,000行のRustコードを完成させ、出力・性能の両面でC++版と完全に同一であることを検証した
  • プロジェクトは当面、C++とRustの並行開発体制を維持し、長期的には安全性と保守性を強化する計画である

Rust採用の背景

  • LadybirdはC++に代わるメモリ安全な言語を探すため、複数の言語を検討した
    • SwiftはC++との相互運用性の不足と、Appleエコシステム外でのプラットフォーム対応の制約により候補から外れた
  • Rustはシステムプログラミングのエコシステムが成熟しており、多くのコントリビューターがすでに習熟している言語と評価された
  • 2024年にはRustのC++的なOOPへの不適合を理由に採用を見送ったが、その後安全性とエコシステムの成熟度を理由に再導入を決定した
  • FirefoxとChromiumがすでにRustを導入している事例も踏まえ、Ladybirdにも適していると判断した

LibJS移植の過程

  • 最初の移行対象はLadybirdのJavaScriptエンジン LibJS
    • lexer, parser, AST, bytecode generator などの独立した構成要素と、test262ベースのテストカバレッジがあり、出発点として適していた
  • 移植にはClaude CodeとOpenAI Codexを使用
    • 自動生成ではなく人間主導の翻訳で、移植順序やコード構造は直接決定した
    • 数百件のプロンプトで細かく指示し、その後さまざまなモデルによるコード検証とエラー検出を行った

結果と検証

  • 目標はC++とRustのパイプラインの出力がバイト単位で同一の結果を出すこと
  • 約25,000行のRustコードを2週間で完成させ、本来数か月かかる作業を短縮した
  • ASTとバイトコードが完全に同一で、テストおよびJSベンチマークでも性能低下はなかった
  • C++とRustのパイプラインを同時実行するlockstepテストにより、Web閲覧中の結果一致を検証した
  • 現在のコードはC++から翻訳された形を維持しており、レジスタ割り当てパターンまで同一に模倣している
    • これはC++パイプラインとの互換性確保を最優先しているため
    • 将来的にC++パイプラインを廃止する段階で、Rustコードの簡素化と整理を行う予定

今後の計画

  • Rustへの移行はプロジェクトの主力開発方針ではなく並行作業として進められる
  • C++とRustのコードが共存し、明確な相互運用の境界を維持する
  • 移植の順序と範囲はコアチームが管理し、外部コントリビューターは事前調整が必要
  • 長期的には安全性と保守性の向上を目標に、段階的な移行を進める
  • この決定が論争を呼ぶ可能性を認めつつも、Ladybirdの将来のための正しい選択だと評価している

関連記事

1件のコメント

 
GN⁺ 2026-02-24
Hacker Newsのコメント

  • このプロジェクトでバイト単位で同一の出力を求めた点が、いちばん賢い部分だと思う
    そのおかげで既存パイプラインと新パイプラインを並行して動かして diff を比較でき、変換中に生じたバグを即座に見つけられる
    多くのリライトが失敗するのは、人々が移植中に「改善」を試みて、旧版・新版、あるいは単なる動作差異から生じる幽霊バグを追いかけることになるからだ
    Rust への C++ 翻訳版が最初は不自然に見えても問題ない。あとで C++ 側を完全に退役させれば、段階的にもっとidiomaticにしていける

    • 移植は多くのものを改善するには良いタイミングだが、新機能を追加するタイミングではない
      出力が同一に保たれる限り、リファクタリング、効率化、ドキュメント化はできる
      コードを読みながら文書化するのが最良のタイミングだと思う。Ladybird のような人気プロジェクトでは、ドキュメント化こそ開発速度を上げる方法だ
    • こういう純粋な移植がもっと増えてほしい
      以前は移行コストが高すぎて、「どうせやるなら改善もしよう」という形で正当化していたが、結局は幽霊バグをより多く追うことになった
    • このアプローチは本当に気に入っている。数日前にテストと検証の観点から書かれた記事を読んだが、こういう複雑なプロジェクトに適用されたのを見て驚いた
    • 自分も Web フレームワークをこういう形で何度も変換したことがある。HTTP 出力文字列が完全に一致するように新コード側で合わせてから、旧版を完全削除した
    • 良いテストスイートがあれば、このアプローチははるかにうまく機能する。Ladybird にもそれがあるはずだと思う

  • Claude Code と Codex を使って C++ コードを Rust に翻訳した
    完全自動ではなく、人間が直接方向を定め、数百の小さなプロンプトで調整した
    2つのパイプラインの出力がバイト単位で同一でなければならないという要件を最初から設定し、その結果、2週間で 25,000 行の Rust コードが完成した
    AST とバイトコードはどちらも一致し、リグレッション 0 件を達成した
    こういうやり方こそ、言語間ポーティングに AI を使う正しい方法だと思う

    • 自分も以前、壊れた Perl スクリプトを Claude で Rust に移したことがある
      80 分で Drupal 構造を解析し、元の設計とモジュール構造をそのまま復元しつつ、カスタムプラグインまで実装した
      今ではそのサイトは WordPress、ProcessWire、Node.js、そして今や Next.js にまで移されたという話だ
    • AI 企業がこうした協調型の使い方に集中しないのが残念だ
      自分が欲しいのは「1回のプロンプトで完成したコード」ではなく、AI と長いセッションをやり取りしながら**人間の知能を増幅する（IA）**ツールだ
      ただ、こういうツールは開発知識のある人しか使えないので、市場は小さいのかもしれない
    • 自分も Rust を学びながら Claude に「teach」というスキルを作って使っている
      Claude はコードを直接書かず、ヒントだけを出してレビューだけする
      Rust は言語特性上、その場の勢いで書きにくいが、このやり方には非常に満足している
    • 自分も Claude をこう使っている。「AI が全部やってくれる」ではなく、設計、レビュー、テストを一緒に進めるパートナーとして使っている
    • 以前作った複雑な bash スクリプトを Claude で golang に移したが、速度と安定性がものすごく改善した
      今ではブラウザでも動く wasm 版まである
      暗号関連の部分は自分で実装していないので、その点は心配しなくてよい

  • Rust への移行の話は興味深いが、Ladybird チームは以前は**「anti-Rust hype」**寄りだったので驚いた
    それでも Rust に移れば、自分が貢献するのはずっと簡単になりそうだ

    • 自分も Rust は好きだが、言語への過度な熱狂はときどき疲れる
      言語はただの道具であって、特定の言語にアイデンティティを賭ける必要はないと思う
    • Rust は好きではないが、実用面では最善の選択になることはある
    • Ladybird はもう C++/Swift 中心ではないというリンクがある
    • 言語方針が頻繁に変わるのは少し不安だ。プロジェクトの継続性が揺らぐ可能性がある

  • Andreas は優れたエンジニアであり、起業家的な感覚もある人物だ
    趣味プロジェクトを産業的なプロジェクトへ発展させたのは印象的だ
    ただ、こうした急速な言語転換は少し不安に感じる

    • Andreas は単なるビジネスマンではなく、Serenity OS を何年も一人で作ってきたエンジニアだ
      プロジェクトが自然に成長した結果だと見ている
    • Swift の決定も、複数の言語を直接試したうえで下した合理的な判断だったという
    • ちなみに彼は以前、Apple Safari エンジンチームで働いていた
    • それでも、これが本当に新しいブラウザにつながるのかはまだ疑問だ
    • 「不安だ」と言っていたが、具体的に何が不安なのか気になる

  • 「非慣用的な Rust コードだが後で整理する」という言葉が、別のリライトを示唆しているようで心配だ
    スタートアップが言語を変えるのは、しばしば危険信号に見える

    • それでも C++ と Rust はどちらもマルチパラダイム言語なので、構造を似た形で移せる
    • Joel on Software が語った「リライトの罠」を思い出す
      新版の開発と既存機能の開発が並行すると速度競争が起き、新版が追いつけない可能性がある
    • ただし Ladybird はスタートアップではなくオープンプロジェクトなので、比較は異なる
      Linux や PHP、musl libc も何度も全面リライトを経験している
    • 自分ならこういう状況では、ただ Firefox を使い続けると思う
    • LLM で数週間かけて移植するのは、やや奇妙な選択にも見える

  • AI が一般化した今では、「新しい言語への全面リライト」の計算式は完全に変わった
    特にテストスイートがあるなら、リスクははるかに小さくなる
    テストの重要性が10倍になった時代だ

    • 自分も個人プロジェクトで AI を使って Python CLI ライブラリを作った
      Streamlit、Shiny、Dash など多様な UI をすばやく試せるので、プロトタイピングが楽しい
    • 長期的には、AI の進化によってプログラミング言語そのものの意味は薄れていく気がする
      すでに一部のプロジェクトでは、low-code + agent の組み合わせで十分動いている

  • 「AI にコードレビューを任せた」という部分は不安に聞こえる
    モデルには論理的な誤りを見抜く限界がある

    • それでも結果として 65,000 件のテストでリグレッション 0 + 同一出力を達成したなら、完全には無視できない
      ただし後で「整理（cleanup）」が本当に行われるかが鍵だ
    • 人間のレビュアーも完璧ではない。複数の視点でレビューすれば、AI でも人でも異なる誤りを見つけられる
    • こうした部分はテストスイートが検証すべき領域だ
    • ただ、AI が作った非慣用的な Rust コードを扱いたくないという人もいる
      AI コードに依存すると、徐々にAI 依存が強まる悪循環が生まれる

  • プロジェクトが C++ と Rust を並行開発している点は非効率に見える
    いっそメモリ安全な言語ひとつに統一したほうがよいのではと思う

    • しかし Firefox のように混在コードベースでも十分可能だ
      各コンポーネントが1つの言語だけで書かれていれば問題ない
    • 完全移行を試みるとモメンタムの損失が大きく、プロジェクトが止まる可能性がある
    • C++ の厳格なサブセットを使えば、メモリ安全性を確保することもできる

  • 2024 年に Swift を採用した際、Andreas が Rust についてツイートしていた内容がある
    Rust は短時間で終わるプログラムには素晴らしいが、複雑なオブジェクトグラフを維持する長時間稼働プログラムには不便だとしていた
    コミュニティが有害だという評価も付け加えていた
    関連ツイートのリンク

    • 彼は考えを変えたのだろうか？ そもそも最初から C++ を置き換える必要があったのかもしれない
    • Rust コミュニティの排他的な雰囲気に共感する
    • おそらくスポンサーの要求で AI ベースの Rust 移行を進めた可能性もある

  • 非慣用的な Rust コードが後に技術的負債として残るのか気になる

    • リスクは主に整理段階にある。C++ 的なポインタパターンが Rust の所有権ルールと衝突する可能性がある
      Servo プロジェクトもこうした問題を経験したが、その過程で潜在バグを見つけることができた
    • C++ 自体に問題があったわけではなく、Rust に移した理由はメモリ安全性のためだ
    • Andreas は以前から JS ランタイムのGC 安全性の問題に言及し、より安全な言語を求めていた
      Rust への移行は、その哲学に合った成熟した選択に見える