So... DHH's Rust experiments have me wondering if we're optimizing the wrong layer
I've been following the discussions around DHH's AI-generated Campfire implementations, and something about the recent developments with Matz's Spinel and Ryan Lopopolo's Artichoke has me wondering whether there's a bigger opportunity we're overlooking.
DHH's argument makes sense to a point. If agents are increasingly writing the implementation, the economics of choosing a language change substantially. Rust's (✋🏻 I hate Rust btw) performance and memory efficiency become more appealing when the developer doesn't have to spend months writing and maintaining it by hand. His Campfire benchmarks certainly got my attention, although the differences in application architecture, caching, and optimization effort make them difficult to interpret as a straight language comparison.
But what if we're concentrating too much on optimizing individual applications rather than the languages and runtimes they're built on? I've been thinking this for a while and it's one of my major attractions to the V programming language (and no, it's not "V for vaporware" and no, Alex isn't a conman - he's a really genuinely good guy).
At Rails World, Matz and DHH had a fascinating discussion about all this. Matz has been actively using coding agents himself, and made the interesting observation that Ruby's conciseness, expressiveness, and enormous existing codebase are potentially advantages for AI development (which is the same thing I've been thinking and actually experiencing for years now). He also raised a concern I think deserves more attention: as agents increasingly abstract away the underlying infrastructure, who's going to care about maintaining those components?
Meanwhile, Matz is developing Spinel, which uses whole-program type inference and AOT compilation to turn supported Ruby programs into native executables. It already reports substantial performance improvements on selected benchmarks, although full dynamic Ruby compatibility remains a major limitation.
There's an even more interesting connection through Roundhouse, which analyzes Rails applications and can generate implementations targeting Rust, Go, and several other languages, including a Ruby path compiled by Spinel. Its maintainers report that Campfire itself is already running through the Spinel path, with behavioral verification against Rails. That seems particularly relevant given that Campfire is the application DHH has been using for his experiments.
Then there's Lopopolo's latest Artichoke work, which is what really got me thinking.
He's rebuilding Artichoke around a Rust-based Ruby VM with its own IR, optimizer, GC, and replaceable interpreter internals. But the particularly interesting development is lowering Rust's MIR into Artichoke's Ruby IR, allowing portions of the Rust semantic layer to execute as VM-managed frames. That potentially solves Fiber suspension across otherwise native Rust calls while also allowing optimization across the Ruby/Rust boundary.
That seems like a pretty significant architectural direction, even if it's still experimental. It suggests that the traditional separation between a language's runtime implementation and its executable application code might become much less rigid.
Now I'm wondering whether these efforts point toward something complementary rather than competing.
Could we eventually have Ruby and Rails remain the expressive, human-readable source, while increasingly sophisticated compilation and runtime machinery produces native performance wherever the semantics permit it? Whole-program optimization where possible, guarded specialization and native compilation for hot paths, and a dynamic interpreter fallback where Ruby actually needs one?
Obviously there are substantial problems here. Ruby's open classes, runtime method replacement, eval, C-extension compatibility, deoptimization, and the actual cost of preserving dynamic semantics aren't going to disappear through better code generation. And translating Rust MIR into VM bytecode doesn't automatically give you native Rust performance.
Still, if AI agents make it economical to undertake massive Rust rewrites of individual applications, shouldn't they also make much more ambitious compiler and runtime engineering economically practical? Well of course it would... So improvements at that level could benefit an entire ecosystem rather than one application at a time.
I'm particularly interested in what people familiar with YJIT, TruffleRuby, Spinel, Roundhouse, or Artichoke think about this though.
Are we getting closer to a world where Ruby can serve as the primary application language or behavioral specification, with multiple highly optimized execution strategies underneath it? Could some of these projects eventually complement each other?
Personally I think we're going to see this.
Where might you think the biggest obstacle actually lies: full Ruby compatibility, the difficulty of cross-language optimization, native-extension support, or simply the fact that application architecture often matters more than runtime performance?
At any rate, just curious what others are thinking in this space right now.
12 points · 1 comment
Mentions
Kaigi on Rails 2026 参加レポート はじめに ラグザイアのsisoです。 10月16日〜17日に開催されたKaigi on Rails 2026に参加しました。ラグザイアはシルバースポンサーとして協賛しました！ 今年は日英の同時字幕が導入されて、英語のセッションを見るハードルがぐっと下がったように感じました。運営の方々に感謝です。 印象に残ったセッション Keynote: I Want Both まつもとゆきひろ（Matz）さんのキーノートでは、開発されているSpinel（RubyのAOTコンパイラ）のお話が特に印象に残りました。 Railsはメタプログラミングを多用しているため、そのままではSpinelでコンパイルできません。そこで、Roundhouseで静的なRubyコードにトランスパイルすることで、コンパイルが可能になったとのことです。アプリのある時点のスナップショットとして変換するので、動的な実装が不要になるということなのかなと理解しました。 現状はコンパイルの時間に課題があるようですが、Rubyの書きやすさ（読みやすさ）と実行速度を両取りできるならめちゃくちゃ嬉しいなと思います。 Spinelでコンパイルする前提のメタプログラミング無しのフレームワークがあったら良いというようなお話もされていて、AIがある今なら（機能を絞れば）実装できるかもしれないと思いながら聞いていました。ActiveRecordあたりが鬼門になりそうな気がしていますが、非常に面白い題材だと思いました。 現場と育てるRailsモデリング 〜Spreadsheetから始めたモデル設計〜 speakerdeck.com 拠点ごとに独自フォーマットで運用されていたスプレッドシートをRailsアプリ化したというお話でした。いきなり自社のRailsアプリに新機能として追加するのではなく、まずは全拠点共通のスプレッドシートフォーマットを作成して配布するところから始め、その運用の中で見えてきた課題を踏まえて機能追加したとのこと。 統一スプレッドシートの運用をしていく中で、「エンジニアと現場の言葉が一致してきた」とおっしゃっていたのが印象的でした。ユビキタス言語じゃないですが、現場の方と開発者がコミュニケーションを取る上で用語の統一って大事なんだなとあらためて思いました。 Event is what happens speakerdeck.com Rails 8.1で追加されたStructured Event Reportingについてのお話でした。 イベントエンティティに関しての理解が浅かったので、Kaigi on Rails 2023の発表もあらためて見て、ようやくStructured Event Reportingと本発表におけるイベントが理解できたような気がします。 発表の最後にも少し触れられていましたが、手でコードを書く機会がだいぶ減った中で、現実世界の課題をコードに落とし込むための理論構築は、自分自身で考え続けないといけないなと思いました。 真のREST 2026 tkawa.github.io 真のREST APIのクライアントとしてAIエージェントが登場したというような内容の発表でした。 「ハイパーメディアがないとRESTではない」ということを話されていて、私は「REST = リソース設計」くらいの認識だったので、再度勉強しなおさないといけないなと思いました。 少なくとも私自身が開発しているAPIにはハイパーメディアがほぼありませんが、AIエージェントからの利用を想定するならリンクを付けるのはアリかもと思いました。 作れる、でも消せるか？──安全に「枯らして消す」機能削除術 speakerdeck.com リリース済みの機能をどうやって消すかというお話でした。 リリースしたけどあんまり使われていない機能って消すのは大変ですが、消さないと負債になるから悩みどころだなと思いながら聞いていました。 誰からも使われない状態にすることを「枯らす」と表現するのはおもしろいと思いました。 また、枯らす手段として開発側で確実にコントロールできるところから変えていくとお話されていました。私自身はWebアプリケーションの開発がメインなので、「スマホアプリだと更新後のアプリがすぐに使われるとは限らない」という話には「確かに...！」となりました。 おわりに 今年は去年と比べてもAI関連の話題がかなり増えた印象でした。 色々なところで言われていることではありますが、作ることが容易になった今だからこそ、対象のドメインを理解してモデルを構築することがより重要になるのだとあらためて感じました。 また、RESTの話がまさにそうですが、設計を考える上での基礎知識もまだまだ足りていないと感じたので、勉強していきたいと思います。 来年は東京ビッグサイトで開催されるようですね。向こう一年でどのくらい変化があるのか、今から楽しみです。
Railsのレスポンスを60倍速くする方法 この記事を書こうと思った背景 先月、「Kaigi on Rails」という国内最大のRuby on Railsのイベントが渋谷で開かれました。 kaigionrails.org この中で、2日目に登壇したRubyの産みの親 Matzさんのプレゼンで、 「（衰退していると言われがちな）Rubyの未来が実は明るいんじゃないか」 と思わされたので、共有させていただきたいなと思います。 動画はYouTubeで見れます。 youtube.com Matzのプレゼンの概要 AIがコードを書く時代において、 「人間に優しい言語」は「AIにも優しい」 という仮説 Rubyは開発効率が非常に高い ものの、実行効率やメモリ消費量においてコンパイラ言語に後れを取ることがある 開発中の Spinel（スピネル）プロジェクト の紹介: Rubyの実行効率やメモリ消費量の課題を解決するためのAOT（Ahead-Of-Time）コンパイラで、開発時はインタプリタ、出荷時はコンパイルしてバイナリ化することで、高速かつ省メモリな実行を目指す Roundhouse: Railsアプリをメタプログラミングに依存しない形へ静的解析・変換し、Rust・Go・TypeScript・C#・Elixir・Pythonなど他言語のプロジェクトや、Spinelでコンパイル可能なRubyプロジェクトとして出力するトランスパイラ。Spinel向けの出力をバイナリ化すると、ビジネスアプリの高速化と省メモリ化ができる 端的にいうと、 Rubyをコンパイルしてバイナリ化することで、極限までパフォーマンスを高められるのではないか、ということです。 プレゼンタイトルの「I Want Both」は、 「Rubyの人間に優しい書き味」と「（C言語やRustのような）低レイヤーの高パフォーマンス」の両方が欲しい、という意味だと解釈しました。 rubys/roundhouse matz/spinel Railsアプリをコンパイルして、バイナリ出力してみよう Rubyをコンパイルできるなら、当然Railsでもコンパイルできるよね？ってことで、 どれぐらいパフォーマンスが上がるか計測してみます。 大まかな流れは以下の通り。 通常通り、rails newからプロジェクトを作成し、Webアプリを開発する。 roundhouseで変換、Rails独特のメタプログラミングに依存した表現を、静的に解析できるRubyコードへ変換して出力。 出力されたRubyコードを SpinelがC言語に変換し、ネイティブバイナリにする。 コマンドにするとこんな形です。 0. roundhouseとSpinelを用意する（spinelとspinにPATHを通しておく） roundhouse: リリースのインストーラ、または cargo install --git rubys/roundhouse --bin roundhouse Spinel: cloneして make deps && make && sudo make install Cツールチェーンと libsqlite3-dev / libjemalloc-dev、sqlite3コマンドも必要 1. Railsアプリを作る（中身はscaffoldで1機能あれば十分） rails new blog --minimal --skip-test --skip-system-test cd blog bin/rails generate scaffold Post title:string body:text bin/rails db:migrate config/routes.rb に root を書く（無いとバイナリが起動しない） root "posts#index" 2. メタプログラミングが残っていないかチェック roundhouse check --continue . 3. Spinel向けのRubyコードに変換（out/spinel に出力される） roundhouse --target spinel -o out/spinel . 4. アセットを用意して、Cを経由してバイナリ化 cd out/spinel bundle install make assets make build 5. DBを用意して起動 make seed ./build/bin/blog # localhost 他の言語と比較してみた AIエージェントに、 同じVPS・同時接続8（wrk -c8）・20秒 で、同じ画面を返すアプリを各言語で動かして比べさせました。 私の危険思想がもろに入った AIエージェントが実行した結果なので、あまり真に受けないでください。 実装 RPS レイテンシ メモリ 補足 Rustネイティブ 18,565 0.43ms 約6MB 速さも軽さも1位 Java 12,192 0.93ms 約147MB 速いが重い Railsバイナリ（Spinel） 10,967 12.9ms（テール） 約22MB テールが荒い TypeScript 8,796 0.94ms 約190MB tsx（開発実行）での計測で、本番ビルドではない Goネイティブ 8,691 1.01ms 約22MB Python 3,918 2.04ms 約48MB Ruby emit / C# 3,094 約3ms 70〜150MB 2つが同水準 Phoenix 278 28.7ms 約111MB 参考値。この構成では他言語より大幅に低い Rails開発モード 179 45ms 約124MB 比較の基準 比較から外したものが2つあります。C・C++はWebのscaffold文化がなく、比較対象を作れないので見送りました。 Rails開発モードの179 RPSに対して、バイナリは10,967 RPSなので 約61倍 です。 「RubyやRailsって遅いよね」って声を黙らせるには十分な結果 じゃないでしょうか？ 計測条件と注意点 負荷は wrk で、スレッド2・同時接続8（wrk -c8）・20秒です。 全条件を同じVPS上で測っており、ホストのスペックは全行で同一です。別のマシンや別の同時接続数に、そのまま当てはまる数字ではありません。 Railsの179 RPSは開発モードの値です。productionモードやチューニング後のRailsとは別物なので、Railsの実力として読まないでください。 Java・C#・TypeScript・Python・Ruby emitは、同じ画面を返す実装を各言語で用意しています。フレームワークやORMの選定まで揃っているかは、確認できていません。 レイテンシは行によって基準が異なります。Railsバイナリの12.9msはテールの値で、他は平均値です。行をまたいだ比較はしないでください。 メモリは各プロセスの使用量で、測定方法（RSSなど）まで揃っているかは確認できていません。 Ruby emitは、roundhouseのrubyターゲットとして出力したRuby実装を指します。 roundhouseとSpinelはいずれも 開発途上 で、リリースは日付タグのスナップショットです。バージョンによって大きく結果が異なる可能性があります。 個人的感想 「AIが実装とレビューするから人間はコードを見なくていい」はまだ暴論 だと思うので、Rubyにはまだ期待していたい（願望） 少しでも動的なコードやGemがRailsプロジェクトに入ると、roundhouseの解析が通らないので、 実用性はまだまだない。 素のRailsでちょっと遊ぶぐらいのレベルなので、技術としては面白いが実際のビジネスで生かすのはまだまだ先になりそう。 そもそもRailsが遅いって言えるぐらい事業をスケールしてみたい。 DHHは俺を見捨てないでくれ 他にはこんな記事書いてます zenn.dev zenn.dev
[The alias settling pass leaves a subclass that resolves the name through its own ancestor's alias by amatsuda · Pull Request #10000 · matz/spinel](spinel#10000) 1万だ
Truffle is very good. Could also use Matz's Spinel Ruby compiler. That's Ruby with static types using RBS but you have to give up some metaprogramming to get it. I love the idea that we could get ractors written with Spinel and compiled ahead of time. I also love the idea that I can use Ruby for self contained binary tools. (And for the sake of avoiding confusion, Crystal is also a great project. I'm really pleased to see them continue making progress). matz/spinel
Kaigi on Rails 2026 参加レポート クロステックマネジメントでは、各種テックカンファレンス（Go Conference、YAPC など）にスポンサーとして参加しています。今回は一参加者として Kaigi on Rails 2026（10/16〜17）に参加しました。 聴講したセッションの中から、DHH 氏とまつもとゆきひろさんのキーノート、松田明さんの発表が印象に残ったので紹介します。 Where the tracks go next（David Heinemeier Hansson 氏） kaigionrails.org Rails 開発者の精神は別の場所でも活かせる。コードを読み書きしなくなった世界へ進む、それがタイトルの “Next” を指しているのだと理解しました。 中でも「Rubyist を別のエコシステムに送り込めば、そこが Ruby になる」や「手で書く Ruby が減っても Rubyist でいられる」という主張に、その印象を強く受けました。 彼が最近アクティブに開発している Omarchy（Linux on Rails）も、その例だそうです。たしかに、美しいセットアップと最初からすべてが動くことを目指す Omarchy のコンセプトは、15分でブログを構築するデモをしていた初期の Rails のようです。 Rails World 2026 での発表と比べると、今回はコードを書かなくなるだけでなく、読まなくなることにも主眼が置かれていたように思います。 ほかにも、DRY や SOLID 原則は AI がコードを読み書きするようになった時代には見直せるのでは、という提起もされていました。つまり、変更コストがゼロに近づくほど、途中で大きく変わりうる、より柔軟な設計原則に移り変わる可能性もあると受け取りました。トークの中では、アーキテクチャが「コンクリート」から「粘土」のようになるというたとえが出てきました。 I want both（まつもとゆきひろさん） kaigionrails.org タイトルの “I want both” には「開発効率も実行効率も両方欲しい」という意図があり、Rails World 2026 での DHH 氏の講演が「AI が書くなら、より実行速度の速い Rust でいい」と受け取られたことへのアンサーです。 「人間に優しい言語は AI にも優しい」として、mame（遠藤）さんのベンチマークプロジェクトが挙げられました。Claude Code で簡易版 Git（mini-git）を複数の言語で実装させ、時間・コスト・行数を測ったものです。 zenn.dev （注：この時点では Ruby・Python・JavaScript などの動的言語のほうが、完了時間もコストも少なかったものの、最新のモデルでは差がなくなってきているという補足もされていました） Ruby で安価に速くコードが書けるのなら、実行速度の問題さえ改善できれば、Rust のような速度を理由にしたリライトをしなくてもよくなるのでは、という着想が Spinel です。Spinel は Ruby のコードを解析して C に変換し、ネイティブバイナリにコンパイルする AOT コンパイラです。コンパイルされたバイナリは Ruby の実行環境なしで動かせます。ただし、eval などの動的な機能には制約があり、既存の Rails アプリをそのままコンパイルできる段階ではありません。 そこで、Sam Ruby さんが開発している、Rails アプリを他言語などへ変換するトランスパイラ Roundhouse を一度通して、メタプログラミングを展開した Spinel 互換の Ruby にするというアプローチが紹介されました。素朴に見ると、Ruby を入力して別の Ruby が出力されるという構図になっているのが面白いです。 Web Framework Benchmark Battle 2026, Any%（松田明さん） speakerdeck.com これに関連する発表が、松田（amatsuda）さんのトークです。当初のプロポーザルは Rails 本体の最適化に関する内容だったようですが、Rails World 2026 の後に、Rails を Spinel で動かすためのグルーライブラリ Pines の開発記に急遽変更したそうです。 こちらのインパクトに気を取られがちですが、前半で語られた結果も驚きでした。松田さんの手元にあった、アロケーション削減などの地道な高速化のブランチ（パッチ）を Claude に与えて改善案を量産させたところ、Rails 本体がさらに速くなったそうです。Rails ほど多くの手が入った OSS のコードでも、AI でメンテナーの力を増幅する余地が残っていたということだと思います。活発にアップデートされ続けているという Rails の特性もあると思いますが。 そのほかのトーク 現場と育てるRailsモデリング（Emiko Ando さん）: 現場のスプレッドシートから概念と用語を揃えてモデルを育てる。大学の教育現場のシステムのドメインと近く、参考になりました。 AIエージェントのデバッグ能力を向上させよう（rira100000000 さん）: debug gem を MCP 経由で AI に使わせる debug-mcp。デバッグフェーズでの AI 活用の話が貴重でした。 Inertia Rails: The One-Person Framework with React & Friends（Svyatoslav Kryukov さん）: React と組み合わせても Rails の良さを保つ Inertia について Domain Modeling with Vanilla Rails（Yuichi Goto さん）: 「操作」をモデルにして Fat Model に向き合う Herb in Rails 8.2（Marco Roth さん）: Rails 8.2 で ERB が HTML を理解するように（Herb） 真のREST 2026（Toru Kawamura さん）: AI エージェントとハイパーメディアの実験 The Revenge of the Cucumber（Cristian Planas さん）: AI 時代の安全網としての振る舞い仕様。Cucumber のような振る舞いの記述形式を、私たちも活用しています。 Browser Spec: HotwireをRubyでテストする（高橋征義さん）: ブラウザなしで Hotwire をテストする Dommy と「オラクル」。Lean 4 などの要素技術を AI 駆動で実践した話が参考になりました。 Solid Queue: two years on Rails（Rosa Gutierrez さん）: Solid Queue 1.0 からの2年間のアップデート内容について おわりに 運営・スタッフ・登壇者の皆さん、充実した2日間をありがとうございました。次回の Kaigi on Rails 2027 は、2027年11月26〜27日に東京ビッグサイトで開催されると発表されています。 今回は一参加者としての参加でしたが、クロステックマネジメントは今後も技術コミュニティに関わっていきます。11月の YAPC::Tokyo 2026 には Platinum Sponsor として参加する予定です。 クロステックマネジメントでは、AI 時代のソフトウェア開発に関心のあるエンジニアを募集しています。ご興味があれば、募集ページからご連絡ください。 hrmos.co wantedly.com
So... DHH's Rust experiments have me wondering if we're optimizing the wrong layer I've been following the discussions around DHH's AI-generated Campfire implementations, and something about the recent developments with Matz's Spinel and Ryan Lopopolo's Artichoke has me wondering whether there's a bigger opportunity we're overlooking. DHH's argument makes sense to a point. If agents are increasingly writing the implementation, the economics of choosing a language change substantially. Rust's (✋🏻 I hate Rust btw) performance and memory efficiency become more appealing when the developer doesn't have to spend months writing and maintaining it by hand. His Campfire benchmarks certainly got my attention, although the differences in application architecture, caching, and optimization effort make them difficult to interpret as a straight language comparison. But what if we're concentrating too much on optimizing individual applications rather than the languages and runtimes they're built on? I've been thinking this for a while and it's one of my major attractions to the V programming language (and no, it's not "V for vaporware" and no, Alex isn't a conman - he's a really genuinely good guy). At Rails World, Matz and DHH had a fascinating discussion about all this. Matz has been actively using coding agents himself, and made the interesting observation that Ruby's conciseness, expressiveness, and enormous existing codebase are potentially advantages for AI development (which is the same thing I've been thinking and actually experiencing for years now). He also raised a concern I think deserves more attention: as agents increasingly abstract away the underlying infrastructure, who's going to care about maintaining those components? Meanwhile, Matz is developing Spinel, which uses whole-program type inference and AOT compilation to turn supported Ruby programs into native executables. It already reports substantial performance improvements on selected benchmarks, although full dynamic Ruby compatibility remains a major limitation. There's an even more interesting connection through Roundhouse, which analyzes Rails applications and can generate implementations targeting Rust, Go, and several other languages, including a Ruby path compiled by Spinel. Its maintainers report that Campfire itself is already running through the Spinel path, with behavioral verification against Rails. That seems particularly relevant given that Campfire is the application DHH has been using for his experiments. Then there's Lopopolo's latest Artichoke work, which is what really got me thinking. He's rebuilding Artichoke around a Rust-based Ruby VM with its own IR, optimizer, GC, and replaceable interpreter internals. But the particularly interesting development is lowering Rust's MIR into Artichoke's Ruby IR, allowing portions of the Rust semantic layer to execute as VM-managed frames. That potentially solves Fiber suspension across otherwise native Rust calls while also allowing optimization across the Ruby/Rust boundary. That seems like a pretty significant architectural direction, even if it's still experimental. It suggests that the traditional separation between a language's runtime implementation and its executable application code might become much less rigid. Now I'm wondering whether these efforts point toward something complementary rather than competing. Could we eventually have Ruby and Rails remain the expressive, human-readable source, while increasingly sophisticated compilation and runtime machinery produces native performance wherever the semantics permit it? Whole-program optimization where possible, guarded specialization and native compilation for hot paths, and a dynamic interpreter fallback where Ruby actually needs one? Obviously there are substantial problems here. Ruby's open classes, runtime method replacement, eval, C-extension compatibility, deoptimization, and the actual cost of preserving dynamic semantics aren't going to disappear through better code generation. And translating Rust MIR into VM bytecode doesn't automatically give you native Rust performance. Still, if AI agents make it economical to undertake massive Rust rewrites of individual applications, shouldn't they also make much more ambitious compiler and runtime engineering economically practical? Well of course it would... So improvements at that level could benefit an entire ecosystem rather than one application at a time. I'm particularly interested in what people familiar with YJIT, TruffleRuby, Spinel, Roundhouse, or Artichoke think about this though. Are we getting closer to a world where Ruby can serve as the primary application language or behavioral specification, with multiple highly optimized execution strategies underneath it? Could some of these projects eventually complement each other? Personally I think we're going to see this. Where might you think the biggest obstacle actually lies: full Ruby compatibility, the difficulty of cross-language optimization, native-extension support, or simply the fact that application architecture often matters more than runtime performance? At any rate, just curious what others are thinking in this space right now.
Spinel 側... amatsuda さんだけで 300 PR 超えている #kaigionrails_magenta github.com/matz/spinel/pulls
Matzせんせいの次回作の前に今作に期待しています！ matz/spinel #kaigionrails
@yukihiro_matz merged my Windows support into Spinel and added cross compilation. Very cool! spinel#7744
spinelの制限のドキュメント見るとAIってある程度強固な固定概念に縛られているんだなと思う。 github.com/matz/spinel/blob/master/docs/limitatio… 少なくとも、method_missingや新たな変数を作らないbindingはサポートできるだろう。甘えるんじゃないよ