# Canonical переписує C на Rust за допомогою AI: що це змінює > Canonical приєдналася до AI-ініціативи з перекладу коду з C на Rust — крок, що може здешевити модернізацію legacy-систем для будь-якої команди. - Опубліковано: 24 серпня 2026 р. (2026-08-24T11:00:22.230908+00:00) - Розділ: Практика - На основі публікації: [The Register AI](https://www.theregister.com/software/2026/08/24/canonical-backs-quest-to-translate-mountains-of-c-into-safe-rust-with-ai/5290959) - Видання: AiiN (https://aiin.news) - URL: https://aiin.news/article?slug=canonical-%D0%BF%D0%B5%D1%80%D0%B5%D0%BF%D0%B8%D1%81%D1%83%D1%94-c-%D0%BD%D0%B0-rust-%D0%B7%D0%B0-%D0%B4%D0%BE%D0%BF%D0%BE%D0%BC%D0%BE%D0%B3%D0%BE%D1%8E-ai-%D1%89%D0%BE-%D1%86%D0%B5-%D0%B7%D0%BC%D1%96%D0%BD%D1%8E%D1%94 --- Canonical, компанія-розробник Ubuntu, приєдналася до ініціативи, яка використовує штучний інтелект для масового перекладу коду з мови C у Rust. [За даними The Register AI](https://www.theregister.com/software/2026/08/24/canonical-backs-quest-to-translate-mountains-of-c-into-safe-rust-with-ai/5290959), мета проєкту — скоротити кількість вразливостей, пов'язаних із керуванням пам'яттю, у системному програмному забезпеченні, де C залишається домінантною мовою вже понад пів століття. Для індустрії це не косметичний жест. C і C++ досі керують ядрами операційних систем, мережевими стеками та драйверами — і саме там регулярно знаходять критичні вразливості класу use-after-free чи buffer overflow. Ручне переписування таких кодових баз на Rust коштує мільйонів людино-годин, тому «великий рефакторинг» довго залишався теоретично правильним, але практично недосяжним рішенням для більшості команд. Участь Canonical додає ініціативі ваги не через розмір компанії, а через характер її кодової бази: Ubuntu — один з найпоширеніших дистрибутивів Linux, тобто величезний масив реального, бойового C-коду, на якому можна перевірити, чи працює автоматичний переклад за межами лабораторних прикладів. ## Що саме змінює участь Canonical? Canonical постачає інфраструктуру й реальний тестовий полігон — компанія підтримує критичні системні компоненти, від інсталятора до утиліт нижнього рівня, написані на C. Це саме той тип коду, де memory-safety баги найдорожчі: помилка в драйвері чи в парсері мережевого пакета конвертується у CVE з високим рейтингом критичності набагато частіше, ніж баг у прикладному застосунку. Долучення великого дистрибутора Linux до такої ініціативи також сигналізує ринку: AI-переклад C-в-Rust переходить зі стадії дослідницького експерименту в стадію, де серйозні гравці готові виділяти на нього інженерний час і ставити на кін частину власної інфраструктури. ## Чому переписати C на Rust вручну — це роками пекла? Проблема не в синтаксисі — вона в семантиці. Rust вимагає явного опису володіння пам'яттю (ownership), а C-код десятиліттями покладався на неявні контракти, які тримаються в головах авторів, а не в самому коді. Перенести такий контракт вручну означає: - Заново реконструювати, хто «володіє» кожним шматком пам'яті та коли він звільняється - Знайти всі місця, де код покладається на undefined behavior, яке компілятор C мовчки пропускав - Переписати тести так, щоб вони ловили регресії, а не просто повторювали старі припущення - Зберегти продуктивність — наївний Rust-переклад легко програє оптимізованому C Саме тому попередні спроби масової міграції (наприклад, окремі підсистеми ядра Linux) просувалися повільно й вручну, модуль за модулем, роками. ## Де AI справді допомагає, а де ризикує? AI-модель непогано впорається з механічною частиною — трансляцією структур даних, циклів, базових конструкцій. Складніше з тим, що не описано явно в самому коді: припущеннями про виклики ззовні, порядком ініціалізації, специфічними для платформи хаками. Тут ризик не в тому, що переклад не скомпілюється, а в тому, що він скомпілюється, пройде поверхневі тести — і збереже прихований баг у новій, «безпечній» формі. Практичний висновок для будь-кого, хто планує подібний підхід: AI-переклад корисний тільки в парі з жорсткою верифікацією — differential testing проти оригінального C-бінарника, fuzzing нової Rust-версії та людський рев'ю критичних ділянок, а не сліпа довіра до факту, що код компілюється. ## Висновок AiiN: економіка модернізації міняється першою, а не безпека Найцікавіше в цьому кроці — не безпека сама по собі, а економіка. Компанії роками відкладали міграцію legacy C-коду не тому, що не розуміли ризиків, а тому, що вартість ручного переписування не окуплялася бюджетом жодного кварталу. Якщо AI-переклад справді знижує вартість першого проходу навіть на 50-70%, а решту закриває верифікація, поріг рішення «переписувати чи ні» зсувається для тисяч команд одночасно — не лише для операційних систем, а для будь-якого legacy-стеку, де ціна вразливості вища за ціну міграції. Це ключова відмінність від попередніх спроб «AI напише вам код»: тут AI не вигадує нову логіку, а зберігає стару поведінку в безпечнішій формі, що набагато легше верифікувати. ## Що таке пам'яттю-безпечна мова і чому це важливо? Пам'яттю-безпечна мова — це мова програмування, яка на рівні компілятора або рантайму не дозволяє класичні помилки роботи з пам'яттю: звернення до звільненої ділянки, вихід за межі буфера, подвійне звільнення. Rust забезпечує це через систему володіння (ownership) і перевірку позичань (borrow checker) без збирача сміття, тоді як C залишає всю відповідальність на розробникові. ## Чи означає це, що C зникне з системного ПЗ? Ні, і найближчими роками точно ні. Мова йде про поступову заміну найризикованіших ділянок коду, а не про одномоментну заміну всієї екосистеми — C десятиліттями лишатиметься частиною системного стеку паралельно з Rust-компонентами. --- Теги: AI, Rust, Canonical, кібербезпека, legacycode, Ubuntu Джерело: AiiN — https://aiin.news/article?slug=canonical-%D0%BF%D0%B5%D1%80%D0%B5%D0%BF%D0%B8%D1%81%D1%83%D1%94-c-%D0%BD%D0%B0-rust-%D0%B7%D0%B0-%D0%B4%D0%BE%D0%BF%D0%BE%D0%BC%D0%BE%D0%B3%D0%BE%D1%8E-ai-%D1%89%D0%BE-%D1%86%D0%B5-%D0%B7%D0%BC%D1%96%D0%BD%D1%8E%D1%94. Цитуючи, посилайтесь на канонічний URL.