Розробка на Rust в 4 рази легша за розробку на C++

[Володимир Лісівка]

Результати проведеного дослідження на коді Android показали, що зміни, внесені в коді на Раст, відкочуються в 4 рази рідше, ніж зміни в коді Сі++. Не дивно, що в 2025 розробники на Раст вперше обігнали розробників на Сі++ по кількості змін у коді.



Звіт: https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html

[BeSiDa]

І на що це вказує?
Їздити по рейках потягом легше ніж автомобілем по всіх видах доріг і без доріг
Але рейки поки не всюди...

Графік не містить інформації про кількість людей та їх досвід... Якщо це період "фанатів" то вони більше хочуть розбиратися в мові програмування, а коли то буде період "масовки" то все буде таке саме. Тільки сутність помилок стане іншою.

Та й взагалі слова "легше" не існує, є лише "легше та швидше для певної людини". Наприклад, для вас особисто І це не може бути "не правдою". А для ОС то все "бінарники" ))

[Володимир Лісівка]

І на що це вказує?
Їздити по рейках потягом легше ніж автомобілем по всіх видах доріг і без доріг
Але рейки поки не всюди...

Це означає економію часу, а отже і економію грошей для Ґуґла.

Графік не містить інформації про кількість людей та їхній досвід...

Програмістів на Расті менше чим на Сі++, але вони написали більше коду. Я думаю, що досвід програмістів в Ґуґлі приблизно однаковий.

[yvs115]

Наскільки я розумію, у великих галерних структурах важко відслідити якість коду, тому бити растом по рукам ті мульйони на галерах - має сенс, щоб менше багів отримувати на виході тим програмуванням.
А взагалі то вже є різні випадки зі спробами його впровадження - починаючи від firefox що ще досі щось пробують переписати і не дуже далеко зайшли з тим, так і до відносно невеличких проектів як нп "sudo-rs Affected By Multiple Security Vulnerabilities" https://www.phoronix.com/news/sudo-rs-security-ubuntu-25.10

[Володимир Лісівка]

А взагалі то вже є різні випадки зі спробами його впровадження - починаючи від firefox що ще досі щось пробують переписати і не дуже далеко зайшли з тим, так і до відносно невеличких проектів як нп "sudo-rs Affected By Multiple Security Vulnerabilities" https://www.phoronix.com/news/sudo-rs-security-ubuntu-25.10

Firefox перейшов на Quantum (їхній двигун на Расті) у 2017-му, він у два рази швидший за стару версію на Сі++: https://blog.mozilla.org/en/mozilla/introducing-firefox-quantum/

Вразливості у sudo-rs — це логічні помилки: 1) не того користувача записували в журнал (записували того, хто запустив, а не того, хто аутентифікувався), та 2) не стирало пароль з екрана, коли увімкнена опція показувати пароль при наборі, у випадку ненормального завершення програми (хтось інший може потім подивитися на екран і побачити пароль). Ніяка мова програмування не захищає від таких помилок.

[yvs115]

А взагалі то вже є різні випадки зі спробами його впровадження - починаючи від firefox що ще досі щось пробують переписати і не дуже далеко зайшли з тим, так і до відносно невеличких проектів як нп "sudo-rs Affected By Multiple Security Vulnerabilities" https://www.phoronix.com/news/sudo-rs-security-ubuntu-25.10

Firefox перейшов на Quantum (їхній двигун на Расті) у 2017-му, він у два рази швидший за стару версію на Сі++: https://blog.mozilla.org/en/mozilla/introducing-firefox-quantum/

може в 2017му і перейшов, але зараз якщо того не видно (мабуть щось залишилося в секціїї other 5%) - то що виходить відмовилися від раст?
JavaScript 28.7%
C++ 28.0%
HTML 21.9%
C 10.4%
Python 2.9%
Kotlin 2.7%
Other 5.4%
https://github.com/mozilla-firefox/firefox

Вразливості у sudo-rs — це логічні помилки: 1) не того користувача записували в журнал (записували того, хто запустив, а не того, хто аутентифікувався), та 2) не стирало пароль з екрана, коли увімкнена опція показувати пароль при наборі, у випадку ненормального завершення програми (хтось інший може потім подивитися на екран і побачити пароль). Ніяка мова програмування не захищає від таких помилок.

якого типу помилки для користувача не дуже відіграють роль, нп як приклад - як тільки в 25.10 дефолтні coreutils переключили на раст версію - у мене на десктопі почали вискакувати віконечка щоб отрепортити з backtrace - тому просто переключив на gnu coreutils і працював далі

