Hacker News Digest

Автор архивирует исходный код своих Ruby-библиотек, чтобы ясно показать: он больше не работает над ними. Причина — смена самой природы сообщества Ruby. Юкихиро Мацумото, создатель языка, в 2000 году писал, что цель жизни — радость, а программисты чувствуют её, когда могут сосредоточиться на творчестве, поэтому Ruby создавался, чтобы делать программистов счастливыми. В интервью 2019 года он повторял: «Я проектировал Ruby для людей, а не для машин». Именно в ту эпоху, когда язык был ради радости и людей, автор и написал свои библиотеки.

Теперь, по его мнению, эта эпоха прошла. Главное применение Ruby — веб-фреймворк Rails, который, будучи открытым, контролируется человеком, чьи взгляды автор считает отвратительными; есть попытки сделать форк. Судя по докладу на Rails World, этот человек уже не особенно интересуется ни Ruby, ни Rails, ни программированием: он генерирует приложения на Rust с помощью агентов на базе больших языковых моделей и даже не смотрит на результат. Сам язык Ruby теперь существенно развивается с помощью таких агентов, а Мацумото продвигает его как «язык программирования для эпохи ИИ», который должны порождать модели, для чего им нужно поглощать больше хорошего кода, написанного людьми.

Автор не хочет больше вносить вклад в общее достояние, которое крупные корпорации вычерпывают, чтобы кормить машины, чей бездумный вывод его же и загрязняет. Он уходит.

Реакции на автоматизацию кода разделились. Большинство считает, что LLM убивают радость от программирования и разрушают взаимодействие в открытых проектах, что ведет к утечке талантов и дестабилизации экосистем. В сообществе Ruby это проявляется в росте числа уходящих из профессии разработчиков. Другие видят в AI полезного помощника, который освобождает от рутины для решения сложных задач. Рекомендуют использовать его как «24/7 junior engineer» при строгом контроле кода или для автоматизации (например, в переводах). Отмечаются проблемы с поддержкой open source: отсутствие обратной связи от мейнтейнеров вызывает разочарование, из-за чего некоторые советуют архивировать репозитории. Также существует риск роста «vendored forks» из-за AI-кода, что может усложнить совместимость и привести к коллапсу инфраструктуры.

Дэвид Хайнемайер Ханссон объявил, что отошёл от профессионального программирования и теперь позиционирует себя как «мейкер», веря, что английский язык стал лучшим языком программирования благодаря LLM, а чтение сгенерированного кода больше не требуется. Он утверждает, что ручное написание кода перестало быть экономически продуктивным для большинства программистов, и что 37signals переписывают Hey на нативные приложения с использованием Rust на серверной стороне — языка, который он считает «ужасным» для людей, но идеальным для LLM, поскольку он не читает код anyway. За август он насгенерировал 150 тыс. строк кода (в основном «словного» Rust), тогда как раньше писал около 30 тыс. в год, и доля Ruby в его работе упала с 50% до 3%. Его видение: к концу года LLMs будут доминировать во всех сферах, а люди будут читать код лишь исключительно, как ошибку в Sentry. Он также хочет, чтобы у каждого сервиса был CLI для взаимодействия через агентов. На Rails World 2026 он использовал ключевую речь, чтобы объявить, что флагманское Rails-приложение Hey покидает фреймворк, хотя и отметил, что Rails остаётся хорошим для веб-приложений и разработки с ИИ. Однако его аргументы сводились к тому, что Rails был лишь временным обходным манёвром, а теперь его роль сведена к «веб-приложениям по необходимости», а «конвенция над конфигурацией» переосмыслена как «эффективность токенов». Критик отмечает отсутствие чёткой стратегии для Rails, заменённую оптимизмом без фактической основы, и выражает разочарование тем, что вместо обсуждения будущего Rails DHH предложил лишь веру в ИИ и отверг скептицизм как «чёрную таблетку для неудачников».

