Обзор языка программирования Rust: стоит ли его учить?

Спросите двух опытных Rust-разработчиков, стоило ли учить Rust, и можете получить прямо противоположные ответы. Один скажет, что для карьеры это ничего не дало; другой назовёт это одним из лучших технических решений в своей жизни. И оба могут быть правы.

Именно в этом противоречии и кроется вопрос «стоит ли учить Rust», и поэтому огульное «да» вам бесполезно. Rust — компилируемый язык, безопасное подмножество которого проверяет правила безопасности памяти на этапе компиляции, не требуя сборщика мусора во время выполнения.

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

Кратко

Rust стоит учить, если вы строите что-то долгоживущее, где за то, что компилятор ловит целый класс ошибок, стоит платить. Он не подходит, если вам нужно выпустить CRUD-приложение в этом месяце, вы только учитесь программировать или считаете вакансии. 4 из 5, с вычетом за то, во что он обходится, прежде чем начнёт окупаться.

• Что вы покупаете: в безопасном Rust правила владения и заимствования превращают ошибки use-after-free, double-free, недействительных ссылок и гонок данных в ошибки компиляции, а не в инциденты в продакшене. Вот и весь смысл, и он хорош.
• Чем вы платите: компилятор заставляет явно записывать решения о памяти, которые ваш нынешний язык принимает молча, и поначалу кажется, что инструмент просто вредничает.
• Вопрос долговечности решён. Мейнтейнеры ядра завершили эксперимент с Rust на Maintainers Summit в декабре 2025 года, а метка «экспериментальный» исчезла в Linux 7.0.
• Вопрос моды не решён, и это другой вопрос. Rust занимает #10 в индексе TIOBE за сентябрь 2026 года, поднявшись с #18 годом ранее.
• Моему тестовому сервису на Rust для компиляции понадобилось гораздо больше памяти, чем для работы: при сборке пик был около 1 GB, а в простое при работе — около 3,5 MB.
• Подходит вам, если вы уже выпускаете продукты на другом языке и создаёте что-то, где ошибка памяти обошлась бы дорого, или работаете рядом с системным ПО. Не подходит вам, если у вас горят сроки, вы начинаете с нуля или выбираете язык с наибольшим числом вакансий.

Как делался этот обзор: цифры сборки и выполнения здесь мои. Я установил Rust 1.98.1, написал небольшой веб-сервис на Axum и измерил, чего стоила компиляция и чего стоил запуск. Всё это работало в изолированном контейнере, а не на выделенном железе, и это один проект, так что считайте цифры точкой данных, а не законом. Всё остальное взято из первоисточников или авторитетных источников: патч ядра и материалы LWN о нём, посты Google о безопасности Android, собственный индекс TIOBE (с апрельским комментарием в пересказе Slashdot), Phoronix об окне слияния Linux 7.0, записи CVE ядра Linux об уязвимости в Binder, заявление самой Canonical и опрос Stack Overflow 2025 года. Патч ядра я прочитал. Код Rust в ядре я не аудировал. И я не пишу на Rust годами, поэтому там, где этот обзор оценивает сам язык, он опирается на практиков, которые пишут, и называет их по именам.

Что даёт вам компилятор

Дайте двум потокам изменяемую ссылку на один и тот же вектор в Rust, и код не скомпилируется. Не предупреждение. Не линт, который можно заглушить, когда горят сроки. Он просто не собирается. Этот отказ и есть то, что вы покупаете в безопасном Rust: ошибки use-after-free, double-free, недействительных ссылок и гонок данных превращаются в ошибки компиляции, а не в инциденты в продакшене. Аварийный люк Rust (unsafe) может обходить часть этих гарантий, так что это не абсолютное обещание для любой кодовой базы на Rust.

Владение означает, что у каждого значения ровно один владелец, отвечающий за его освобождение. Заимствование означает, что можно одалживать ссылки, но компилятор отслеживает их время жизни и не позволит ссылке пережить то, на что она указывает, или изменяемому заимствованию сосуществовать с любым другим. В безопасном Rust ошибки use-after-free, double-free, недействительных ссылок и гонок данных ловятся системой владения и типов ещё до запуска программы.

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

