[Перевод] Rewrite It in Rust: когда переписывание действительно оправдано

RIIR. Если вы хоть немного следите за open source, то наверняка с этим сталкивались. Кто-нибудь открывает issue в проекте на C или C++ и предлагает переписать всё на Rust ради безопасности работы с памятью и производительности. Иногда это вполне серьёзное предложение. Иногда — мем. В 2026 году, пожалуй, это и то и другое одновременно.

Нам захотелось разобраться, что из этого ближе к реальности. Не в теории, а на примерах проектов, которые действительно решились на такой шаг: какие преимущества они получили, что случилось с производительностью, какие проекты забросили спустя три года работы и какие CVE обнаружились в только что написанном Rust-коде. Мы достаточно давно варимся в этой экосистеме и успели увидеть всё перечисленное. Эта статья основана на докладе с Rustikon 2026 и представляет собой попытку без прикрас разобраться, что на самом деле происходит с RIIR.

Что такое RIIR и почему эта идея стала популярной?

RIIR расшифровывается как Rewrite It In Rust — «перепишите это на Rust». Фраза начала появляться в issue-трекерах проектов на C и C++ как предложение перейти на производительную альтернативу с безопасной работой с памятью. По данным Google Trends, интерес к запросу «rewrite rust» начал заметно расти примерно в 2022 году. Кажется, это примерно совпало с выходом Rust 2021 Edition, хотя в тот период происходило много всего, поэтому утверждать, что причина именно в этом, мы не берёмся.

Когда разработчики задумываются о переписывании проекта и выбирают Rust, обычно их привлекают три вещи:

1. Безопасность работы с памятью

2. Производительность

3. «Бесстрашная конкурентность» (fearless concurrency)

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

Что до производительности, в исследовании 2017 года, где языки программирования сравнивались по энергоэффективности, времени выполнения и потреблению памяти, Rust оказался среди лидеров и по энергоэффективности, и по скорости выполнения. Методика исследования не идеальна, да и напрямую сравнивать языки непросто, но результаты всё же отражают общую картину: Rust способен на равных конкурировать с другими языками и по скорости, и по эффективности. По потреблению памяти он уступал абсолютным лидерам, но всё равно находился в верхней половине рейтинга.

А ещё есть опрос разработчиков Stack Overflow. Rust уже несколько лет подряд остаётся самым любимым языком среди разработчиков. И вполне вероятно, что немалая часть RIIR-проектов существует просто потому, что разработчикам хочется писать на Rust. Это тоже стоит признать.

Три типа переписывания

Не все переписывания одинаковы, поэтому полезно сразу уточнить, о каком именно типе идёт речь. Мы выделили три категории.

Полностью совместимые замены (drop-in replacements) стремятся полностью повторить функциональность оригинала. Вы просто заменяете бинарник, а всё остальное продолжает работать как раньше. К этой категории относятся, например, uutils coreutils, sudo-rs, youki как замена контейнерного рантайма и Arti как новая реализация Tor. Таких проектов в экосистеме тысячи: от небольших библиотек для работы с файловыми форматами, вроде PNG-крейта, заменяющего libpng, до крупных инфраструктурных проектов с серьёзной поддержкой компаний и сообщества.

Альтернативы решают ту же задачу, но делают это иначе. ripgrep вместо grep, delta вместо diff, bat вместо cat, Typst вместо LaTeX, Polars вместо pandas. Они не пытаются быть полностью идентичной заменой. Часто такие проекты быстрее, удобнее или просто строятся вокруг другой философии. Typst хорошо показывает преимущество с точки зрения читаемости:

LaTeX и Typst способны дать один и тот же результат, но исходный код у них выглядит совершенно по-разному. А если говорить о чистой производительности, Марек запустил ripgrep и grep на каталоге target от Cargo размером 37 ГБ и искал слово cot. grep справился за 52 секунды. ripgrep – за шесть. Это уже не небольшая разница.

Переписывание собственного проекта на Rust (self-rewrite) – это ситуация, когда существующий проект решает переписать на Rust часть своей кодовой базы или всю её целиком, не заменяя при этом какой-то внешний бинарник. Сюда относятся Firefox, ядро Linux, Windows, инфраструктура Cloudflare и оболочка Fish. И это уже совсем не маленькие эксперименты. Сегодня Rust используется в некоторых из самых массово развёрнутых программных систем в мире, и пришёл он туда именно таким путём.

Производительность после переписывания на Rust: действительно ли становится быстрее?

Иногда да. При том иногда – не по вполне очевидным причинам.

Например, в uutils утилита sort работает почти в четыре раза быстрее GNU sort. Причина – параллельная сортировка слиянием, которую благодаря модели конкурентности Rust заметно проще реализовать корректно. Но некоторые другие утилиты быстрее просто потому, что это новая реализация, созданная с учётом 30 лет накопленного опыта. У оригинального проекта не было такой свободы для экспериментов: от него зависели пользователи в продакшене.

PNG-крейт – более показательный пример преимуществ, связанных именно с Rust. Реализация на Rust почти вдвое быстрее libpng. Отчасти это результат автовекторизации: компилятор Rust автоматически генерирует SIMD-инструкции из обычного цикла for, тогда как в большинстве реализаций на C SIMD приходится писать вручную. Второй фактор – потоковая декомпрессия DEFLATE, благодаря которой за один раз в кеш процессора помещается больше данных. И то и другое уже можно считать реальными преимуществами Rust.

Размер бинарников Rust: в чём проблема и как её решают

Бинарники Rust славятся своим размером, и причины вполне конкретные: код для обработки panic, реализации трейта Debug, стандартная библиотека, включаемая в каждый бинарник, мономорфизация дженериков и статическая линковка всех зависимостей.