Rails не умирает из-за технологий, а из-за ухода DHH. Многие разработчики продолжают использовать его для CRUD- и LoB-приложений в 2026 году благодаря сильным конвенциям, упрощающим поддержку, даже если LLM генерирует большую часть кода. LLM-генерация делает производительность Ruby менее критичной, так как разработчики фокусируются на проверке и доработке сгенерированного кода. Один разработчик отмечает, что 90% его 25k строк продакшн-кода и тестов генерируются LLM — код надежен, легко расширяем и требует меньшего ручного вмешательства. SRE предупреждают, что если LLM генерирует код быстрее, чем человек его читает, чтение становится необязательным, что ставит под вопрос понимание системы на уровне инженеров. Производительность Rails (80–100 мс на запрос) остаётся приемлемой для большинства бизнес-приложений, и миграция не мотивирована скоростью, а удобством разработки. Компании не переходят на другие стеки из-за производительности, а из-за усталости от устаревших инструментов и отсутствия развития экосистемы без DHH. Критики утверждают, что DHH, как BDFL, не передал управление, что привело к фрагментации сообщества и необходимости форка — это системная проблема, а не техническая. Некоторые считают, что переход на нативные приложения или CLI-агенты — ответ на ограничения веб-фиделити, а не на устаревание Rails. LLM не генерируют код в WASM или нативной сборке, а используют высокоуровневые языки, значит, они ускоряют разработку фреймворков, а не заменяют их. Исторически Rails решал проблему медленной разработки в 2000-х — теперь эта проблема решена LLM, и фреймворки перестают быть конкурентным преимуществом, а становятся инструментом. Разработчики, ушедшие от Ruby, рекомендуют Kotlin+http4k как альтернативу: он сохраняет стиль Ruby с типизацией, поддерживает функциональный подход и лучше интегрируется с агентными системами.

DHH открыл Rails World 2026 с провокационным заявлением: 37signals полностью прекратил ручную разработку кода, перейдя на AI-агентов для генерации всего — от UI до бэкенда. Он утверждает, что Rails с его принципом «конвенция над конфигурацией» идеально подходит для эпохи агентов: предсказуемая структура позволяет ИИ эффективно генерировать код без лишних решений. Вместо оптимизации под человеческие ограничения, теперь нужно проектировать под возможности ИИ — и Rails уже готов к этому.

Он призывает сообщество отказаться от страха перед автоматизацией и принять «полный оптимизм»: если ИИ может писать 90% кода, то разработчики должны сосредоточиться на творческих задачах — архитектуре, пользовательском опыте и интеграции. DHH подчеркивает, что Rails не устарел, а стал мощнее: его простота теперь — не ограничение, а ускоритель для ИИ. В будущем, по его мнению, разработчики будут управлять агентами, а не писать строки кода вручную.

Переход 37signals на AI-агенты и Rust разрушает традиционную модель разработки на Rails, но не предлагает замены для экосистемы — вызывая тревогу о будущем Ruby и роли разработчиков как менторов унаследованных систем. Разработчики в продакшене чаще работают с унаследованными системами, а не создают новые архитектуры — AI-агенты помогают тонко настраивать и поддерживать их, а не заменять человеческое понимание контекста. Спор: Одни считают переход на Rust и AI-агенты логичным шагом для бизнеса с ресурсами (DHH), другие — недоступным для большинства и губительным для экосистемы Rails, где нет инструментов для массового миграционного переписывания. Rails с его конвенциями идеален для AI-генерации кода — предсказуемая структура снижает токен-затраты и повышает надежность генерации, подтверждая опыт использования AI для CRUD-приложений. Успех переписывания бэкенда в Rust напрямую связан с наличием качественной тестовой базы — без неё AI не сможет поддерживать качество кода, что критично для долгосрочной поддержки. Спор: Некоторые утверждают, что AI-агенты не могут заменить глубокое понимание архитектуры, приходящее через ручное написание кода — агенты полезны только при чётком техническом видении опытных разработчиков. Совет: Менеджеры могут неправильно интерпретировать AI как способ генерировать продукт из ничего — важно понимать, что агенты работают на основе существующих кодовых баз и требуют квалифицированного руководства. Переход на Rust сократил количество серверов с 110 до 10, демонстрируя реальную экономию инфраструктуры — но это возможно только при наличии ресурсов и готовности отказаться от Ruby. Спор: Некоторые считают, что DHH провокационно объявил о смерти Rails на конференции, что неэтично по отношению к спонсорам и участникам, чьи бизнесы зависят от Rails — это не технический, а этический вопрос. AI-агенты не убивают flow-состояние — оно просто меняет форму: вместо написания кода разработчики управляют и ревьювят генерацию, требуя новых навыков, но не устраняя удовлетворение от создания. Совет: Для AI-разработки нужны фреймворки с жёсткими конвенциями — Rails подходит, но Elixir/Phoenix и другие также показывают эффективность, особенно при отсутствии исторического бремени. Паттерны вроде delegated type, упрощённые Rails, не будут автоматически перенесены в Rust — их нужно переосмысливать вручную, требуя глубокого понимания домена, а не только AI-генерации. Спор: Один участник считает, что DHH потерял связь с реальностью, восхищаясь размером бинарника в 0.5 МБ — это тривиальная оптимизация, не решающая проблему поддержки сложных бизнес-логик.

