【速報】新興ブラウザ「Ladybird」がRustを採用！C++からの脱却で安全性と速度を両立へ

次世代の独立系ブラウザエンジンとして注目を集める「Ladybird」が、主要な開発言語としてRustを採用することを公式に決定しました。これまではC++をベースに開発が進められてきましたが、メモリ安全性の向上やモダンな開発体験を求めての大きな決断となります。ブラウザ界の新たな挑戦者がRustという武器を手に入れ、今後どのような進化を遂げるのか、エンジニア界隈でも大きな期待が寄せられています。

「結果がイディオマティックな（Rustらしい）書き方じゃないのはわかってるし、C++のパイプラインを廃止できれば簡素化できる部分はたくさんある。クリーンアップはそのうちやる」ってことだけど。

この2つの言語を知らないから間違ってたら教えてほしいんだけど、他の言語と同じで、その言語らしい書き方をするとなると、作りが劇的に変わることもあるよね。ここで言う「クリーンアップ」って言葉、かなり無理させてない？結局ゼロから完全に書き直すのと同じ意味だったりしないかな？

開発に何年もかけた後で言語を切り替えるスタートアップって、大抵はやばい兆候（レッドフラッグ）だよね。「Xで書き直してます」っていう投稿は、大体「サービス終了します」の前触れだし。まあ、彼らの幸運を祈るけど！

「翻訳にはClaude CodeとCodexを使った。これは人間が指示したもので、自律的なコード生成じゃない。何をどの順番で移植するか、Rustのコードをどう見せるかは俺が決めた。何百もの小さなプロンプトを投げて、エージェントを正しい方向に誘導したんだ。最初の翻訳の後、アドバーサリアル・レビュー（敵対的レビュー）を何度も回して、別のモデルにミスや悪いパターンがないか分析させた。
最初からの要件は、両方のパイプラインからバイト単位で同一の出力を得ることだった。結果は約2万5000行のRustコードになり、移植全体で約2週間かかった。手作業だったら数ヶ月はかかっていただろう。Rustパーサーが生成するすべてのASTがC++のものと同一であること、Rustコンパイラが生成するすべてのバイトコードがC++コンパイラの出力と同一であることを確認済みだ。全項目でデグレはゼロだ」

これこそ正解だね。コーディングアシスタントは言語間の移植に本当に役立つ。特に既存のテストがある場合は最強だよ。

長年のRustファンだけど、これにどう反応していいか正直わからない。この移行についてはもっと情報が必要だと思う。特にLadybirdの開発者たちは、かなりはっきりと「アンチRust」（というか、Rustが流行りすぎてた頃の「アンチ・ハイプ」かな）を公言してたしね。

これがうまくハマるかどうかは謎。Rustでブラウザエンジンを書くこと自体は良い（good）と思うけど、Ladybirdは今CPPやSwiftを推してるし、コントリビューターがどういうスタンスなのか全然見えないんだよね。

まあ、少なくとも俺の立場からすれば、コントリビュートはかなり楽になりそう。LadybirdへのこれまでのPRは、C++の経験がなさすぎてひどいもんだったから。正直、何やってるか自分でもわかってなかったし。

リファクタリングや「新しい言語で全部書き直す」っていうこれまでの定説は、AIがこれだけ普及した今となっては通用しなくなってる。特に、広範なテストスイートがある状況ではね。

テストの重要性は、これまでの10倍くらいになってると思うよ。

「結果がイディオマティックなRustじゃないのはわかってるし、C++のパイプラインを廃止できれば簡素化できる部分はたくさんある。クリーンアップはそのうちやる」って部分について。

これがどんな技術的負債をもたらすのか、そしてC++で抱えていた問題と引き換える価値が本当にあるのか気になるな。

Andreasは凄腕のエンジニアだけど、起業家としてはさらに手腕があるみたいだね。意図的かどうかはさておき、彼はかなり注目されるパッションプロジェクトを作り上げてリードし、多くのコントリビューターを引きつけ、その勢いを利用してLadybirdをより具体的な資金見込みのある独立した事業へと切り離すことに成功した。

Jakt -> Swift -> Rustというピボットも、別次元で同じことをやってるように見える。最初のSwiftへの変更は、間違いなく業界からのサポートを得るためだった（純粋なエンジニアリングの観点からは微妙な選択だったと思うけど）。

一人の人間が、ホビイストやハッカーの関心と貢献をレバレッジにして自分の仕事を創り出し、業界の注目やスポンサーを集めつつ、自分の好きなこと（ブラウザが彼の専門だとして）を支配的な立場でやり続けているのは、見ていて畏敬の念を覚えるよ。

うまく言語化できないけど、これらすべてに対して少し警戒心を感じる部分もある。まあ、傍から見てる分には面白いんだけどね。

「最初の翻訳の後、アドバーサリアル・レビューを何度も回して、別のモデルにミスや悪いパターンを分析させた」

これってもう詰んでる気がする。結局「生成されたコードを自分ではレビューしたくないし、できない」って言ってるようなもんだし。モデルに間違いを探させる手法がうまくいった試しがない。明らかなパターンや、セキュリティミスの傾向は見つけられるだろうけど、深いロジックのエラーは見抜けないよ。

「これがプロジェクトのメインフォーカスになるわけではない。エンジニアの開発はC++で継続し、サブシステムをRustに移植するのは長期間並行して進めるサイドプロジェクトになる」

この部分はあんまり好きじゃないな。メモリ安全な言語を使うって決めて、それから新しいコードは全部Rustで書くとか、しっかりコミットしたほうがいいんじゃない？これだと二度手間になりそう。

2024年にSwiftを採用した時のTwitterの投稿から、Rustに関するコメントを引用。

Rustに対する俺の一般的な考え：

• 入力Aを出力Bに変換するような、短寿命のプログラムには最適
• 巨大で複雑なオブジェクトグラフを維持するような、長寿命のプログラムには不向き
• エコシステムは本当に素晴らしい
• コミュニティが有毒

https://xcancel.com/awesomekling/status/1822241531501162806

「バイト単位で同一の出力」を要件にしたのは、この件で一番賢いやり方だね。新旧のパイプラインを並行して動かしてdiffを取れば、翻訳のバグを即座にキャッチできる。移植の最中に「改善」しようとして、古いコードにあるのか新しいコードにあるのか、あるいは単なる挙動の違いなのかわからないような謎のバグを追いかける羽目になって、書き直しに失敗するケースがあまりにも多いからね。

あと、「C++から翻訳された」Rustコードをスタート地点にするのは全然アリ。C++側を廃止してから、少しずつイディオマティックな書き方に直していけばいいんだし。コードの書き方がちょっと変でも、Rustコンパイラはメモリ関連のバグを根こそぎ捕まえてくれる。それがそもそもRustを使う目的だしね。