Обновить
4K+

Ruby *

Динамический высокоуровневый язык программирования

9,2
Рейтинг
Сначала показывать
Порог рейтинга

Мысли про 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 была важна именно человеку, который этот код пишет. А если код всё чаще пишет агент, то эти преимущества уже не выглядят настолько очевидными.

Теги:
+9
Комментарии4

После 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 невероятно удобными инструментами. Но теперь, когда хочется в очередной раз сделать что-то вручную, полезно задать себе вопрос:

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

Теги:
+3
Комментарии5

WebTransport: будущее потокового вещания и коммуникаций.

В сети появились интересное, как по мне, видео с конференции rubyconf2024. В нем рассказывается об эволюции веб-протоколов передачи данных, от веб-сокетов до веб-транспорта, а также грядущую спецификацию HTTP 3. Из видео можно узнать о двунаправленной потоковой передаче, дейтаграммах и потенциале веб-кодеков для потоковой передачи видео. 

Всем кому любопытно, то рекомендую к просмотру: https://youtu.be/WqYExpMWIUU?si=p4gSGHXkhHAS4LK_

Для питонистов и тем кому интересно хочу перекомендовать к прочтению статью о webtransport и библиотеке на python aioquic [habr].

Что такое веб-транспорт?

Web Transport — это новый веб-протокол, разработанный для улучшения существующих решений, таких как WebSockets и события, отправляемые сервером (SSE). Хотя Web Transport часто называют «WebSocket 2.0» из-за его расширенных возможностей, он предлагает более тонкие функции, такие как однонаправленная и двунаправленная потоковая передача, дейтаграммы и улучшенная обработка частичной надёжности. В настоящее время этот протокол поддерживается в виде черновика основными браузерами, такими как Firefox и Chrome, а вскоре его поддержка появится и в Safari.

Ключевые особенности

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

  • Дейтаграммы: в отличие от более ресурсоёмких веб-сокетов, дейтаграммы требуют меньше ресурсов и допускают потерю пакетов, что может быть преимуществом в сценариях, где надёжность не является критически важной.

  • Приоритетная обработка: особенно полезна для таких приложений, как потоковое видео, где определённые критические кадры могут иметь приоритет над другими для обеспечения более плавной работы пользователя.

Теги:
Всего голосов 3: ↑3 и ↓0+3
Комментарии0

Уж сколько раз убеждался, что ФИПС при регистрации по факту ничего не проверяет и не правит в данных от заявителя... но чтобы настолько можно было нагло проталкивать чужое ПО как свое, пользуясь ленностью ФИПСа...

Наглость - второе счастье...
Наглость - второе счастье...

Федоров Максим Владимирович - если ты это читаешь - покайся! :)

Если Jean-Philippe Lang не просматривает реестры ФИПС - это не значит, что можно так безоглядно использовать его интеллектуальную собственность.

P.S.: очень хочется узнать, как удалось уместить программу в 10КБ :))

Теги:
Всего голосов 7: ↑7 и ↓0+7
Комментарии2

26 апреля 2024 года состоялся релиз эффективной многопоточной среды обработки Kafka на Ruby и Rail проекта Karafka 2.4.

Исходный код этого инструментария опубликован на GitHub под лицензией LGPLv3.

В новой версии проекта исправлены ранее обнаруженные ошибки, а также внесены улучшения и изменения. В Karafka 2.4 прекращена поддержка Ruby 2.7 и используется инструментарий WaterDrop 2.7.

Теги:
Всего голосов 3: ↑3 и ↓0+5
Комментарии0

Перестал работать RubyGems. Пакеты теряются на магистрали Мегафона. Как до них достучаться? Какие есть рычаги воздействия?

Если начнут блокировать еще и аутлайн, то вся работа компании встанет банально из-за невозможности запустить бандл.

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии2