Canonical, компанія-розробник Ubuntu, приєдналася до ініціативи, яка використовує штучний інтелект для масового перекладу коду з мови C у Rust. За даними The Register AI, мета проєкту — скоротити кількість вразливостей, пов'язаних із керуванням пам'яттю, у системному програмному забезпеченні, де 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-код десятиліттями покладався на неявні контракти, які тримаються в головах авторів, а не в самому коді. Перенести такий контракт вручну означає:

Саме тому попередні спроби масової міграції (наприклад, окремі підсистеми ядра 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-компонентами.