Цена проявляется там же, где и гарантия. Каждое решение о памяти, которое ваш нынешний язык тихо принимает за вас, Rust просит записать явно: кто этим владеет, сколько живёт вот эта ссылка, может ли её видеть что-то ещё и пересекает ли она границу потока. Компилятор не вредничает. Он отказывается гадать.

Итак: именно поэтому люди платят цену, которую просит Rust, и, по-моему, это оправдано. Если класс ошибок, который он устраняет, вас не беспокоит, остальная часть обзора вряд ли изменит ваше мнение.

Rust всё ещё эксперимент или уже продакшен-инфраструктура?

Экспериментом он перестал быть в декабре 2025 года, и закончили его сами мейнтейнеры ядра. На Maintainers Summit 2025 года они пришли к выводу, что Rust оправдал себя в ядре, технически и социально. Jonathan Corbet из LWN сообщил о консенсусе 10 декабря 2025 года: Rust в ядре больше не экспериментальный.

Rust попал в основную ветку Linux в v6.1 в 2022 году именно ради этого эксперимента. Патч Miguel Ojeda, снимающий метку, вышел через три дня после Summit и попал в окно слияния Linux 7.0.

«Но эксперимент окончен, то есть Rust пришёл, чтобы остаться».

Miguel Ojeda, «rust: conclude the Rust experiment», LKML, 13 декабря 2025 года

Отдельно и раньше: переписанный Google на Rust драйвер Binder для Android, IPC-слой, через который (постоянно) общаются процессы Android, вошёл в Linux 6.18, который вышел 30 ноября 2025 года. Не смешивайте эту веху с консенсусом Summit. Это та, где компания поставила на Rust в ядре реальный продукт, а не группа мейнтейнеров благословила идею. С тех пор Rust в ядре получил свой первый CVE: CVE-2025-68260, состояние гонки в том же драйвере Binder, о котором Greg Kroah-Hartman объявил 16 декабря 2025 года; оно появилось в 6.18 и исправлено в 6.18.1. Первые сообщения говорили о падениях, но более поздняя оценка команды CVE ядра Linux даёт CVE-2025-68260 балл 7,8 (высокий) и описывает путь локального повышения привилегий через повреждение памяти ядра. У того же драйвера (rust_binder) с тех пор накопились и другие CVE.

Android — это то место, где доказательства обретают цифры. В блоге безопасности Google в декабре 2022 года говорилось, что не было обнаружено ни одной уязвимости безопасности памяти в коде Android на Rust, при примерно 1,5 млн строк Rust в AOSP и около 21% всего нового нативного кода в Android 13. Это заявление 2022 года с охватом 2022 года. Более поздние посты Google показывают долгосрочный тренд: на проблемы безопасности памяти приходилось 76% уязвимостей Android в 2019 году и 24% в 2024 году, при этом их абсолютное число сократилось с более чем 220 до прогнозируемых 36. Эти цифры имеют смысл только в сравнении с базой, которую они заменили: C и C++, написанными очень хорошими инженерами с очень хорошими инструментами.

Два сигнала поменьше указывают в ту же сторону. Драйвер GPU Apple AGX в Asahi Linux написан на Rust, причём проектом Asahi Linux в порядке реверс-инжиниринга, а не самой Apple. Обновление Canonical о rust-coreutils сообщает, что Ubuntu 26.04 LTS поставляет rust-coreutils 0.8.0 для большинства утилит, тогда как cp, mv и rm остаются на GNU coreutils, потому что на 22 апреля 2026 года оставались открытыми восемь проблем TOCTOU; оставшиеся утилиты Canonical планирует перевести к 26.10.

Эту ось я оценил бы выше всех, и причина в характере обязательств. Мейнтейнеры ядра не отменяют завершённые эксперименты, Google не откатывает переписывание такого масштаба, а Canonical не кладёт переписанные coreutils в LTS, чтобы посмотреть, что получится. Что бы ни случилось с популярностью Rust, кому-то придётся поддерживать этот код годами.

Rust умер или просто вышел на плато?

Нет. В январе 2026 года Rust повторил свою лучшую позицию в TIOBE за всё время, #13. Через три месяца он откатился на #16, и CEO TIOBE Paul Jansen написал в апреле 2026 года, в комментарии, который тогда процитировал Slashdot, что рост популярности Rust «похоже, выходит на плато», а место в топ-10 «теперь кажется более далёким, чем раньше».

