Огляд мови програмування 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 для більшості утиліт. Три залишаються на GNU coreutils (cp, mv, rm), бо станом на 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 загалом мало. Якщо обсяг вакансій для тебе вирішальний чинник, перевір актуальні вакансії на своєму цільовому ринку, перш ніж обирати мову.

Часті запитання