Почему мы заранее изучаем Rust, хотя не предлагаем его в каждый проект

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

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

«Я предложил Rust не потому, что хотелось попробовать что-⁠то экзотическое. Для меня это один из языков будущего именно из-⁠за его жесткости: если код нарушает правила, которые компилятор способен проверить, он просто не собирается. Ошибка не уходит дальше по цепочке — в тестирование, поддержку или к заказчику», — Вадим Зимин, техлид Энсайн.

В Энсайн эту позицию разделяют, но формулируют осторожнее: Rust не решает за команду архитектуру, бизнес-логику и качество продукта. Но как направление он действительно важен. Чем больше технических ошибок можно остановить до запуска, тем меньше проблем доходит до тестирования, поддержки и заказчика.

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

«Мы оцениваем новый стек не по тому, насколько он современный, а по тому, какой риск он снимает в конкретном проекте. Если технология помогает сделать запуск или поддержку более управляемыми, ее нужно считать. Если она только добавляет редкую компетенцию, срок и неопределенность, значит, это плохой выбор, даже если сам язык хороший», — Алексей Постригайло, старший партнер ИТ-⁠интегратора Энсайн.

Где Rust стал не идеей, а проектным решением

Один из показательных случаев был на проекте для сайта «Газпромнефть — смазочные материалы».

С технической точки зрения мы могли сделать серверную часть на привычном для таких задач стеке: PHP и фреймворке Yii. Это понятный вариант. Команда знает, как с ним работать, вокруг есть инструменты, библиотеки, подходы к развертыванию и поддержке.

Но в этом проекте важным оказалось не только «на чем написать». Важнее был вопрос: как это потом будет передаваться и запускаться.

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

Здесь было иначе. Архив приложения нужно было передавать зарубежным партнерам, а каждый партнер должен был разворачивать сайт у себя. При этом у нас не было полной информации, как именно и кем будут приниматься архивы, какие серверы уже есть на стороне партнеров, какое окружение там настроено и кто будет заниматься установкой.

Добавьте к этому часовые пояса, языковые барьеры и обычную для таких процессов цепочку коммуникаций. Партнер что-⁠то не смог запустить. Пишет заказчику. Заказчик приходит к нам. Мы пытаемся разобраться в окружении, которого не видим и не контролируем.

Формально проблема может быть не в приложении. Например, не та версия интерпретатора, не хватает расширения, отличается системная библиотека. Но для проекта это все равно проблема: сайт не запущен, процесс стоит, участники тратят время.

Нам не хотелось, чтобы установка сайта на стороне партнера превратилась в длинный и мучительный процесс.

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

Для нас ценность была не в том, что это Rust. Ценность была в более управляемой поставке. Мы хотели уменьшить количество случайностей на стороне партнера и не завязать запуск на бесконечную настройку окружения в чужой инфраструктуре.

Что мы из этого вынесли

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

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

В коммерческом проекте каждый стек должен отвечать на простой вопрос: какую конкретную проблему он снимает?

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

Но у Rust есть и цена. Команде нужно понимать модель владения, библиотеки, сборку, ревью, работу с unsafe, поддержку и сроки. Если этих ответов нет, язык сам становится риском.

Поэтому мы не предлагаем Rust в каждый проект. В типовом сайте, простой админке или быстром личном кабинете привычный стек часто будет быстрее, дешевле и надежнее с точки зрения поддержки.

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

Почему мы изучаем Rust заранее

Самая плохая точка для знакомства с новым стеком — момент, когда проект уже надо оценивать для заказчика.

В этот момент нельзя честно сказать: «Мы разберемся по ходу». Нужно понимать, кто будет писать код, кто будет его проверять, какие библиотеки использовать, сколько займет разработка, где появятся ограничения и во что потом обойдется поддержка.

Поэтому мы изучаем Rust заранее. Не ради красивой строки в списке технологий и не ради идеи «переписать все на новый язык». Нам важно заранее понять, где он действительно снижает проектный риск, а где просто увеличивает срок и стоимость.

В этом и есть нормальная интеграторская позиция. Технология выбирается не в вакууме. Она выбирается под задачу, окружение, команду, срок жизни системы и ответственность после запуска.

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

А если привычный стек решает задачу быстрее, дешевле и без лишних рисков, значит, правильный выбор — остаться на нем.