RustからRubyへ

(xlii.space)

1 ポイント投稿者 GN⁺ 21 시간 전 | 1件のコメント | WhatsAppで共有

Rust製WebアプリのクレートをRuby on Railsへ移行してみる個人プロジェクトの実験で、対象はTeraとAxumベースの14,943行のコード
既存のRust構成では、PlaywrightによるE2E、分離されたDB名前空間、モックサービス、内部APIクレートまで必要で、テストコストが高い
LLM比較ではRailsの総合点は710で、Rust/Axum/Dieselの480より高く、開発速度と単体テストのしやすさが強みと評価された
Local Qwen3.6によるワンショット変換は約30分かかり、Rubyコードは3,322行まで減ったが、まだ実行検証はされていない
Railsは標準機能と簡潔なテストが利点で、Rubyの型安全性不足はSorbetやエージェントベースの型追加で補える可能性がある

移行実験の背景

個人プロジェクトの一部であるRust製WebアプリのクレートがRuby on Railsへの移行対象として選ばれた
- プロジェクト全体は約3万行規模で、移行対象のクレートはTeraとAxumで書かれたWebアプリに近い
- 移行対象のRustコードは合計14,943行で、コンパイルには約10秒かかる
- コード自体はそれほど大きくないが、多くの依存関係を伴う構造になっている
既存のRust構成はテストコストが高い
- E2EテストにはPlaywrightの設定が必要
- モック化が難しく、分離されたデータベース名前空間とモックサービスが必要になる
- Playwrightがヘッドレスモードでアプリとやり取りするための別の内部APIクレートも必要
RubyとRuby on Railsは簡潔な代替案として検討された
- Rubyは型がないため、安定性はRustより低くなる可能性がある
- Sorbetを使えば、Rubyでも型安全性をある程度補える
複数のLLMインスタンスで複雑さ、安定性、テスト容易性などを比較した結果、Railsのスコアがより高かった
- Rust/Axum/Dieselの合計は480、Railsは710、Rails + Sorbetは695と算出された
- Railsは個人開発者への適合性90、開発速度90、単体テストのしやすさ90と高く評価された
- Rust/Axum/Dieselは安全性95、性能95と高い一方で、単体テストのしやすさ20、統合テストのしやすさ30と低く評価された
- 単純合計ベースでは、Railsアプリの方が1.47倍良い結果を出せると判断された

変換結果と検討ポイント

Local Qwen3.6で比較的小さなプロジェクトをワンショット変換した
- 変換には約30分かかった
- まだ実行していないため、実際に動作するかどうかは確認されていない
最大の変化はコード行数の減少だった
- Rustファイルの総行数: 14,943行
- Rubyファイルの総行数: 3,322行
- 行数は77%減少し、Rubyの1行はRustの約4.49行に相当する
変換されたRubyコードは、ざっと見た範囲ではクリーンで慣用的に見える
- バグの可能性は残っている
- 今後さらに綿密にレビューする予定
追加の検討ポイントは、型の補完、Railsの標準機能、テストの単純化である
- エージェントを使って型を追加すれば、型安全性の問題を緩和できる可能性がある
- Ruby/Railsは「batteries + kitchen sink included」に近く、3GiB規模のコンパイル済み依存関係より良いと評価されている
- テストははるかに簡単になると期待されている

Rubyのテスト例は、VCR.use_cassette("llm_call")でLLM呼び出しを囲み、結果サイズを検証する短い形である

  VCR.use_cassette("llm_call") do
    result = LlmClient.match(entry, data_list)
    expect(result.results.size).to eq(data_list.size)
  end

Rustのテスト例は、モックプロバイダを直接実装しなければならない、より長い形である
- Arc<RwLock<Vec<Response>>>, AtomicUsize, async_trait, tokio::test などを使う
- 応答リストと呼び出し回数を管理する MockProvider を作成し、Provider トレイトの match を実装したうえで、テストで結果と呼び出し回数を検証する
個人プロジェクトであるため思い切った選択が可能であり、RustからRubyへの移行は今後さらに綿密に検討される予定である

1件のコメント