Дублирование часто дешевле, чем попытка создать «правильное» обобщение. На RailsConf 2014 я говорил: «дублирование намного дешевле неправильного абстракции», что отразилось в твите «Duplication is far cheaper than the wrong abstraction» (41 shades of blue, март 2014). Когда в коде появляется повтор, разработчик вытаскивает его в метод или класс, получая новую абстракцию. Со временем к ней добавляются параметры и условия, чтобы покрыть новые требования, и код превращается в запутанный набор ветвлений. При этом сохранение такой конструкции подпитывается эффектом удержания вложенных усилий — «sunk‑cost fallacy» заставляет считать, что сложный код обязателен и важен.

Чтобы выйти из ловушки, лучше отменить прежнее решение. Нужно вернуть дублирование, заменив вынесённый метод на его тело в каждом месте вызова, а затем оставить только те части, которые действительно нужны конкретному вызывающему. Удаляя лишние ветви, вы избавляетесь от условных параметров и получаете чистый код, который легко расширять. Такой «откат» часто раскрывает, что исходная абстракция была избыточной, и позволяет заново выделить более подходящие обобщения. Главное – не позволять заложенным усилиям удерживать плохой дизайн.

• Копирование кода иногда проще, чем вводить плохие абстракции, которые усложняют поддержку.
• Плохие абстракции добавляют скрытую сложность и приводят к самоссылкам, ухудшая читаемость.
• Правильный баланс между дублированием и абстракциями зависит от частоты изменения и контекста.
• Часто лучше откладывать рефакторинг, пока не будет ясно, что дублирование стабильно повторяется.

Чтобы ускорить процесс получения услуг у регулируемой монополии, где падение удовлетворённости ниже 96 % грозит миллионами штрафов, команда решила заменить устаревший ASP‑форму и дорогой React‑приложение на полностью HTML‑ориентированный сайт. Используя Astro, они построили сайт, где каждая стадия формы — отдельная страница, отправляемая на сервер, а данные сохраняются в базе. Такой подход позволил работать без JavaScript, поддерживать древние браузеры и сохранять ввод даже при плохом соединении. Результат — количество пользователей мгновенно удвоилось.

Ключевой принцип — «простое HTML работает везде». Как отмечает Теренс Эден, даже браузеры типа PSP, способные открыть лишь три вкладки и часто терять память, без проблем отображают страницы GOV.UK, написанные в лёгком HTML. Команда использовала кастомные веб‑компоненты, которые перехватывают стандартную валидацию браузера, выводят ошибки в aria‑describedby и очищают их при вводе, избегая тяжёлых React‑валидаторов. Доступность достигла уровня AA, а всё приложение оставалось лёгким: без 20 МБ JavaScript‑пакетов, только небольшие улучшения в виде CSS и минимального скрипта. Это показывает, что для публичных форм достаточно чистого HTML и грамотного серверного хранения, а современные фреймворки лишь дополняют, а не заменяют базовый веб‑технологический фундамент.

• Простой HTML‑first подход с минимальным JavaScript может значительно повысить доступность и производительность сайтов.
• Использование технологий вроде HTMX и серверных фреймворков (Go, Rails, Django) позволяет реализовать сложные функции без тяжёлых клиентских библиотек.
• Проблемы с поддержкой старых браузеров и устройств часто решаются через полифиллы, ограничение функционала и fallback‑варианты.
• Успешные кейсы показывают, что правильный дизайн и понимание пользователей важнее выбора конкретного фреймворка.

Автор рассказывает, как он создал свой собственный класс AppVersion для сравнения версий, но затем обнаружил, что в Ruby уже есть встроенный Gem::Version, который делает то же самое, но лучше. Он заменил свой класс на встроенный и призвал сообщество делиться знаниями, чтобы избежать изобретения велосипедов.

