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

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

"N" з "в N разів" важче-чи-легше залишимо як повністю суб'єктивно-узагальнюче бачення разів у будь-яку сторону.

Власне це вже обʼєктивні дані отримані в результаті дослідження великого проєкту за 6 років, а не субʼєктивні дані. В цьому ж суть новини. Дослідження показали що на Расті в 4 рази легше програмувати, чим на Сі++, при однакових інших показниках.

Цитата (перекладено aya-expanse:32b-q4_K_S):

Для середніх і великих змін частота відкату змін Rust в Android приблизно у 4 рази нижча, ніж у C++. Така низька частота відкату не лише вказує на стабільність, але й активно покращує загальну продуктивність розробки. Відкат змін є високодеструктивним для продуктивності, створюючи організаційні тертя та мобілізуючи ресурси далеко за межами розробника, який подав несправну зміну. Відкати вимагають повторної роботи та додаткових кодових рецензій, можуть також призвести до повторного створення збірок, післяаварійних аналізів та блокування інших команд. Результуючі післяаварійні аналізи часто вводять нові захисні заходи, які додають ще більше перевантаження розробкою.

У самозвітному опитуванні 2022 року програмісти Google повідомили, що Rust легший для рецензування та ймовірність його правильності вища. Тверді дані про частоту відкату та час рецензування підтверджує ці враження.

[yvs115]

І працювати з Растом значно легше ніж Сі

vs

Для середніх і великих змін частота відкату змін Rust в Android приблизно у 4 рази нижча, ніж у C++

Так тут мова про різні речі (легкість і частота чогось), і навіть мови інші (раст і плюси, то зовсім не сі), і все то на твердженні для андроїда.
Заперечень до "C is generally considered simpler" у порівняні з раст не побачив... навіть у часткових замірах чогось компанії з раст промошен, не кажучи про узагальнення.

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

І працювати з Растом значно легше ніж Сі

vs

Для середніх і великих змін частота відкату змін Rust в Android приблизно у 4 рази нижча, ніж у C++

Так тут мова про різні речі (легкість і частота чогось), і навіть мови інші (раст і плюси, то зовсім не сі), і все то на твердженні для андроїда.

Ну так «програмувати» та «працювати» — це теж різні слова.

Заперечень до "C is generally considered simpler" у порівняні з раст не побачив... навіть у часткових замірах чогось компанії з раст промошен, не кажучи про узагальнення.

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

Сі складний у роботі, через ручне керування памʼяттю, через відсутність обʼєктно-орієнтованого програмування, через погану обробку помилок, через квадратичну складність при роботі з текстами, через застарілі інтерфейси які розраховані на однопоточну модель, і так далі. Це можна виправити (Ява на Сі написана), але тоді Сі перестає бути Сі.

[yvs115]

І працювати з Растом значно легше ніж Сі

vs

Для середніх і великих змін частота відкату змін Rust в Android приблизно у 4 рази нижча, ніж у C++

Так тут мова про різні речі (легкість і частота чогось), і навіть мови інші (раст і плюси, то зовсім не сі), і все то на твердженні для андроїда.

Ну так «програмувати» та «працювати» — це теж різні слова.

C is generally considered simpler так і залишається.

Заперечень до "C is generally considered simpler" у порівняні з раст не побачив... навіть у часткових замірах чогось компанії з раст промошен, не кажучи про узагальнення.

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

дає серйозний приріст у продуктивності порівняно ... ніж на Сі

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

Сі складний у роботі, через ручне керування памʼяттю, через відсутність обʼєктно-орієнтованого програмування, через погану обробку помилок, через квадратичну складність при роботі з текстами, через застарілі інтерфейси які розраховані на однопоточну модель, і так далі.

і в цілому враховуючи всі плюси та мінуси залишається зручнішим в більшості випадків по практиці які у мене були

p.s.

Це можна виправити (Ява ...)

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

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

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

Ні, не говорить. Наведіть дослідження, які це підтверджують. Наприклад дослідження Ади проти Сі в 94-му показали що один рядок коду на Сі у півтора рази дорожчий за рядок коду на Аді ($10.52 проти $6.52), в той же час помилок в коді на Аді було допущено приблизно у 8 разів менше чим в коді на Сі (122 проти 1020).

Код: [Вибрати]

(Up to Oct. 15, 1994)

                    C_FILE     ADA_FILE   SCRIPT_FILE  OTHER_FILE    TOTALS   

all_lines:          1925523     1883751      117964      604078      4531316   

SLOC:               1508695     1272771      117964      604078      3503508   