GN⁺ 21 시간 전

Hacker Newsの反応

信じがたい話だ。「技術的にかゆいところがあって、ローカルAIが30分で作業を終わらせた。動くか確認するためにStartすら押していないが、ブログ記事は書いた……」というふうに聞こえる
- いまトップページ1位ということは、プロジェクトが実際に動かなくても構わないということだろう。読者も記事をちゃんと読んでいないはずだ
  もちろん、ボットが押し上げたのでなければ
- 2016年: 新しいJavaScriptライブラリを見てください！
  2026年: 自分で書いていない成果物を見てください！
  2036年: Cという古代ラテン語で200行を書く方法
- 「信じがたい」というより、2026年基準ではかなりありふれたことに近い
- ただし5時間はレビューしている。なので ¯\(ツ)/¯
最初は面白い記事かと思ったが、変換にLLMを使ったと出た時点で一気に興味が失せた。「これをやりたくて部下にやらせ、その話をしよう」というのに近い
実際に変換を自分でやったわけでもなく、深く考えたわけでもないのに、わざわざ読む理由が見当たらない
- 最大の問題は、筆者が検証すらしていないことだ。複数モデルを組み合わせた大きなツールで6時間かけて変換を回したあと、厄介な計算やロジックをどう処理したかを手動で確認すると、スタブやハードコードされた真が入っていることがある
  だからスモークテストだけ回すと成功したように見えるかもしれない
- さらに大きな問題は、今後のソフトウェア開発がこうなっていくことだ
  職人的なプログラミングを除けば、プログラミング言語そのものはあまり重要でなくなる
  LLMが改善するほど、結局は仕様をどの種類の言語で生成するかを決める問題になるだろう
  UMLとRUP陣営が復讐を果たしたようなものだ
- 要点はコードを自分で書いたかどうかではなく、差分を見て、おそらく最適ではない選択をしたことにある。他のコメントでも言ったように、かなり広くレビューはしている。大きなプロジェクトではないので、いくつか厄介な部分を除けば大半はWebアプリだ
  「考えていない」という評価は不当だと思う。ボタンを押してYOLOしたわけではない
  トレードオフと結果を調べたし、Rustのコード断片とRailsの違いは実際に大きく、Rustアプリのテスト容易性は2か月間考えていたテーマだった
  LLM愛好家が言うように、コンテキストが重要だ ;)
どの言語やフレームワークも、Ruby on Railsほど開発者の幸福を優先しているかはわからない
- Railsプロジェクトで働いていたときほど不幸だったことはほとんどない。サイトのバグを見つけ、表示がおかしいビューを探そうとgrepを回す。そのセクションをレンダリングするメソッド呼び出しを見つけ、メソッド名でもう一度grepすると結果が0件になる
  どこかで合成されている何かなので、どこにあるのかわからず、結局やっていた作業を止めて1時間ドキュメントを読む羽目になる。1日中Railsだけを使う人にはいいのだろうが、設定より規約は自分にとって巨大なアンチパターンだ
- ElixirやPhoenixでも似た感覚はあるが、method_missingという自分の足を撃つ装置はない
- シリコンバレー好みのコミュニティでは魅力的に見えなくても、Javaや.NETのフレームワークでもかなり満足して仕事をしてきた
  幸福が常に性能につながるわけではない。TwitterがJVMとScalaへ移る前の有名なロゴの話を思い出す
  Ruby on Railsは名声を得たが、TclベースのAOLServerやVignetteでもすでに似た体験はあった
  ポルトガルのスタートアップでも独自の派生版を作っており、創業者たちはのちにOutSystemsを作った。これはWebサイトと分散システム開発のための初期のグラフィカルRADツールの一つで、ローコード/ノーコードでJVMまたはCLRインフラを対象にしていた
  それでも今やCRubyにJITが標準で入っているのを見るのはうれしい
