После семи лет в проде Scarf нехотя отказалась от Haskell

Ави Пресс, основатель Scarf и член совета директоров Haskell Foundation, опубликовал пост о том, почему компания после семи лет продакшена на Haskell переходит на Python. Он подчёркивает, что критикует язык не со стороны: 16 лет пишет на Haskell, считает его важнейшим языком в своей карьере и продолжает участвовать в его развитии.

Основной API Scarf работал на Haskell поверх PostgreSQL с библиотеками Servant и Beam, а высоконагруженный сервис Scarf Gateway, на низкоуровневой библиотеке WAI; через него проходит большой объём трафика загрузок open-source пакетов с контрактными SLA. По словам Пресса, система себя оправдала: код был надёжным, система типов реально ловила ошибки, а высокую производительность было несложно получить. Но цена тоже была реальной, время компиляции и трение вокруг экосистемы (настройка сборок, кешей, Nix, CI, окружений разработчиков). Долгое время команда с этим мирилась, зная язык и инструментарий досконально.

Переломным моментом стало массовое распространение ИИ-инструментов для написания кода. Пресс формулирует это так: раньше ошибки ловились в двух точках, на этапе компиляции и на этапе выполнения. Теперь появилась третья точка, момент генерации кода: модель часто предотвращает ошибку ещё до того, как её увидит компилятор. Из-за этого ценность строгой проверки типов на компиляции относительно снижается, а стоимость самой компиляции начинает значить куда больше. Если ИИ-агент выдаёт рабочую реализацию за пару минут, а сборка проекта с нуля занимает 15 минут, компилятор превращается из мелкой неприятности в главный тормоз всего цикла разработки. Особенно болезненно это ощущается при параллельной работе нескольких агентов в разных git worktree (изолированных рабочих копиях репозитория): каждая новая ветка работы требует холодной сборки, и если сборка Haskell дорогая, эта «пошлина» умножается на число параллельных агентов. Кеширование и удалённые сборщики (remote builders) помогают, но никогда не работают идеально, а усилия на их настройку, сами по себе часть проблемы.

В ответ Scarf начала вести всю новую работу над API на Python: развернули отдельный Python-сервер рядом с Haskell-сервером, маршрутизируют запросы между ними и постепенно переносят функциональность по мере того, как к ней прикасаются. Пришлось заново реализовать аутентификацию, доступ к базе данных, общие модели, образы для деплоя, тесты и вспомогательную инфраструктуру, раньше это было бы дорого, но с LLM перенос существующего кода на новый язык оказался, по словам Пресса, вполне рутинной задачей.

Высвободившееся время команда направила на то, чтобы выпускать больше функциональности с более полным тестовым покрытием: ИИ хорошо пишет тесты, хотя за ним нужен присмотр, он может писать бесполезные или фиктивные тесты. Путь от звонка клиента до заведённого тикета, PR, ревью, мержа и деплоя иногда укладывается в то же время, что и сам звонок с клиентом. Явной потери от отказа от строгой типизации Пресс пока не заметил, тестовое покрытие компенсирует риск, а починка багов после релиза теперь происходит быстро.

Дальше Пресс переходит к более широкому тезису: Haskell в опасности. Экосистема языка растёт заметно медленнее, чем конкурирующие экосистемы в эпоху ИИ, и разрыв в производительности между теми, кто эффективно использует ИИ, и теми, кто нет, будет только увеличиваться. При этом, по его наблюдению, в сообществе Haskell разговор об ИИ чаще сводится к ограничениям (запрет на использование LLM, требования раскрывать факт ИИ-ассистирования), а не к тому, как сделать язык удобнее для агентов. Он считает лагерь «не используем LLM» проигрышной стороной истории и предлагает переориентировать усилия сообщества: сделать документацию и примеры библиотек пригодными для копирования агентами, ускорить холодную сборку проектов, сделать сообщения об ошибках компилятора понятнее для моделей, упростить быстрый старт проектов, а не концентрироваться в первую очередь на исследованиях системы типов вроде зависимых типов (dependent types). Он призывает Haskell Foundation находить больше финансирования на техническую работу в этом направлении, иначе отставание из точечной неприятности превратится в фундаментальное несоответствие языка новой реальности разработки. Текст поста обрывается на полуслове («Мы всё ещё уважаем Haskell. Мы всё ещё используем Haskell в продакшене. Но…»), это обрыв исходного текста, а не сокращение пересказа.

