Hacker News Digest

Ruby Central, испытывающая финансовые трудности после потери спонсорства Sidekiq ($250 тыс. в год), по требованию Shopify взяла под контроль ключевые проекты Ruby-сообщества — Bundler и RubyGems — без согласия их многолетних сопровождающих. Shopify пригрозила отозвать финансирование, если Ruby Central не обеспечит полный контроль над репозиториями и правами на gems, что привело к принудительному изменению прав доступа и исключению ведущих разработчиков, включая Андре Арко с 10-летним стажем.

Этот захват был преднамеренным: Shopify заранее организовала дежурство для замены прежних сопровождающих, а совет Ruby Central проигнорировал предупреждения о незаконности действий и альтернативы в виде форков. Инцидент подчеркивает риски зависимости open-source от корпоративного финансирования, где сообщество теряет автономию под давлением спонсоров.

• Sidekiq прекратил спонсорскую поддержку Ruby Central на $250 тыс. в год из-за участия DHH в RailsConf 2025, что вызвало споры о его политических взглядах.
• Shopify и Ruby Central взяли под контроль инфраструктуру RubyGems и Bundler, удалив ключевых мейнтейнеров, официально — для усиления безопасности supply chain.
• Сообщество раскололось: часть видит в действиях Shopify корпоративный захват, другие — необходимые меры после недавних атак на npm.
• Критики обвиняют Ruby Central в злоупотреблении властью и плохой коммуникации, особенно после передачи прав на репозитории без консенсуса.
• Наблюдатели отмечают, что конфликт усугубляется давними культурными разногласиями в сообществе Ruby, выходящими за рамки технических вопросов.

Почему в 2025 году мы всё ещё пишем на Ruby

Стартуя с Lago, мы выбрали Ruby on Rails — у команды был десятилетний опыт, и это был самый быстрый путь к рабочему API. Сегодня система обрабатывает миллионы вызовов в день, пережила множество обновлений Ruby/Rails, и, если бы начинали заново, выбор остался бы тем же.

Скорость как главное преимущество
Rails больше не «тренд» для стартапов, но его используют Shopify, GitHub, GitLab — зрелые компании, которым важна надёжность и скорость разработки. Мы взяли Rails в API-only режиме: без лишнего middleware и рендеринга, но с миграциями, валидациями, Active Record и фоновыми задачами. Это позволило тратить время на продукт, а не на костыли.

Масштабируемость
Rails не масштабируется? Это проблема архитектуры, а не фреймворка.

• Rails 8 упрощает деплой без PaaS.
• Redis + Sidekiq проверен временем.
• Ruby Fibers добавляют асинхронность.
• Puma, автомасштабирование и кеширование справляются с нагрузкой.

Недостатки, с которыми живём

• Производительность и память: ошибки дорого обходятся.
• GIL CRuby: один поток Ruby-кода за раз, поэтому тяжёлые задачи уходят в Go/Rust.
• «Магия» Rails: избегаем лишних гемов и пишем максимально явный код.

Все языки компромиссы; мы выбрали Rails, потому что знаем его настолько хорошо, что умеем обходить ограничения и получать максимум скорости разработки.

• Участники жалуются на рутину вокруг JS/TS-стека: тройное дублирование типов, самописная интеграция auth и прочие «reinventing wheels».
• Многие называют Rails «скучным, но рабочим» инструментом, который до сих пор быстро даёт полный вертикал функционала без бойлерплейта.
• Популярность Rails страдает из-за ассоциаций с «устаревшей» эпохой 10-летней давности и отсутствия хайпа, хотя кодовая база активно развивается (YJIT, ZJIT).
• На практике Rails используется для бизнес-логики и API, а Go/Rust — для I/O- или CPU-ёмких задач; Shopify и GitHub живут по такой же схеме.
• Некоторые мечтают о «Rails на другом языке» (Clojure, Gleam) или ждут, что AI сделает быстрые языки такими же удобными, как Ruby.