• Участники восхищаются элегантностью и лаконичностью Ruby, особенно в реализации классов вроде AppVersion, и отмечают его выразительность по сравнению с TypeScript, Elixir и другими языками.
• Подчеркивается мощь метапрограммирования Ruby и его роль в развитии любви к программированию, хотя есть критика по поводу документации и экосистемы.
• Сравниваются реализации AppVersion в других языках (Python, Java, Scala), где признается сходство в выразительности, но отмечаются различия в синтаксисе и подходах.
• Упоминается ностальгия по Rails и его современное состояние, а также скрытые возможности стандартной библиотеки Ruby.
• Есть критика Ruby за "скрытые опасности" (footguns) и проблемы с масштабированием, а также за то, что экосистема Rails затмевает сам язык.

Разработчик сравнивает несколько популярных фреймворков и объясняет, почему выбрал Phoenix LiveView. Вместо того чтобы разделять фронтенд и бэкенд на разные стеки, он нашёл решение, которое позволяет писать всё на одном языке — Elixir. Это не только ускоряет разработку, но и даёт серьёзные преимущества в производительности.

Ключевые моменты:

• Меньше кода, меньше ошибок: Вместо двух кодовых баз (например, JavaScript + PHP) всё пишется на Elixir, включая UI-логику, что снижает вероятность ошибок.
• Реальное время без усилий: LiveView использует WebSockets для двухсторонней связи в реальном времени, что встроено "из коробки" и не требует дополнительных библиотек.
• Производительность и надёжность: Бэкенд на Elixir (работающем на Erlang VM) обеспечивает высокую конкурентность и отказоустойчивость. Фоновые задачи через Oban перезапускаются автоматически при сбоях.
• Единая архитектура: Нет необходимости в отдельном API или SPA, что упрощает разработку и развертывание.

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

• Обсуждение в основном вращается вокруг сравнения Rails, Phoenix и LiveView, но при этом всплывают факты, что Rails всё ещё умеет WebSocket, а Phoenix не так уж идеален, если нужен только CRUD-приложение.
• Участники спора подчеркивают, что выбор стека часто диктуется личными предпочтениями и опытом, а не объективными преимуществами.
• Несколько раз поднимается тема, что современные фреймворки всё ещё не решают проблему масштабирования и фоновых задач, и что важнее выбрать тот стек, который действительно подходит под задачу.
• Также обсуждается, что выбор инструмента влияет на набор библиотек и сообщество вокруг него, и это может быть важнее, чем абстрактные преимущества языка.

Разрабатывайте самое простое, что только может работать.
Это правило годится и для исправления багов, и для новых систем.

Многие инженеры мечтают о «идеальной» архитектуре: масштабируемой, распределённой, красивой. Это ошибка. Лучше глубже понять текущую систему и сделать самое простое решение.

Простое может выглядеть скучно
Джуны любят рисовать сложные схемы из кэшей, очередей, прокси. Настоящее мастерство — уметь делать меньше. Великий дизайн выглядит тривиально: «О, задача оказалась простой».
Unicorn и стандартный Rails REST API — примеры: всё нужное достигается очевидными средствами.

Практика
Нужно ограничение частоты запросов в Go-сервисе?

• Вариант 1: Redis + алгоритм «протекающего ведра».
• Вариант 2: счётчики в памяти (теряются при рестарте).
• Вариант 3: включить rate-limit в edge-прокси одной строкой конфига.
  Если последнее покрывает требования — выбирайте его.

Развивайте продукт, начиная с минимума и усложняя только по новым требованиям. Это YAGNI как высший принцип.

Возражения

1. Слякоть из костылей
   Костыль не прост — он добавляет сложности. Настоящее простое решение требует понимания всей системы и часто сложнее придумать.

2. Что такое «просто»?
   Простота — это минимум сущностей, минимум переходов, минимум новых инструментов. Она не всегда очевидна и требует инженерной работы.

3. Масштабирование
   Простое не значит «только сейчас». Unix-сокеты, CGI, файлы — примитивы, на которых построены крупные системы. Если завтра потребуется масштаб, выясните новые факты и добавьте минимально необходимое.

Делайте самое простое, что только может работать — и будете удивлены, как далеко это вас заведёт.

• Участники сходятся в том, что «делай самое простое, что может работать» — полезная эвристика, но не универсальный закон.
• Опытные разработчики подчеркивают: простота ≠ легкость; требует глубокого понимания задачи и контекста.
• На больших системах «простое» быстро ломается из-за edge-case’ов и масштаба, поэтому часто приходится усложнять.
• Частая ошибка — проектировать «на вырост»: реакт, k8s и прочее для сайта из трёх страниц, лишь бы «в портфолио».
• Самый практичный совет: фиксируй реальные требования здесь и сейчас и строй под них, а не под гипотетическое будущее.