Он описывал, как Rust достиг своей высшей позиции за всё время в его собственном индексе (впервые он занял это место в июле 2024 года), а затем уступил её.

Индекс TIOBE за сентябрь 2026 года ставит Rust на #10: это выше #18 годом ранее и выше #13, которую TIOBE в январе назвал его высшей позицией за всё время.

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

Оговорка работает в обе стороны, и статья Slashdot подняла её ещё тогда: не могут ли рейтинги просто колебаться из-за помесячного шума в поисковой выдаче, а именно её индекс и считает. Если падение на три позиции за квартал было слабым доказательством замедления Rust, то подъём на шесть позиций — такое же слабое доказательство его победы. Воспринимайте это как погоду, а не климат.

Более сильный сигнал о настроениях — опрос Stack Overflow, где Rust снова стал самым любимым языком программирования в 2025 году с результатом 72%: это люди, которые использовали его за последний год и хотят продолжать. Это намерение продолжать, а не внедрение, и здесь это полезнее голой популярности, если вы решаете, понравится ли вам оставаться с этим языком.

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

Во что вам обойдётся изучение Rust

Цена приходится на самое начало, и вся сразу. Код, который Python, Java или C# охотно запустили бы, снова и снова отвергается по причинам, которые кажутся произвольными, пока модель владения не уляжется в голове, и отложить это нельзя. Проскочить мимо borrow checker, просто выпуская код, не выйдет, в отличие от того, как можно выпускать код, не до конца понимая свою ORM.

Вот что меня удивило, и это работает наоборот, чем вы ожидаете. В треде r/rust «Struggling to learn Rust» самый популярный ответ переосмысляет проблему как непривычность, а не сложность, и тред указывает, что тяжелее всего приходится опытным разработчикам, пришедшим из языков со сборкой мусора. u/Voxelman говорит прямо: «Rust не сложный. Он другой.» В том же треде он описывает свой путь: C64 Basic, затем ряд императивных языков и первое знакомство с Rust, которое «было каким угодно, только не WOW», потому что избавиться от старых привычек удалось не сразу.

Вот как выглядит счёт. Если вы восемь лет пишете на Python, вы не учите набор правил, вы отказываетесь от набора предположений о том, кто за вами убирает. Тому, кто знает меньше, меньше и переучиваться.

В этом треде постоянно всплывает ещё один паттерн, и он превращает ошибку в порядке действий в проблему уверенности в себе: люди застревают не на Rust, а на выборе веб-фреймворка, пытаясь выучить язык через Axum или Actix до того, как дошла идея владения. Как выразился u/jmartin2683, это «как пытаться выучить ruby, изучая rails».

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

Для сборки Rust нужна машина мощнее, чем для запуска

Вот вывод, которого я не ожидал: сборка этого проекта на Rust заняла на порядки больше памяти, чем его запуск. Я собрал небольшой сервис на Axum (Tokio с набором возможностей full плюс serde, serde_json, tower, один JSON-маршрут, около 60 крейтов в дереве зависимостей) на rustc и cargo 1.98.1, с strip = true в релизном профиле, а затем дважды собрал его с нуля:

# constrained: one compile job at a time
cargo build --release --jobs 1
# unconstrained: default parallelism, 4 vCPUs available
cargo build --release

С ограничением в одну задачу компиляции (--jobs 1) пиковое потребление памяти cargo, rustc и компоновщика составило от 464 MB до 527 MB в зависимости от того, какой из двух моих методов измерения брать (я мерил двумя способами, потому что первое число выглядело слишком гладким), а сборка заняла 113 секунд. С параллелизмом по умолчанию на четырёх vCPU пиковая память выросла примерно вдвое, примерно до 1 GB, и сборка завершилась примерно за 35 секунд. Переменная тут — параллелизм, а не проект. Больше задач означает больше процессов rustc в памяти одновременно, поэтому компиляторы — одна из немногих нагрузок, которые охотно займут все ядра, что вы им дадите, на несколько минут подряд.

Готовая программа после strip весит 1,3 MB и в простое использует примерно 3,3–3,6 MB памяти.