files:               6057        9385         2815        3653        21910   

updates:             47775       34516       12963        12189      107443   

new_features:        26483       23031        5594        6145        61253   

Fixes:               13890       5841         4603        1058        25392   

Fixes/feature:        .52         .25         .82          .17         .41     

Fixes/KSLOC:         9.21        4.59        39.02        1.75        7.25     

devel_cost:       $15,873,508 $8,446,812   $1,814,610  $2,254,982  $28,389,856

cost/SLOC:          $10.52       $6.62       $15.38       $3.72       $8.10   

defects:             1020         122         (A)          (B)        1242     

defects/KSLOC:       .676        .096         (A)          (B)        .355     


і в цілому враховуючи всі плюси та мінуси залишається зручнішим в більшості випадків по практиці які у мене були

Дослідження показують, щоб зараз більшість мов програмування показують себе добре на проєктах довжиною від 4 до 8 місяців, а от пізніше починаються проблеми, які є різними для різних типів мов. Тому для маленьких проєктів мова майже не має значення. А от на великих проєктах, Раст демонструє чіткий відрив від конкурентів.



(PO - процедурні мови, ОО - обʼєктно орієнтовані, SL - скрипти, VD — HTML/SQL і т.д.)

[BeSiDa]

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

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

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

[yvs115]

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

Ні, не говорить. Наведіть дослідження, які це підтверджують.

Мої враження складаються з того з чим стикаюсь на практиці (а раст промошен - дивлюсь і просто приймаю до уваги)
З того маємо:
uutils(coreutils-rs) since 2013 (якщо вірити томуж гугл) і досі повністю не переписали, а після того як додали в убунту - про віконця з backtrace вже згадував раніше.
sudo-rs - вище наводив url з phoronix з обговоренням multiple security vulnerabilities.
firefox - mozilla де створили раст, так досі особливо і не продвинулись з раст-переписуванням браузера.

Ще можна було додати кейс з orphaned (після міграціїї на раст) bcachefs-tools в дебіан при появі maintenance-проблем, але це так на додаток поза тим що використовую.

Наприклад дослідження Ади проти Сі в 94-му показали що один рядок коду на Сі у півтора рази дорожчий за рядок коду на Аді ($10.52 проти $6.52), в той же час помилок в коді на Аді було допущено приблизно у 8 разів менше чим в коді на Сі (122 проти 1020).

ada назараз цікавить ще менш ніж джава

і в цілому враховуючи всі плюси та мінуси залишається зручнішим в більшості випадків по практиці які у мене були

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

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

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

Мої враження складаються з того з чим стикаюсь на практиці (а раст промошен - дивлюсь і просто приймаю до уваги)
З того маємо:
uutils(coreutils-rs) since 2013 (якщо вірити томуж гугл) і досі повністю не переписали, а після того як додали в убунту - про віконця з backtrace вже згадував раніше.

Не переписали повністю тому що авторів коду влаштовує наявний код, вони не на зарплаті. Busybox теж не переписав coreutils повністю. Помилки є і будуть, coreutils теж не за один день написали і без помилок.

sudo-rs - вище наводив url з phoronix з обговоренням multiple security vulnerabilities.

Це вже обговорювали.

firefox - mozilla де створили раст, так досі особливо і не продвинулись з раст-переписуванням браузера.

Переписують firefox в проєкті servo, а firefox бере звідти вже готові частини. Сам servo ще сирий, але linux.org.ua він вже показує нормально. По статистиці для Вогнелиса, наведеній вище, код на Расті вже займає 1/3 від коду на Сі та Сі++. Хроміум відстає трохи.

Ще можна було додати кейс з orphaned (після міграціїї на раст) bcachefs-tools в дебіан при появі maintenance-проблем, але це так на додаток поза тим що використовую.

У Федорі, десятки покинутих пакетів викидують щомісяця. Деякі з них теж написані на Расті. Розробники нікому нічого не винні.

ada назараз цікавить ще менш ніж джава

Мене теж, але DoD використовує Аду саме тому, що працювати на ній в два рази легше чим на Сі. А Раст переплюнув і Аду.

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

Там тільки зарплата CEO іде в ногу з часом, а все інше — падає.

[ps]

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

Звісно, в матьорих сішників є купа напрацьованого інструментарію з відладки до компіляції релізу. Але для новачків - Rust надає супер-сувору перевірку логіки і успадковування сутностей пам'яті. Від того ще в процесі створення програми, частина косяків просто відсіюється і якщо аналайзер не свариться - з вірогідністю 99% програма збереться будь де і не впаде на продакшні через логічні помилки типу подвійного вивільнення пам'яті, плутанини з null та обслуговуючими їх контейнерами, яких там анархічний мільйон.