- せいぜい短期的な幸福で、保守性・性能・信頼性・拡張性など、他のあらゆるアーキテクチャ特性を代償にしているに近い
すでに簡潔なRuby on Railsコードをさらに極端に押し進める propel_rails というgem群を作った。APIコントローラやconcernのような最上位クラスを生成し、そこから完全なRESTfulリソース（モデル、コントローラ、シリアライザ、単体テストとE2Eテスト）をボイラープレートゼロで生み出す
コントローラは最終的にAPIが許可する属性一覧だけを持つことになる。RESTfulアクションは自動生成されるからだ。完全に説明するのは少し難しいが、Rubyのメタプログラミングの力は本当に驚くようなことを簡単にしてくれる
- これはCRUDを洗練した形のように聞こえる
  ドメインモデル基準で動くと考えていい？
- rubygemsでは見つかるが、そこからリンクされているGitHubは404になる
かなり似た状況にある
GoとRustが好きで、どちらも長所と短所を持つ素晴らしい言語だ。だが残念ながら、そのどちらでもSaaSアプリを作るには至らなかった。四角い杭を丸い穴に入れる感じだ
自分が大きく間違っているのかもしれないが、SaaSツールには付随する仕掛けが多く、それを一から発明したくはない
RoRは「十分に良い」。必要なら型も導入できるし、素早く作れて、ツールも悪くない
最初の実務はPHPだったが、落とし穴が多すぎた。Rubyはもう少しEコマース寄りに見えて興味深かったし、Shopifyで十分なら悪くないと思う
RustからRubyに切り替えても筋が通る状況なら、最初にRustを選んだことが間違いだったということだ
- この記事をとてもよく要約しているし、共有しようと思った理由でもある
RubyがRustより遅いと思っている人は、Rubyが今では実際にはPythonより速く、GoやRustよりは遅いと知ったら驚くだろう
- たいていは速度よりメモリ使用量の方が重要だった。大半のRubyアプリケーションはRubyではなくデータベースがボトルネックになっている
  だがバックグラウンドワーカーが何本もあり、それぞれが2GB以上のメモリを食い始めると、すぐ積み上がる
  本番のRustサービスを1つ書いたが、速度以上に印象的だったのは、そのサービスが30MBのメモリで動いていたことだ
- RubyがRustより遅いと思う人が、なぜPythonより速いという事実に驚くべきなのかわからない。両者に何の関係があるんだ？
刺激的な言い方だが、周囲の平民に900超のIQを見せつけるにはいいのかもしれない一方で、賢く才能ある開発者の多くはRustをあまり好きではない。Rustを1行書くくらいなら、自分のプログラミング言語とコンパイラを自作する方を選ぶ人すらいる
Jonathan BlowのJaiやGinger BillのOdinを思い出す
広く使われる美しいライブラリやフレームワークを作ってきた、創造性と深さが証明された人はもっと多いが、ここで紙幅を使いたくはない
ただRustにはすばらしいマッチョクラブ、そして結束の強い兄弟団がある
- Rustコミュニティは「マッチョクラブ」とはできる限り縁遠い方だ
ClaudeはRailsアプリで本当にうまく動く。この記事の筆者も指摘しているように、Rubyは少ないコードで多くのことをこなせて、Railsは設定より規約を採るので、Railsアプリはさらに簡潔になる
ClaudeがRailsアプリをうまく書ける理由の一つの仮説は、トークン効率だ
以前、プロジェクトごとのトークン効率を測って比較しようとするこのプロジェクトを見たが、Railsはかなり良い結果を出していた
https://felipemrvieira.github.io/SyntaxTax/dashboard/
プロジェクトの規模を見ると時々驚く。3万行のコードベースが小さいのか？上限が高いのはわかるが、3万行あれば膨大な情報と動作上の微妙さを含められる
もしかすると、Goを使うバックエンド/ネットワーク寄りの仕事に集中してきた自分の背景のせいかもしれない。1万〜1万5000行を超えると、たいていコードベース全体のモデルを頭の中に保つのが難しくなり、かなり負担だった
- 何を作るかに大きく依存する。複数のフロントエンドを持つSaaSアプリなら3万行には簡単に到達する

RustからRubyへ

移行実験の背景

変換結果と検討ポイント

関連記事

1件のコメント

Hacker Newsの反応