[DalekiyObriy]

https://4e6.github.io/firefox-lang-stats/

4,7 млн рядків коду ядра на Rust, тобто десь чверть

[DalekiyObriy]

Тип найчастіших помилок в C/C++ що викликають головні CVE:

1. Buffer Overflow (stack/heap)

Що це: запис за межі масиву або буфера.
Наслідки: RCE (remote code execution), підвищення привілеїв.
...
Це №1 джерело серйозних CVE протягом десятиліть.

2. Use-After-Free (UAF)

Що це: використання пам’яті після її звільнення (free, delete).
...
Один із найтиповіших експлойтів у браузерах (Chrome/Firefox), PDF-рендерах, графічних драйверах.

3. Double Free

Що це: повторний виклик free() щодо одного й того ж блоку пам’яті.
Наслідки: корупція heap-структур → можливий контроль над heap.

4. Null Pointer Dereference

Зазвичай призводить до краху, але в драйверах чи ядрах може викликати privilege escalation.

6. Out-of-Bounds Read/Write

Не обовʼязково прямий overflow.
...
OOB-read часто стає інфо-витоком (info leak) — дуже важливим кроком для реальних експлойтів.


7. Race Conditions
...
У ядрах (Linux, Windows) це одне з найсерйозніших джерел CVE.

8. Uninitialized Memory Use
...
У криптобібліотеках це може призводити до витоку ключів.

і т.ін.

Тобто основні джерела проблем безпеки в софті на C/C++ не є дозволеними в Rust (без зайвих хитрощів звичайно).
Якщо уявити скільки головняка мають компанії (й не лише софтові) з запобіганням цим CVE або, що гірше, у боротьбі з наслідками, то міграція на Rust — цілком логічний і правильний рух.

[yvs115]

тобто десь чверть

Якісь незрозумілі порівняння розмірами...)
- з однієї сторони маємо - чи чверть, чи 12 на діаграмі, і т.п. від раст фан чи блогерів
- з іншої - проценти від алгоритмів які використані на github.com в секції languages по офіційному репозіторію

Нехай навіть той десяток процентів від раст-оптимістів буде, за років 10. Тобто зарастять весь проект за 50-100 років по оптимальним цифрам? Так він за той час поржавіє вже і сам. І це в компанії яка створила раст для вирішення проблем з кодуванням на плюсах на своїй галері. Тобто доволі показовий кейс.

основні джерела проблем безпеки ... не є дозволеними в Rust (без зайвих хитрощів звичайно)

sudo-rs якраз відносно проблем безпеки (як ви назвете їх логічно-безпечними нелогічно-безпечними логічно-небезпечними і т.п. - для користувачів ролі не відіграє - якщо вони є), і тоді виходить що там раст кодери переписуючи код цієї тулзи достатньо "нахитрили" (за вашою термінологією) що з'явилися нові додаткові security vulnerabilities?

міграція на Rust — цілком логічний і правильний рух

ніяк не применшуючи плюси що надає відносно нова-ненова мова програмування така як раст - тим не менш скрізь є трейдофи, у цьому випадку також достатньо щоб не узагальнювати

[Володимир Лісівка]

тобто десь чверть

Якісь незрозумілі порівняння розмірами...)
- з однієї сторони маємо - чи чверть, чи 12 на діаграмі, і т.п. від раст фан чи блогерів
- з іншої - проценти від алгоритмів які використані на github.com в секції languages по офіційному репозіторію

На Расті приблизно стільки ж коду як на Сі і в половину менше коду чим на Сі++, решта коду це JS, HTML, CSS, Python і так далі. Фундація Мозілли звільнила програмістів на Раст в 2020-му році через внутрішні конфлікти.

Нехай навіть той десяток процентів від раст-оптимістів буде, за років 10. Тобто зарастять весь проект за 50-100 років по оптимальним цифрам?

Там ніколи не буде 100%. Максимум — перепишуть весь код на Сі та Сі++ під Раст. Але якщо код вже написаний, добре відлагоджений за роки, і проблем не створює, то навіщо його переписувати? От ffmpeg було б добре переписати, бо там понад тисячу вразливостей знайшли.

sudo-rs якраз відносно проблем безпеки (як ви назвете їх логічно-безпечними нелогічно-безпечними логічно-небезпечними і т.п. - для користувачів ролі не відіграє - якщо вони є), і тоді виходить що там раст кодери переписуючи код цієї тулзи нахитрили достатньо що з'явилися нові додаткові security vulnerabilities?

Саме так, при написані коду люди часто помиляються. Не помиляється той, хто нічого не робить. Але кількість помилок та їхня серйозність значно менші при написанні на Раст чим на Сі та Сі++.

ніяк не применшуючи плюси що надає відносно нова-ненова мова програмування така як раст - тим не менш скрізь є трейдофи, у цьому випадку також достатньо щоб не узагальнювати

Компроміси ніхто не приховує — за вищу надійність потрібно платити довшим циклом навчання програмістів порівняно з Сі, та довшими циклами компіляції. Якщо Пітон можна вчити в школі, бо він простий, то Раст вчать і використовують здебільшого професійні програмісти, так само як і Сі++.

Крім того, Раст вже не нова мова програмування. Я використовую Rust з версії 1.0, яка була випущена у 2015-му, 10 років тому. А до того ще був довгий цикл альф та бет.

[yvs115]

firefox etc.

На Расті приблизно стільки ж коду як на Сі і в половину менше коду чим на Сі++

github секція languages по офіційному firefox репо схоже з цим "приблизно стільки ж" не погоджується
(https://github.com/mozilla-firefox/firefox/)

за вищу надійність потрібно платити довшим циклом навчання програмістів порівняно з Сі, та довшими циклами компіляції

Не тільки цим, а з окремим виділенням складності раст програмування можна погодитись (приклад напевно може і firefox бути). В цілому - деякий тип помилок, чи десь щось недогледів, по ідеї очікували вирішити за допомогою додаткових засобів вбудованих напряму в мову програмування, але те що чи недостатній рівень expertise поза мовою програмування, чи мовна складність, чи ще щось не зовсім ясно що саме з тим пов'язано, - на практиці (приклади з coreutils-rs sudo-rs) призводить до появи помилок в інших місцях там де і не очікували.

Якщо Пітон можна вчити в школі, бо він простий, то Раст

Думаю що це один з основних недоліків раст, бо мова чим простіша тим легше її використовувати, тому тренд з овер-ускладненням багато хто вважає контрпродуктивним. І тому саме (точніше - як одна з причин і цілей впровадження) нп для широкої бази пайтон програмерів з'явився mojo (який доречі з borrow checker) з плавним переходом від чисто пайтон коду, замість нп раст використання.

Якщо поза пайтоном - то періодично продивляюсь які нові зручні мови з'являються без legacy старих мов програмування, і один із критеріїв - наскільки легко-зручно мені програмувати з відповідною мовою, і такі потрохи з'являються незважаючи на покищо відсутність підтримки від bigtech.

[Володимир Лісівка]

firefox etc.

На Расті приблизно стільки ж коду як на Сі і в половину менше коду чим на Сі++

github секція languages по офіційному firefox репо схоже з цим "приблизно стільки ж" не погоджується
(https://github.com/mozilla-firefox/firefox/)

Ну подивіться тут статистику тоді: https://optiklab.github.io/browsers-lang-stats/ , там і для Chromium статистика є.

Не тільки цим, а з окремим виділенням складності раст програмування можна погодитись (приклад напевно може і firefox бути). В цілому - деякий тип помилок, чи десь щось недогледів, по ідеї очікували вирішити за допомогою додаткових засобів вбудованих напряму в мову програмування, але те що чи недостатній рівень expertise поза мовою програмування, чи мовна складність, чи ще щось не зовсім ясно що саме з тим пов'язано, - на практиці (приклади з coreutils-rs sudo-rs) призводить до появи помилок в інших місцях там де і не очікували.

Так, але в результаті помилок значно менше. І працювати з Растом значно легше ніж Сі (а тим більше Cі++) + Valgrind, чи інший валідатор коду. Раст пише про проблему ще на етапі компіляції.

Думаю що це один з основних недоліків раст, бо мова чим простіша тим легше її використовувати, тому тренд з овер-ускладненням багато хто вважає контрпродуктивним.

Раст поки що значно простіший за Сі++, але мені теж не подобається, коли починають ускладнювати. Але розробники знають про цю проблему, і працюють над спрощенням деяких аспектів мови. Наприклад валідатор позичань став ще розумнішим (переписують вже четвертий раз, здається).
Ніхто ж не забороняє використовувати інші мови програмування. У Раст своя ніша, в якій він успішно витісняє Сі та Сі++, у Пітона — своя.

І тому саме (точніше - як одна з причин і цілей впровадження) нп для широкої бази пайтон програмерів з'явився mojo (який доречі з borrow checker) з плавним переходом від чисто пайтон коду, замість нп раст використання.

Не чув про mojo. Виглядає перспективно, але проєкт із закритим кодом.

[yvs115]

На Расті приблизно стільки ж коду як на Сі і в половину менше коду чим на Сі++

github секція languages по офіційному firefox репо схоже з цим "приблизно стільки ж" не погоджується
(https://github.com/mozilla-firefox/firefox/)

Ну подивіться тут статистику тоді: https://optiklab.github.io/browsers-lang-stats/ , там і для Chromium статистика є.

(1) github.io хостить персональні чи прожект сторінки, (2) github.com використовує не пов'язані з раст тулзи для тих вимірювань
тому цифри від github.com/languages виглядають більш reliable як на мене

Не тільки цим, а з окремим виділенням складності раст програмування можна погодитись (приклад напевно може і firefox бути). В цілому - деякий тип помилок, чи десь щось недогледів, по ідеї очікували вирішити за допомогою додаткових засобів вбудованих напряму в мову програмування, але те що чи недостатній рівень expertise поза мовою програмування, чи мовна складність, чи ще щось не зовсім ясно що саме з тим пов'язано, - на практиці (приклади з coreutils-rs sudo-rs) призводить до появи помилок в інших місцях там де і не очікували.

Так, але в результаті помилок значно менше. І працювати з Растом значно легше ніж Сі (а тим більше Cі++) + Valgrind, чи інший валідатор коду. Раст пише про проблему ще на етапі компіляції.

працювати з раст важче ніж з сі, тобто більш загальний погляд що "C is generally considered simpler", що збігається з моїм

Думаю що це один з основних недоліків раст, бо мова чим простіша тим легше її використовувати, тому тренд з овер-ускладненням багато хто вважає контрпродуктивним.

Раст поки що значно простіший за Сі++, але мені теж не подобається, коли починають ускладнювати. Але розробники знають про цю проблему, і працюють над спрощенням деяких аспектів мови. Наприклад валідатор позичань став ще розумнішим (переписують вже четвертий раз, здається).

я не дуже займаюсь плюсами, а те що в принципі раст і створювався як заміна для кодування на плюсах, тому не дивно що складність можна порівнювати з плюсовою

І тому саме (точніше - як одна з причин і цілей впровадження) нп для широкої бази пайтон програмерів з'явився mojo (який доречі з borrow checker) з плавним переходом від чисто пайтон коду, замість нп раст використання.

Не чув про mojo. Виглядає перспективно, але проєкт із закритим кодом.

Тенденція go/dart/rust/... коли мови створюються в рамках компаній для їх потреб, а потім можливо віддаються в коммюніті чи ні, це окремий аспект.
А взагалі то існують нові open-source мови, доволі цікаві швидкі прості достатньо надійні і т.п., єдине що покищо з невеликими комюніті та недостатньо обросли всім що треба, які з них стануть достатньо популярні - буде видно.

[Володимир Лісівка]

працювати з раст важче ніж з сі, тобто більш загальний погляд що "C is generally considered simpler", що збігається з моїм

Навчитися писати програми на Расті важче чим на Сі. Написати надійну програму на Расті в 4 рази легше ніж на Сі. Писав надійний код і на Сі і на Раст. Надійний код на Сі взагалі не схожий на типовий код на Сі.

[yvs115]

Так, але в результаті помилок значно менше. І працювати з Растом значно легше ніж Сі (а тим більше Cі++)

працювати з раст важче ніж з сі, тобто більш загальний погляд що "C is generally considered simpler", що збігається з моїм

Навчитися писати програми на Расті важче чим на Сі. Написати надійну програму на Расті в 4 рази легше ніж на Сі.

"N" з "в N разів" важче-чи-легше залишимо як повністю суб'єктивно-узагальнюче бачення разів у будь-яку сторону.
В кінці кінців на виході все показує практика ("надійність" як нп з переписуванням coreutils чи sudo, і як там можна було додати свої "safe"-помилки переписуючи обкатаний роками код незважаючи на всі вбудовані запобіжники, чи "легкість" переписування файрфокса десятками років, etc), і це навіть якщо не розглядати трейдофи при виборі рішення. Будуть інші приклади впровадження які можна буде самому покористуватися на практиці - можна буде відкоректувати свої суб'єктивні судження відносно відповідного кодування якщо суттєво щось зміниться, а покищо такі як є на базі прикладів які вже є.