При параллелизме по умолчанию это в двести-триста раз больше памяти на компиляцию, чем на запуск; с ограничением в одну задачу всё равно намного больше чем в сто. Подберите сервер под то, что нужно вашему сервису на Rust в продакшене, и можете получить машину, которая не может его собрать, причём сбой будет не аккуратной ошибкой: это OOM killer, убивающий rustc посреди сборки, или компилятор, который двадцать минут молотит своп. Работают два варианта. Собирать там, где есть запас, и поставлять бинарник, по той же схеме, что и отдельная машина для сборки при тяжёлой работе с Docker. Или собирать на самой машине и дать ей место: для сервиса такого масштаба комфортно пары гигабайт RAM и двух vCPU. Если нет, запасной выход — --jobs 1 (да, это медленнее; такова цена).

Если на вашей рабочей машине нет такого запаса, наш Linux VPS с самостоятельным управлением даёт root-доступ с почасовой или помесячной оплатой и место, куда можно вынести сборку и вернуть его, когда закончите, хотя это всё ещё сервер, которым управляете вы, а не который управляет собой сам.

Один проект, одна конфигурация, одна машина. Машиной был общий изолированный контейнер, а не выделенный сервер, примерно с 2 GB доступной памяти, так что неограниченный пик подходил к её потолку ближе, чем на машине побольше. Это не универсальная константа: если ваше дерево зависимостей в четыре раза больше или релизный профиль включает оптимизацию на этапе компоновки, ждите других цифр. Большие деревья зависимостей, оптимизация на этапе компоновки и код с обилием дженериков могут поднять память сборки выше, так что не считайте мои замеры универсальным потолком.

Я бы отнёс это к тому, как вы работаете, а не к тому, учить ли язык. Знайте об этом до того, как столкнётесь.

Кому стоит учить Rust

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

Вы уже выпускаете продукты на другом языке и строите что-то долгоживущее, где ошибка памяти обошлась бы дорого. Сервис, который обязан работать. Библиотека, от которой зависят другие команды. Всё, где use-after-free означает разбор инцидента, а не трассировку стека в терминале. Ради этого случая и строилась вся гарантия, а то, что вы платите вначале, амортизируется за всё время жизни того, что вы строите.

Вы работаете рядом с системным ПО или внутри него. Драйверы, работа с устройствами, утилиты базовой системы, встраиваемые системы, всё, что работает под операционной системой, а не поверх неё. Здесь индустрия взяла на себя обязательства так, как нигде больше, и доказательства в пользу безопасности памяти здесь сильнее всего.

Вам нужен побочный эффект. Два комментатора в том треде r/rust полностью расходятся в оценке карьерной ценности Rust, но здесь приходят к одному. u/tyler_church, который говорит, что на карьеру это не повлияло совсем, всё же допускает «возможно, тонкое влияние на то, как я пишу другие программы на других языках». u/SirKastic23, который уже два года получает деньги за код на Rust, говорит, что это расширило его навыки так, как он и не ожидал. Два человека, а не исследование, но это отдача, которая остаётся, даже если вы никогда не будете писать на Rust профессионально: изменение в мышлении, а не строчка в резюме.

Кому не стоит учить Rust

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

У вас дедлайн в этом месяце по CRUD-приложению или прототипу. Rust приходит ровно не по тому расписанию для работы, которая должна существовать к пятнице. Очевидная альтернатива — Go, если вам нужен компилируемый язык с быстрой сборкой и управлением памятью через сборщик мусора и не нужны гарантии Rust, основанные на владении.

Вы вообще только учитесь программировать. Этот вопрос по-настоящему раскалывает людей, которые пишут на Rust профессионально, и спор в тредах r/rust идёт в обе стороны, поэтому моя позиция такая: давать новичку подброшенную монетку — плохой совет, как бы она ни упала. Сначала разберитесь, как работает машина, где-нибудь, где больше прощают, а потом возвращайтесь и дайте компилятору подтянуть это понимание.

Вы выбираете язык по числу вакансий, где он упоминается. Здесь я не дам цифру, потому что не нашёл данных о зарплатах или вакансиях для Rust, которые вели бы к источнику, за который я бы поручился. То, что u/crusoe описывает в том треде r/rust, — это рынок с меньшим числом более специализированных позиций. Это один комментатор в одном треде, а не данные рынка труда, так что я бы не делал из этого вывод, что вакансий на Rust в целом мало. Если объём вакансий для вас решающий фактор, проверьте актуальные вакансии на своём целевом рынке, прежде чем выбирать язык.

Часто задаваемые вопросы