Rust уже кілька років поспіль очолює рейтинги «улюблених мов» серед розробників, але водночас має репутацію однієї з найскладніших для опанування. Чому ж інженери вперто проходять цей бар’єр і залишаються з Rust надовго? У розмові на подкасті The Pragmatic Engineer про це докладно говорить Аліс Рюль — інженерка в Android Rust‑команді Google, core‑мейнтейнерка Tokio (де-факто стандартного async‑рантайму для Rust) та радниця команди мови Rust.
За цією, на перший погляд, «важкою» мовою стоїть дуже прагматична обіцянка: якщо код на Rust скомпілювався, він із високою ймовірністю працюватиме правильно в продакшені. Не тому, що розробники стали ідеальними, а тому, що сама мова й екосистема систематично не дають пропускати цілі класи помилок.
Ця стаття розбирає, як Rust вибудовує досвід розробки навколо надійності: від типів і обробки помилок до рефакторингу, документації та інструментів.
Мова для тих, хто не хоче прокидатися вночі через продакшен
Rust сьогодні тихо, але впевнено займає місце мови для надійних і високопродуктивних систем. У TIOBE‑індексі, який оцінює популярність мов програмування, Rust уже обігнав PHP і Go. Паралельно він з’являється в усе більшій кількості компаній та проєктів — від інфраструктурних стартапів до ядра Linux.
Ключова цільова аудиторія Rust — команди, яким потрібна мова, що мінімізує кількість багів у продакшені. Це особливо помітно, якщо дивитися з перспективи розробника, який приходить, наприклад, із TypeScript.
Для такого інженера Rust природно лягає в бекенд: API‑сервери, сервіси, які мають працювати безвідмовно й під навантаженням. Ідея проста: ви не хочете прокидатися серед ночі через падіння веб‑сервера, спричинене якоюсь дрібною, але фатальною помилкою. Rust намагається зробити так, щоб більшість таких помилок просто не проходили компіляцію.
Фраза «once it compiles, it works» у спільноті Rust звучить часто. Вона, звісно, не є математичною гарантією від усіх багів, але добре передає відчуття: компілятор і типова екосистема мови влаштовані так, щоб виявляти проблеми ще до запуску коду.
Це відчуття не виникає з повітря. Воно є наслідком цілого набору рішень у дизайні мови.
Нуль без null: як Rust змушує моделювати відсутність і помилки
Один із найвідоміших «гріхів» класичних мов — це null. Автор null у Java, Тоні Гоар, називав його своїм «помилкою на мільярд доларів»: кожен виклик функції може обернутися неочікуваним NullPointerException і крашем програми.
Rust радикально вирізає цю категорію помилок: у мові просто немає null. Відсутність значення моделюється через enum Option, а помилки — через enum Result.
Це змінює саму культуру написання коду.
По‑перше, будь‑яке значення, яке може бути відсутнім, має бути явно позначене як таке. Замість «можливо null» за замовчуванням, як у Java, Rust вимагає: якщо щось може не існувати, тип має бути Option<T>. Компілятор потім змушує розробника обробити обидва варіанти — «є значення» і «немає значення» — перед використанням. Забути перевірку просто не вийде: код не скомпілюється.
По‑друге, Rust не використовує винятки для помилок. Замість цього функції повертають Result<OkType, ErrorType>. Це означає, що кожен виклик потенційно помилкової операції явно позначений у типах. Немає прихованих шляхів, де помилка «пролетить» через стек викликів і раптово зупинить програму.
Щоб не перетворити обробку помилок на нескінченний шаблонний код, Rust має оператор ?. Він читається як: «якщо тут помилка — поверни її з поточної функції». Це дозволяє писати лаконічний, але все ще явний код. Важливий момент: якщо розробник просто «забуде» поставити ? або іншим чином обробити Result, це не залишиться непоміченим. Нехтування результатом — це помилка компіляції.
У багатьох інших мовах ігнорування результату функції — звична пастка. Наприклад, виклик, який повертає помилку, можна просто не перевірити, і програма продовжить працювати, накопичуючи приховані проблеми. У Rust такий стиль технічно неможливий: компілятор змушує вас або обробити помилку, або явно сказати, що ви її свідомо ігноруєте.
У сумі це створює саме те відчуття «коли скомпілювалося — працює»: відсутність і помилки не можуть «прослизнути» повз розробника як неявні стани. Вони стають частиною контракту функцій і типів.
Рефакторинг як діалог із компілятором
Ще одна причина, чому Rust відчувається «надійною» мовою, — це те, як вона підтримує рефакторинг. У багатьох мовах зміна API або структури даних — це завжди ризик: щось можна пропустити, десь залишиться старий виклик, який компілюється, але працює неправильно.
Rust спроєктований так, щоб компілятор фактично вів розробника за руку під час змін.
Коли змінюється тип або сигнатура функції, компілятор послідовно вказує на всі місця, де старий контракт більше не виконується. Замість того, щоб шукати по всьому коду, розробник просто йде за списком помилок компіляції, виправляючи їх одну за одною. Це перетворює рефакторинг із «пошуку мін» на керований процес.
Особливо потужним цей підхід стає в поєднанні з enum‑ами та оператором match. На відміну від класичного switch, Rust‑івський match вимагає повного покриття всіх варіантів enum‑у, якщо розробник не використовує спеціальний «catch‑all» варіант. Це означає, що коли до enum додається новий варіант, усі match‑вирази, які не враховують його, миттєво стають помилками компіляції.
У практиці це виглядає так: команда додає новий стан до бізнес‑логіки — наприклад, ще один статус замовлення чи новий тип події. У мовах без такої перевірки можна легко забути оновити якусь гілку логіки, і програма поводитиметься некоректно лише в рідкісних сценаріях. У Rust компілятор одразу підсвічує всі місця, де цей новий стан ще не оброблено.
Це не просто зручність. Це системний спосіб зменшити ризик регресій під час еволюції коду. Мова буквально не дає забути про нові варіанти поведінки.
У поєднанні з тим, що Rust не дозволяє використовувати неініціалізовані змінні — значення обов’язково має бути встановлене до першого використання — це створює ще один рівень захисту від типових помилок, які в інших мовах виявляються вже в рантаймі.
Документація, яка не бреше: коли приклади — це тести
У багатьох проєктах документація швидко відстає від реального коду. Приклади в README або API‑довідці перестають працювати, але ніхто про це не знає, поки хтось не спробує їх запустити. Rust намагається розв’язати цю проблему на рівні інструментів.
Документаційні коментарі в Rust позначаються трьома слешами ///. Усередині них можна писати приклади коду — звична практика для будь‑якої мови. Але в Rust ці приклади не залишаються просто текстом: інструменти компілюють їх і запускають як тести.
Якщо код змінюється так, що приклад більше не відповідає реальній поведінці або API, тест падає. Це означає, що «забути оновити документацію» стає не просто людською помилкою, а конкретним червоним тестом у CI.
Для бібліотек і фреймворків це особливо важливо. Приклади в документації часто є першим, що бачить розробник, який пробує інструмент. У Rust є вбудований механізм, який змушує ці приклади залишатися актуальними. Це ще один прояв тієї ж філософії: зробити правильну поведінку «шляхом найменшого опору», а неправильну — технічно складною або неможливою.
JSON, типи й Serde: коли валідація вбудована в дизайн
У сучасних бекенд‑системах значна частина помилок пов’язана з обробкою даних: некоректний формат JSON, відсутні поля, неправильні типи. Rust‑екосистема пропонує відповідь на це через бібліотеку Serde, яка стала стандартом де‑факто для серіалізації та десеріалізації.
Підхід Serde добре ілюструє, як Rust поєднує типову безпеку з продуктивністю. Розробник описує структуру даних як звичайний Rust‑структ struct із полями та типами. Далі за допомогою derive‑макросів він вмикає для цієї структури підтримку парсингу з JSON.
Serde на основі цієї структури генерує спеціалізований код, який перевіряє, що вхідний JSON має саме ту форму, яку описано в типі: усі потрібні поля присутні, типи збігаються, формат коректний. Це не універсальний «рефлексивний» парсер, який намагається підлаштуватися під усе, що йому дають. Це код, оптимізований під конкретну форму даних.
Результат — одночасно й жорстка валідація, і висока швидкість. І знову ж таки, помилки не можуть бути проігноровані: результат парсингу — це Result, який потрібно або обробити, або явно передати далі.
У поєднанні з відсутністю null і вимогою явно моделювати опційні поля через Option, це дає більш передбачувану поведінку при роботі з зовнішніми даними. Там, де в інших мовах можна «проковтнути» некоректний JSON і отримати дивні стани в об’єктах, Rust змушує або відхилити запит, або чітко описати, як поводитися з неповними даними.
Екосистема, що підсилює типоцентричний підхід
Важливо, що всі ці властивості Rust не існують у вакуумі. Їх підсилює екосистема інструментів і бібліотек, яка робить «типоцентричний» підхід до розробки повсякденною практикою.
Cargo — стандартний менеджер пакетів і збірки для Rust — інтегрує тести, документацію, лінтинг і публікацію в єдиний робочий процес. Для розробника природно регулярно запускати тести, включно з тими, що заховані в документаційних прикладах. Це зменшує тертя між «написати код» і «переконатися, що він коректний».
Tokio, яким опікується Аліс Рюль, фактично виконує роль стандартної бібліотеки для асинхронного Rust. Він надає чергу задач і модель виконання, схожу на event loop у JavaScript, але з можливістю працювати на кількох потоках. Це дозволяє будувати високонавантажені бекенд‑сервіси, не виходячи за межі типобезпечної моделі Rust.
Усе це разом формує певний стиль розробки: спочатку моделюється домен через типи й enum‑и, потім компілятор і інструменти допомагають довести реалізацію до стану, коли всі варіанти оброблені, усі помилки враховані, а документація відповідає коду.
Це не означає, що в Rust немає багів або що мова магічно вирішує всі проблеми дизайну систем. Але вона суттєво зменшує простір для цілої низки класичних помилок, які в інших мовах виявляються вже в продакшені.
Чому розробники залишаються з Rust, попри криву навчання
Rust часто описують як мову з крутою кривою навчання. Концепції на кшталт ownership і borrow checker вимагають зміни мислення, особливо для тих, хто приходить із мов із garbage collector’ом. Однак багато інженерів, пройшовши цей етап, не хочуть повертатися назад.
Причина в тому, що Rust пропонує не просто синтаксис чи нові фічі, а інший досвід розробки. Компілятор стає партнером у проєктуванні API й рефакторингу, а не лише «перевіряльником граматики». Типи, enum‑и, Result і Option перетворюються на інструменти моделювання домену, а не лише на спосіб зберігати дані.
Для команд, які будують критичні бекенд‑сервіси, це означає менше «сюрпризів» у продакшені й більше впевненості в тому, що зміни в коді не зламають систему в неочевидних місцях. Для окремих розробників — відчуття, що мова допомагає писати правильний код, а не боротися з нею.
Rust не обіцяє нуль багів. Але він послідовно вбудовує в мову й інструменти ідею: усе, що може піти не так, має бути або явно змодельоване, або зупинене на етапі компіляції. Саме це й робить його «іншим» — і пояснює, чому фраза «once it compiles, it works» так часто виявляється ближчою до правди, ніж у більшості інших мов.
Джерело
Why Rust is different, with Alice Ryhl — The Pragmatic Engineer Podcast