Ключевые факты

Scarf семь лет держала бэкенд на Haskell (Servant/Beam/PostgreSQL плюс сервис Scarf Gateway на WAI с контрактными SLA) и была довольна надёжностью и системой типов
Ключевая причина ухода, не недостатки Haskell, а то, что ИИ-агенты сделали долгую компиляцию новым узким местом цикла разработки: генерация кода занимает минуты, холодная сборка, до 15 минут
Проблема резко обостряется при параллельной работе нескольких агентов в разных git worktree: каждая ветка требует своей холодной сборки, и цена умножается на число параллельных потоков работы
Миграция идёт постепенно: новый Python-API работает рядом со старым Haskell-сервером, маршрутизация между ними, перенос существующего кода на Python дался легко благодаря LLM
Автор, 16-летний сторонник Haskell и член совета Haskell Foundation, призывает сообщество не запрещать использование ИИ-агентов, а оптимизировать язык и экосистему под них (быстрая сборка, документация, ошибки компилятора для агентов)

Почему это важно

Пост фиксирует смену расчёта издержек в разработке ПО: раньше строгая типизация и её цена на компиляции однозначно окупались (меньше багов в проде), теперь появление быстрого этапа «генерации кода» ИИ-агентами меняет баланс, стоимость медленной компиляции стала весомее относительной пользы от строгих проверок на этом же этапе. Это не абстрактный аргумент: он привёл конкретную компанию к смене основного языка бэкенда после семи лет эксплуатации.

Кому это важно

Инженерным руководителям и архитекторам, которые выбирают или пересматривают технологический стек с оглядкой на работу с ИИ-агентами; сообществу Haskell и других языков с дорогой компиляцией (Rust, Scala и им подобных), где встаёт тот же вопрос; командам, которые уже используют несколько параллельных coding-агентов и упираются в стоимость холодных сборок и настройки окружений.

Как это применить

Практическая схема миграции из поста: не одномоментный переход, а постепенный, новый сервис на новом языке разворачивается рядом со старым, запросы маршрутизируются между ними, функциональность переносится по мере того, как к ней обращаются разработчики. LLM используется для рутинного переноса существующего кода (аутентификация, доступ к БД, модели, деплой, тесты) на новый язык, по опыту автора, это ускоряет то, что раньше было дорогой ручной работой.

Можно ли доверять

Источник, личный блог основателя и CEO компании, первое лицо, конкретные технические детали (конкретные библиотеки, архитектура, роль в Haskell Foundation) проверяемы и правдоподобны. При этом цифры о росте продуктивности намеренно не раскрыты («не могу поделиться всеми базовыми цифрами»), а выводы о качестве переноса, самоотчёт одной компании без независимой проверки; исходный текст обрывается на середине фразы, финал материала недоступен.

Риски и подводные камни

Вывод сделан на опыте одной компании и не обязательно обобщается на весь Haskell или на другие языки с дорогой компиляцией. Сам автор признаёт, что ИИ может писать «мусорные» или фиктивные тесты и требует присмотра, а также что явную потерю от отказа от строгой типизации компания пока не почувствовала лишь потому, что тестовое покрытие выросло, то есть риск переносится с компилятора на качество тестов, написанных тем же ИИ. Есть и репутационный риск для Haskell-сообщества: если нарратив «язык теряет актуальность из-за ИИ» приживётся, это может ускорить отток разработчиков независимо от того, решит ли сообщество проблему цены компиляции.

«Сопротивляться такой продуктивности больше не вариант.»

— Ави Пресс, основатель Scarf