ルビーのワイマール時代に生きる

DHHがRailsWorldで行った基調講演については、多くのことが語られてきました。私には、それは実存的危機にある人物、しかし同時に非常にうんざりした人物の声のように聞こえました。 「もうどうでもいいんだ、君たちもそうすべきだ」というのは、自分が推進したカンファレンス、ここではケアコンフとでも呼びましょう、のヘッドライナーである時には、あまり良いメッセージではありません。 至高の指導者からのメッセージは明確でした。我々はHEYをよりパフォーマンスの高い方法で再構築し、それは素晴らしい結果をもたらした。もはやRailsは必要とも関心もない、と。 正直なところ、辛辣な真実をぶちまけてさらに喝采を浴びるよりも、もはや愛していないおもちゃを、そのコミュニティも含めて、静かに放っておけばよかったのにと思います。 しかし、ここで重要なのは、金持ちや有名人が良いものへの関心を失ったからといって、残りの我々がそれに従う義務はないということです。むしろ、それは部屋を空けてくれるのです。 🧭 私は現在、契約で仕事を受け付けています。あなたのRailsアプリをより良くするために、私を雇ってください！ 数日間、このすべてについて非常に落ち込んでいたことを認めなければなりません。AIがすべてのコードを書くようになることについてではありません。それは私にとって明らかであり、職人の世界の変化を嘆くつもりはありません。私が嘆くのは、使用法の変化であり、それは別の記事のトピックです。 LLM（大規模言語モデル）が定着し、すべての行を手で入力することがもはや持続可能ではなくなり、状況が劇的に変化したことは明白です。 私を落ち込ませたのは、Rubyのエコシステムとコミュニティに対する配慮の少なさ、そしてDavidが「単一のRaspberry Piで動かすため」という理由で、RailsとRubyの文化全体を軽蔑して捨て去ったことです。 私が実際に観察しているのは、別のことです。ルネサンスです。たとえ多くの著名なRubyistが他のスタックに移ったとしても、それらのスタックは今や探求に対してはるかにオープンであり、すべてを…ガラクタ、そう呼びましょう、を手で書く必要がなくなったからです。 7つのリトルエンディアン整数を詳細に展開するのは、特に興味深いものでも芸術的でもありません。それは単なるガラクタであり、私はそれを惜しまないでしょう。構造体のパッキングが高速化のために必要な場合を除き、その場合はいつでもアートディレクションを追加できます。 ドイツの歴史には、二つの世界大戦の間に「間奏曲」と呼ばれる興味深い時代がありました。ワイマール共和国の時代です。 それは非常に激動の時代であり、その多くは全く見栄えの良いものではありませんでした。社会的な困難、失業、信じられないほどのインフレ、劣悪な生活条件、想像しうる限り最もワイルドな運動、キャバレー、カルトの出現…しかし、そこには別のものもありました。 ワイマールドイツの「狂騒の20年代」は、信じられないほどの数の偉大で、気まぐれで、魅力的な芸術運動も生み出しました。バウハウスからベルリンのゲイキャバレー、クルト・ヴァイルからフリッツ・ラングのメトロポリスまで。それは活況を呈した時代であり、そこで現れた多くのものは今日でも評価され、大切にされています。 そしてそれは技術的なブームでもありました。ますます広がる電力の使用、近代的な医薬品の大規模展開、地下鉄、自動車…魅力的な時代でした。 私はその時代の終わりを知っています。そしていいえ、私が求めているのはその部分のアナロジーではありません。 私が求めているのはこの部分です。古い秩序は関心を失い、誰も責任を負わず、すべての人の足元で地面が揺れ動いていました。そして、まさにその時に最も興味深い仕事が作られました。 偉大な混乱、偉大な産業の変化、大人の監督なし。 聞き覚えがありますか？ そして、Rubyコミュニティは常に芸術的でした。 _why の初期の作品からそうでした。結局のところ、美学こそが多くの人々をRailsに引きつけたのです。 括弧が必要なかったこと。単語で書かれていないこと、オランダ人が発明したかのように、属性とメソッドの区別が曖昧なこと…言語の多くのことは、単に美的に素晴らしかったのです。 そして、新しいツールの豊富さとともに、エコシステムの状況を見るための正しい考え方はこうです。 José Valim @josevalim @nateberkopec に返信しています あなたは正しいですが、それは近視眼的にも感じませんか？ あなたはこれまでにない最も強力なツールを持っており、1000倍のメーカーになりました。そして、あなたのスタックを10倍良くする方法を考えられませんか？ はい、Rustは高速で、型システムはバグを捉えますが、それ以上のものがたくさんあります。 * なぜRubyを10倍速くしないのか？ * なぜRuby（そしてしたがってRails）を並行処理で本当に素晴らしいものにしないのか？ * なぜRust以上の保証を提供する、素晴らしい型システムをRubyに追加しないのか？ * なぜSQLite3をレプリケーションプロトコルとともにRailsに埋め込み、単一サーバーを超えてスタックを本当に圧縮できるようにしないのか？ * データベースプールのようなRailsの最も重要な部分のほとんどのバグを、先回りして修正するにはどうすればよいか？ はい、ActiveSearchを誰が気にするのか、しかし、エージェントにコードを吐き出させる以上の根本的な方法でスタックを改善する方法はたくさんあります。 Phoenixは依然としてプレゼンス（オンライン状態表示）を標準搭載している唯一のフレームワークです。なぜなら、それは欺瞞的に難しい問題であることが判明したからです。しかし、どういうわけかすべての問題が解決されたのですか？ 上記のいずれも行うことに興味がない人もいることは理解しています。それは構いません。しかし、少なくともそれをやりたい人たちにバトンを渡してください。 追伸：私はこれすべてを愛を込めて言っています❤️ 2026年9月26日 今日私たちがRubyでできることの数々の中で、なぜRust風のリライトを選ぶのか？ もちろん、物語はこうです。我々が持つそれらのアプリはすべて、LLMが我々のあらゆる決定、明示的または暗黙的なものを、比較テストの厳密さ（またはお茶の葉のマトリックス係数を読むこと）で翻訳しながら、加速された、不透明なSIMDの良さのバイナリブロブに魔法のように変身するでしょう。 私たちがすでに住んでいる庭を改善するために貴重なトークンを費やすのはなぜですか？地面をならして、代わりに栄光のコンクリートに置き換えることができるのに？ しかし、もちろん誰もそれをしません。 そして幸いなことに、破壊と置き換えだけが起こっているわけではありません。そうでなければ、物語はあまりにも悲しいものになるでしょう。 見てください、Rubyのランタイムと「シーン」には、技術的に「あまりにも多すぎる」というかなりの数の問題がありました。 レイアウトを持つPDFを生成するのは面倒でした。ライブラリがありませんでした。 ネイティブGUIアプリケーションを構築できなくなりました。ライブラリがありませんでした。 ネイティブGemを簡単に生成できませんでした。数百のubf_unblockとINT2FIXを絶妙な精度で説明する準備ができていない限り… これらはすべてひどい問題でした。3人のチームでさえ、それらを処理するには多すぎました。時にはそれ以上の人数でも十分ではなかったでしょう。 アプリケーションにそれらを導入する際の障壁は高かった（たとえそれらがあったとしても）、なぜならほとんどの企業ではRailsアプリのリリースサイクルはそれほど速くなかったからです。 そして多くの人々は絶望して手を投げ出し、「恐怖の呪文」を唱えました。Rubyでこのようなことをする人はもういない、と。 「恐怖の呪文」の詠唱のプレイブックは、私たちが覚えているように、「Rails開発者は採用が難しい」と唱えた直後に、Rubyを憎むすべての人がそれを正しいと確認する小さなダンスを踊るのです。 しかし、今、その方程式は劇的に変化しました。 簡単な例を挙げましょう。請求書を生成するだけでは済まない。 Rubyの典型的なひどい問題の一つは、PDF生成でした。 わずか18ヶ月前、RailsアプリからPDFファイルを生成したいRubyistは、どれも同様に魅力のないいくつかの選択肢に直面していました。 Gotenbergを実行して、ChromiumにHTMLをレンダリングさせ、それをPDFに変換する。 ローカルのChromiumを起動して同じことを行うためにFerrumを使用する。 Prawnを使用し、そのほぼ文字ごとの手動座標配置と戦う。 4年近く放置されていたwkhtmltopdfを使用し、それをビルドし、その必要な依存関係を苦労してインストールする。 Prawnは当時素晴らしかったのですが、非常に困難でした。主に、適切なメトリックやコンポーザー機能なしで、ほぼ完全な手動レイアウトを義務付けていたためです。コンポーザーとは、タイプセットされた文字を配置し、バランスを取って、指定されたブロックに収まるようにするエンジンです。時には、レイアウトをより良く見せるためにそのブロックを調整したい場合もあります。それはt