В uutils эту проблему решили с помощью формата мультиколл-бинарника (multicall binary) – того же подхода, который использует BusyBox. Все утилиты компилируются в один бинарник и вызываются через символические ссылки. В итоге 73 МБ отдельных бинарников превращаются в 13,8 МБ одного мультиколл-бинарника – это даже меньше, чем 18,4 МБ у стандартной установки GNU coreutils. После сжатия UPX размер уменьшается до 5 МБ.

Проблему можно решить, но для этого придётся серьёзно потрудиться.

Переписывание на Rust: что может пойти не так и почему?

Об этом говорят недостаточно: любое переписывание приносит новые баги. Вы пишете код с нуля, а значит, неизбежно получите ошибки или регрессии, которых не было в исходном проекте. Это проблема не конкретно Rust, а переписывания ПО как такового. Но важно смотреть на неё трезво.

Cloudflare допустила вызов unwrap в компоненте оценки запросов. uutils немного неправильно форматировал даты, из-за чего ломались автоматические обновления. sudo-rs после тайм-аута выводил обратно в терминал уже набранную часть пароля. Первая CVE в Rust-коде ядра Linux появилась из-за состояния гонки в unsafe-блоке драйвера Android Binder. TARmageddon — RCE-уязвимость в async-tar — возникла из-за некорректного разбора формата .tar.

Если такие ошибки допускают даже опытные команды с серьёзным финансированием, будем допускать и мы. Это не повод отказываться от переписывания, но веская причина относиться к тестированию всерьёз.

А иногда Rust вообще оказывается не лучшим выбором. Microsoft выбрала Go для переписывания компилятора TypeScript во многом потому, что модель программирования Go гораздо ближе к TypeScript. Это было особенно важно, поскольку довольно долго в одной кодовой базе должны были сосуществовать оба языка. Проект NTPsec тоже выбрал Go: на тот момент у него были более удобные сетевые примитивы и менее фрагментированная экосистема. Это вполне рациональные решения, а не недостаток амбиций.

Более того, некоторые проекты выбрали Rust для переписывания, но всё равно не добились успеха. Prisma отказалась от движка запросов на Rust и вернулась к TypeScript из-за нехватки нужной экспертизы в команде, сложностей с развёртыванием и проблем с рантаймом. Loglog Games отказалась от Rust после трёх лет разработки игр. По их опыту, Rust отлично подходит для рефакторинга, но плохо — для быстрых итераций. Они также отметили, что Rust-сообщество в геймдеве больше сосредоточено на технических деталях движков, чем на выпуске законченных игр. Интеграция curl с hyper дошла до 95% готовности, после чего её забросили: последние 5% оказались слишком сложными, а интерес сообщества сошёл на нет. При этом сотрудничество всё равно пошло обоим проектам на пользу: попытка интеграции заставила разработчиков навести порядок в обеих кодовых базах.

Лицензия — это тоже важное решение

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

Более строгая лицензия вроде GPL может отрезать пользователей, которые не могут добавлять в проприетарные проекты зависимости с copyleft-лицензиями. Более разрешительная лицензия, наоборот, может вызвать критику со стороны open source-сообщества: некоторые опасаются, что компании будут пользоваться кодом, ничего не отдавая взамен. Универсально правильного ответа здесь нет. Всё зависит от целей проекта и его сообщества. Но это решение стоит принимать осознанно, а не просто оставлять вариант по умолчанию.

Живо ли движение RIIR в 2026 году?

Сам мем RIIR немного поутих. Но само движение никуда не делось. Rust в ядре Linux больше не считается экспериментом, а на Maintainers Summit 2025 мейнтейнеры признали эксперимент успешным. Rust работает и в ядре Windows. Cloudflare, Firefox и множество инфраструктурных проектов уже используют значительные объёмы Rust-кода в продакшене.

Масштаб действительно огромен. Только благодаря Linux и Windows Rust сегодня работает на миллиардах устройств. Пожалуй, это самое весомое подтверждение жизнеспособности идеи «переписать на Rust» за всё время её существования.

Как сделать всё правильно

Если вы задумались о переписывании проекта, сначала стоит ответить на несколько вопросов. Действительно ли Rust подходит для вашей задачи? Написана ли кодовая база на языке без гарантий безопасности работы с памятью? Насколько критично это ПО? Есть ли реальные требования к производительности и надёжности? Много ли в проекте параллельного или конкурентного кода, в котором сложно разобраться? Чем больше ответов «да», тем весомее аргументы в пользу переписывания.

Убедитесь, что команда к этому готова. Разработчики либо уже должны знать Rust, либо действительно хотеть его освоить и работать с ним. По данным Google, примерно две трети разработчиков уже через два месяца чувствуют себя достаточно уверенно, чтобы вносить изменения в кодовую базу на Rust. Но никаких гарантий здесь нет, а последние 5% переписывания почти всегда оказываются сложнее, чем кажется. Небольшие проекты занимают месяцы. Средние – от одного до двух лет, крупные – от двух до пяти. Почти всегда всё длится дольше первоначальных оценок.

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

А если всё же что-то переписываете, создайте серьёзный набор тестов. Один из лучших примеров – uutils, который прогоняется на официальном наборе тестов GNU coreutils, чтобы отслеживать соответствие поведению оригинала. На начало 2026 года доля успешно пройденных тестов составляет 92,2% и продолжает расти.

Так стоит ли оно того?

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

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

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

• 23 сентября, 20:00. «Создание кроссплатформенного приложения с GUI на Rust: от идеи до реальности». Записаться

• 24 сентября, 20:00. «Указатели в Си — от адреса к управлению памятью». Записаться

Полный список бесплатных уроков сентября смотрите в дайджесте.