概要
- Ruby on Rails の創始者DHHが Campfire Once を複数言語（Rust, Elixir, Go）でAIリライト
- 各言語リライトで 非互換や設計の違い が発生、AIの限界が露呈
- パフォーマンス評価やベンチマーク の難しさと、単一指標の危険性を指摘
- ElixirとRustの並行処理 比較から、言語特性や設計トレードオフの重要性を解説
- 結論： 自動化やAIに頼り切るのは危険、設計判断と批判的思考が必須
DHHによるCampfire OnceのAIリライトとその問題点
- DHH が自作チャットアプリ Campfire Once を Ruby on Rails から Rust へAIエージェントでリライト
- さらに Elixir や Go でもリライトを追加
- AIによる自動リライトで 設計意図・仕様の曖昧さ が問題化
- 「後方互換性を維持するか」「レイテンシとスループットの優先度」「許容メモリ量」など
- プロンプトが具体的でないと 多くの設計判断が運任せ になる
- 実際のリライト結果では 後方互換性やRedis利用有無などがバラバラ
- Rust版は CSRFトークンを省略 しキャッシュ性を重視、 Redisを廃止 しインプロセスキュー化
- Elixir版は Rails原作に近い設計
- 言語の違いというより AIプロンプトの曖昧さ によるもの
AIリライトの品質とパフォーマンス問題
- コードを読むと パフォーマンスや設計の問題 が多発
- Elixir版は 全SQLクエリを1プロセスで逐次実行 し並列性に欠ける
- Rust版も 一部DB操作が非同期でなく、スレッドブロッキング が発生
- Rustの非同期ランタイムは 協調的スケジューリング のため、
- タスクがyieldしないと 他タスクがブロック される
- 非同期I/Oやasyncロック の適切利用が不可欠
ベンチマークとシステム設計上のトレードオフ
- ベンチマークでは 単一指標での評価の危険性 を強調
- Rust版の通知配信成功率が 高負荷時1%、Elixir版は 100%
- ただし、Rust版は より多くのリクエスト処理 （4倍）を達成
- Elixir版は 高負荷時にHTTP POSTの23%がタイムアウト
- 通知遅延 や クライアントUX についても比較
- Rust版は 遅延時にクライアント再接続で新着取得、Elixir版は 最大180秒の通知遅延
- どちらがUXとして優れているかは 一概に決められない
並行処理・メモリ管理・イベント配信の設計判断
- Rust版は tokio::sync::broadcast channel でイベント配信
- チャンネル容量（stream_capacity）を 256→16384 に増やすと配信成功率が 14%→90% に上昇
- しかし 遅延が大幅増 し、クライアント再接続戦略の方がUXとしては良い場合も
- Elixir版は GenServerのメールボックス無制限 でOOMリスク
- 100req/s時に 1.8GBメモリ使用
- 「一部の通知を落とす or OOMで全停止」どちらが良いかは 設計次第
結論：AIと自動化の限界、設計と批判的思考の重要性
- AIや自動化で全てが解決するわけではない
- 言語ごとの特性や設計トレードオフ を理解し、 失敗モードを予測 する力が不可欠
- 単一ベンチマーク指標に依存せず、複数観点で評価 する姿勢が重要
- 批判的思考と設計判断能力 の維持が、信頼性あるシステム構築の鍵