[BeSiDa]

... з вірогідністю 99% програма збереться будь де і не впаде на продакшні через логічні помилки типу подвійного вивільнення пам'яті, плутанини з null та обслуговуючими їх контейнерами, яких там анархічний мільйон.

+

... про віконця з backtrace вже згадував раніше.

(з точки зору користувача "впала", але ... з інших причин)

Це схоже на перекладання проблем з одних людей (девів) на інших (користувачів).
Бо раніше користувач хоч в деяких випадках міг зробити свою задачу (хоч програма і глючила), а тепер не може бо її завершують ще до того як вона зробила корисне користувачу (бо вже натиснула на приховану перевірку глюку)

[BeSiDa]

Ні, не говорить. Наведіть дослідження, які це підтверджують. Наприклад дослідження Ади проти Сі в 94-му показали що один рядок коду на Сі у півтора рази дорожчий за рядок коду на Аді ($10.52 проти $6.52), в той же час помилок в коді на Аді було допущено приблизно у 8 разів менше чим в коді на Сі (122 проти 1020).

Цей аргумент підсвідомо оминає знання про те "чи вміли ті програмісти на Аді так само й Сі"?
Тобто ви робите вигляд що "Ади достатньо", але замість того у реальності могло бути "потрібні люди що 10 років вчилися Сі, а лише після того вивчили Ада
І то вже зовсім інша картина...
А для "вчитися" повинен бути не "тест", а "реальний корисний багатьом людям проект на Сі з реальними багами що псують життя мільйонам людей з програмою на Сі". І лише після того Ада стає (для того досвіду) корисною ))

[BeSiDa]

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

А навіщо вам якісь там гітхаби, у вас що немає інсталяції Файерфокс? Не можете з ліб-ксул.со вибрати "стрічки тексту" та зних все з закінченням .рс та з папкою /срц/ і /раст/?  Там дофіга

І до того ж чому ви відсотки коду берете, а не відсотки часу чи викликів-дій який користувач використовує частіше? Може бути що там коду раст мало, але той код відображення графіки з 60 кадрів в секунду чи нетворк. А іншого багато, але то дев-тулз якими 1% користується 1% часу ))

[BeSiDa]

Та й взагалі ви ж розумієте що це не того рівня порівняння?

Що С і С++ не однакового рівня. С створено для "одного єдиного процесу" який запущений в межах ОС одним користувачем (де є й інші процеси).
А от С++ це "багато об'єктів" що фактично є аналогом "багато процесів" тільки вже ... "замість ОС в одного користувача".

Тобто С++ перебрала на себе те що робила ОС. Тому виходять монстри що постійно в пам'яті висять замість тулзів що завершуються.

А от Раст це ... "вся опереційна система", бо там не тільки об'єкти ("процеси" ОС), але й _А_ктори (окремі користувачі-сутності ОС).
Але ... вся ОС у одному бінарнику

[BeSiDa]

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

Це дуже поганий підхід. Фактично ви кажете "мені зручно", що те саме що "я вже вивчив більшу частину тієї мови, хоч вона і нова бо ... вона насправді застаріла" (тобто складається з того що ви й так знаєте, а отже зі "старого") )))

Замість того щоб обирати "найбільш не зручне" бо ви "гадки не маєте навіщо вони так зробили" (але ж вони щось тим хотіли вирішити!) і лише після того як ви вивчите те "нове" ви зможете казати "от тепер я розумію що мова зручна" ))

А без того в розробників мови є потреба вас ... обманути! Щоб вам здалося що "воно таке як ви знаєте" (і ви почали нею користуватися та виконувати реальні задачі), а лише потім (через рік чи 5, чи 10 ви зрозуміли що то зовсім інша нова мова от тільки те дуже ретельно від вас сховали ))

Так було з "С++ дуже схоже на С (навіть можете і без об'єктів писати)".  Чи Джаваскрипт дуже схожий на Сі

[BeSiDa]

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

))
Це ж не про ефективність "мови програмування", а про "ефективність монстрів-заплутаних-мамонтів що харчуються програмістами" )) Не про те "чи швидко трава росте" (програмувати), а "чи швидко зубами траву перетерти та перетравити" (менеджмент).

Так би й писали що "Раст то ідеальний засіб створити з людини перетерту кашицю без комочків" ))