Мысли про DHH, Rails и AI в Ruby

Посмотрел выступление DHH с Rails World 2026. Ниже просто мои мысли по поводу того, что он говорил.

Никто не спорит что DHH гениальный маркетолог. Помню еще по истории когда он пересел с Mac на Linux и начал активно про него рассказывать, потом появились Omakub и Omarchy. В какой-то момент это местами звучало почти как проповедь.

С рельсой у меня сейчас похожее ощущение. DHH рассказывает, что Rails чуть ли не идеально подходит для эпохи AI: convention over configuration, мало кода, агенту проще разобраться в проекте, меньше токенов тратится, в этом есть логика. Но Надо помнить что Ruby является динамическим типизированным языком. Сам DHH статическую типизацию исторически не особо любит и, насколько я знаю, Sorbet или RBS активно не использует. Для человека отсутствие типов вполне может быть плюсом: быстрее пишешь код, не надо делать перегонять данные из одного типа в другой. Но для AI типы — это дополнительная информация. Поэтому мне не очень понятно, почему динамичность Ruby должна быть большим преимуществом именно в эпоху AI.

Но самое интересное не это. В том же выступлении DHH рассказывает, что в 37signals теперь фактически pencils down — код руками стараются почти не писать. И одновременно рассказывает, что HEY переписывают с использованием Rust. Причём, по его словам, получили огромную экономию CPU и памяти.

Сам DHH ещё говорит:

If I look at the past 21 years, over half of my work was Ruby code. This year, about 3%.

что раньше больше половины его кода было на Ruby, а в этом году что-то около 3%.

Получается довольно интересная ситуация, которая вызывает вопросики. Одно из главных преимуществ Ruby всегда было в том, что на нём очень приятно писать человеку. Синтаксис простой, код выразительный, Rails позволяет очень быстро собрать рабочий продукт. Но если код теперь в основном пишет агент, то насколько вообще важно, приятно ли человеку этот код писать?

DHH сам говорит примерно об этом же на примере Rust: смотреть на него ему не нравится, зато результат, который делает AI, нравится. И получается, что AI в каком-то смысле убирает одно из главных преимуществ Ruby. Раньше можно было сказать: да, Rust или Go быстрее, но Ruby позволяет разработчику быстрее получить результат, а теперь агент может довольно быстро написать и Rust, и Go.

При этом у тебя остаются статическая типизация, нормальная работа с многопоточностью и более предсказуемое потребление ресурсов. С Ruby всё сложнее. В MRI всё ещё есть GIL. Для обычного веба это далеко не всегда проблема, но если нужна CPU-параллельность, приходится уже думать про воркеры, дополнительные инстансы и так далее. А инфраструктура тоже стоит денег.

С Hotwire у меня похожее ощущение. Сама идея нормальная и для определённого класса приложений действительно удобная. Но DHH иногда очень хорошо умеет взять подход, который отлично работает в 37signals, и продать его так, будто именно так теперь должен писать весь интернет.

Поэтому DHH я всегда воспринимаю сразу в двух ролях. С одной стороны, это очень сильный инженер, который сделал один из самых крутых фреймворков. С другой, один из лучших маркетологов среди разработчиков. Он умеет взять своё мнение о разработке, превратить его в философию, дать ей красивую обёртку и заставить всех нас потом это обсуждать. Но после этого выступления я так и не понял, почему именно Ruby должен идеально ложиться на эпоху AI. Да, у Rails есть сильные conventions, мало шаблонного кода и агенту действительно может быть проще ориентироваться в проекте. Но при этом часть преимуществ Ruby была важна именно человеку, который этот код пишет. А если код всё чаще пишет агент, то эти преимущества уже не выглядят настолько очевидными.

После Ruby/Elixir в Go, часть 1

Когда я начал писать на Go после опыта с Ruby и Elixir, одной из самых непривычных вещей стало отсутствие консоли, в которой можно напрямую вызывать код приложения.

Для рубиста такая консоль почти универсальный пульт управления приложением(но пульт довольно опасный). Если нужно посмотреть, что происходит с конкретным пользователем, можно просто открыть консоль, найти его, вызвать нужный метод и понять, почему, например, не работает какая-то функция.

Набираешь:

bundle exec rails c

И через несколько секунд уже находишься внутри приложения и можешь работать с его кодом и данными. Только вместо кнопок у разработчика код. Надо помнить: «С большой силой приходит большая ответственность». © Дядя Бен.

Например, приходит вопрос:

Почему у этого пользователя не появился доступ к фиче?

В Rails можно открыть консоль, вызвать нужный код и довольно быстро проверить несколько гипотез. Когда я пришёл в Go, первое время постоянно хотелось сделать то же самое. Конечно, проверить код всё равно можно. Можно написать тест или небольшую программу, подключиться к базе, сделать отдельную CLI-команду под конкретный кейс, но это уже не то ощущение: «открыл приложение и начал быстро проверять гипотезы».

Ruby здесь не единственный пример. В Elixir есть интерактивная консоль IEx. Можно запустить прямо внутри неё:

iex -S mix

Благодаря возможностям Erlang VM можно даже подключаться консолью к другому запущенному узлу. И вот после Ruby и Elixir Go ощущается особенно необычно. В Ruby удобную консоль обычно даёт фреймворк. В Elixir сама платформа хорошо приспособлена к интерактивной работе с запущенной системой.

В Go это ощущается так:

Если хочешь что-то вызвать, сделай для этого нормальную точку входа.

Поначалу это раздражает. Кажется, что раньше на проверку гипотезы уходило 5–10 минут, а теперь приходится что-то дополнительно писать, но со временем я увидел в этом и другую сторону. Удобная консоль очень легко позволяет разработчику стать частью бизнес-процесса. Про эту боль я подробнее писал в статье. Также можно легко сломать продакшен.

Нет нужной кнопки в админке?

Попросим разработчика выполнить команду.

Нужно поправить состояние пользователя?

Разработчик сделает через консоль.

Для небольшого бизнеса это действительно может быть удобно. Но потом внезапно оказывается, что важная операция в продукте существует только потому, что рядом есть разработчик, который знает правильную команду. Я такой подход называю Developer as an admin panel.

В Go отсутствие такого универсального пульта начинает раздражать раньше. Если одна и та же операция повторяется, довольно быстро хочется сделать для неё CLI, скрипт, админку или нормальный API. Бизнес раньше начинает видеть ценность такого инструмента.

Я всё ещё считаю консоли в Ruby/Elixir невероятно удобными инструментами. Но теперь, когда хочется в очередной раз сделать что-то вручную, полезно задать себе вопрос:

Мне действительно не хватает консоли или не хватает нормального инструмента?