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

[BeSiDa]

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

Як на мене це не про "мову", а про те що дуже багато хто використовує "код" для "зберігання знань"   І саме тому для них проблема "переписати іншою мовою", бо "знання є в коді, а в головах вони втрачені" (чи люди пішли, чи перемішалося, чи ще щось).
Такого немає коли є хоч одна голова в якій міститься весь проект всі ті роки (хоч основна частина, хребет проекту), або (рідко) є інша база (крім коду та таск-трекерів) що зберігають знання. Знаєте такі бази для знань розробників (з яких можна без коду створити те саме з нуля іншою мовою)?
Мабуть тільки РФЦ по протоколам та іншому ))

[BeSiDa]

Отак і знищуються цивілізації... спочатку "їм роблять легше" (тим, хто сам вміє і знає як "складніше"), потім проходить пару поколінь (коли помирають ті хто знав, та за ними учні тих хто знав і пам'ятав)... і маємо труп всіх!
Чому?
А бо новим ... не цікаво! Як було раніше!
А "легше" для них вже не є аргументом, бо ... а вони гадки не мають "а що було якось інакше чи що"?
І навіщо то було ... і вони ... "викидають зайве" )) ... щоб стало "ще легше" ... поки все не гепнеться.

Спрацьовує тільки "градієнт" стану людини яка видозмінюється "зі складніше в легше".

[yvs115]

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

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

Busybox теж не переписав coreutils повністю.

busybox такої цілі і не має з мінімазіцією зборки, так як і інший софт в ньому з мінімумом функціоналу

Помилки є і будуть, coreutils теж не за один день написали і без помилок

coreutils-rs саме переписували/переписують, а не пишуть заново - тому додати свої помилки у відкатаний іншими софт - то своя окрема заслуга

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

Переписують firefox в проєкті servo,

То окремий проект, тещо файрфокс використовує з нього трохи щось з раст - тим більш говорить наскільки власне переписування на далекій до завершення стадії.
Відносно servo самого - що з'являється з нових браузерів також іноді дивлюсь, десь недавно порівнював функціонал servo та ladybird (ще один з нових на свому движку браузер, плюсовий). По функціоналу навіть до ladybird (який паралельно у часі пишеться) ще далеко як до ...

По статистиці для Вогнелиса, наведеній вище, код на Расті вже займає 1/3 від коду на Сі та Сі++.

раст десь в other 5% по github інфо, тобто скільки від конкретної мови (плюси та інші там окремо бо достатньо коду) - не шукав

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

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

це інший кейс - orphaned після того як зарастили його, наскільки я зрозумів з опису саме за проблеми maintenance раст коду (відсутність стандарту, впевненості його кодерів що збирається значить робить, etc.)

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

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

No idea, навіть вже в 90х не використовував і не бачив щоб хтось з нею працював щоб щось оцінювати реально.

[yvs115]

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

Це (покладання занадто на мову програмування що все зробить окей) і є проблемою, яку особливо відмітили коли заoрфанили bcachefs-tools - невідомо звідки така самовпевненість "збирається значить працює".
І те що щось почало в rust-coreutils падати і чого не було з gnu версією - тому також підтвердження з чим сам також був стикнувся недавно.

[ps]

На мою думку, ця мова як то кажуть юзер-френдлі: вона не дає робити помилки початківцям, а в цьому житті початківці приходять постійно. До них же відношу і себе: я роблю помилки через відсутність досвіду (якого в мене й без того мабуть років 20) або просто через втому чи перегруз інфою.

Rust (зокрема його цілістна екосистема довкола інтегрованого пакетного менеджера cargo і його фіксованих релізів) дозволяє контролювати процес розробки мабуть краще за будь яку іншу відому з мого досвіду мову, якщо говорити про такі що мають прямий доступ до заліза.

Щодо цілістності інфраструктури - тут йдуть стандартні rustfmt і clippy: перший робить уніфікований код і допомагає приборкати хвору фантазію на йменуваннях змінних чи їх розміщенню, який легко читається різними розробниками через "стандартну" стилістику. Другий - виявляє синтаксичні оптимізації від версії до версії, на які не звиртає увагу око через звичку та відсутність часу на впаковування в голову документації останніх оновлень.

Тут наче й нічого нового (окрім делегації ownership і корекції логіки return) але з іншого боку, воно все з коробки - тут не треба ставити якийсь конан, лазити в дебаг у паралельному вікні. Немає файлів заголовків, в які пишуть що завгодно, ділячи прогу навпіл. Якщо ви пишете код з rust-analyzer, це буде повністю робоча, стабільна програма. Інша справа, що сам код можна написати не оптимізовано. Як і у всіх "найвисокорівневіших мовах зпоміж низькорівневих" - тут потрібен досвід. Дійсно, в мене забирає купу часу як розгорнути цикл без зайвих алокацій, як і коли його краще спинити. Але програма буде завжди робочою - це фокус і мета Rust. Я просто в захваті, добровільно на плюси не повернусь нізащо, але так я просто змушений досі писати на плюсах виключно через легасі півсторічної історії розвитку ПК, не більше того.

Для мене C/C++ це скло - яким без майстерних навичок можна легко порізатись, і чи треба то початківціям сьогодні, коли є безпечна альтернатива - вирішувати кожному для себе.

[ps]

Ось, недавно я реалізував кастомні проксі в IRC клієнті Halloy. Це зайняло 5 хвилин часу, буквально!

Головне тут те, що я даю вам 100% гарантію, що це працюватиме в рамках поточної ревізії Git. Чи дав би я таку гарантію в програмі на C? Кожного разу, коли я вношу контрибуції до програм на C/C++ за мною "прибирають" витоки майнтейнери, які знають свої реалізації обгорток, що чистять пам'ять. Мовчу вже як зорієнтуватись в чужому коді, який завжди різний, в якому кілометри рядків і залежностей, які між собою пов'язані людиною а не процесорною логікою.

І стосовно швидкості орієнтування в чужому коді: в Rust - дуже круто реалізована документація:

* // для нотаток
* /// для документації сутностей (що також підтримує md)

Останній формат дозволяє витягати аналайзером inline-документацію з надр залежностей при наведенні мишкою на потрібний фрагмент коду. Це супер-зручно і дуже заощаджує час, запобігаючи втомі від постійної навігації по сплітам вікон. Автоматичні док-сайти - я таким чином не відкриваю взагалі, хоча вони є і створюються автоматично для всіх застосунків щонайменше реєстру cargo. Коли я переходжу в код C, мені там дуже не вистачає цієї коробкової фічі.

[yvs115]

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

На мою думку, ця мова як то кажуть юзер-френдлі: вона не дає робити помилки початківцям

Не дає робити відповідного типу помилки всім (не тільки початківцям), а розпочати працювати важко (steep learning curve), а тим для кого фішки з раст і не потребуються в конкретному софті - все одно бореться з відповідною лімітацією. Тому user-friendly це малоймовірно що булоб сказано про раст.

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

Тренд на пакетний менеджер з мовою програмування все частіше зараз критикують як незручний. Тобто хаос стайл пакетизації типу perl/python/node з такими менеджерами в кінці кінців з'являється і в мовах з вбудованими пакет-менеджерами аля dart/go/rust/etc. Тобто виглядає як боролися з пакетним та ліб хаосом в системі - і прийшли ще до гіршого варіанту - отримали ще більший хаос ніж той який хотіли уникнути, і це незважаючи що доволі часто для запуску софта потребується вже тільки свій рідний environment/runtime.

... Але програма буде завжди робочою - це фокус і мета Rust. Я просто в захваті

про самовевненість та сподівання що все вирішить мова кодування було вище

Для мене C/C++

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

Головне тут те, що я даю вам 100% гарантію, що це працюватиме в рамках поточної ревізії Git

Відсутність стандартизації тут гарантовано 100% недолік, тобто порівняємо нп з сі - булоб щось на зразок код відповідно стандарту c99.
А тут нп умовному мейнтейнеру ще прийдеться боротися як то з "поточною ревізією git" все то підтримувати.

Одним словом значну частину з того що було надано як "у захваті від" можно розглядати як раст антирекламу)

[ps]

Виглядає як склеїні частини з різних чогось

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

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

Звісно різні, якщо C++ це по суті обгортка для C, при чому зібрана з усього на світі з наміром його стандартизувати від версії до версії.
ось зроблять стандартним безпечний для пам'яті аналізатор... через років так п'ять чи коли там вийде черговий std

А тут нп умовному мейнтейнеру ще прийдеться боротися як то з "поточною ревізією git" все то підтримувати.

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

Одним словом значну частину з того що було надано як "у захваті від" можно розглядати як раст антирекламу)

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

[ps]

Відсутність стандартизації тут гарантовано 100% недолік, тобто порівняємо нп з сі - булоб щось на зразок код відповідно стандарту c99.
А тут нп умовному мейнтейнеру ще прийдеться боротися як то з "поточною ревізією git" все то підтримувати.

Чекайте но, якої саме стандартизації не вистачає в Rust? До кожної програми і її залежностей вказується версія компілятора 2021, 2024 і тд. Довкола цієї версії будується стандартний набір бібліотек (std) та інші компоненти. Допоки програма використовує вказану версію у своєму Cargo.toml ні з чим боротися не потрібно, її залежності можуть використовувати інші версії, все цілісно пов'язано між собою як і в будь якому пакетному менеджері, якого з коробки в C/C++ немає, зате є купа 3-паті у кожного пакунку своя система збірки.

[kostiantyn.hermash]

Мені, як людині, яка вивчала C і C++, код на rust виглядає некрасиво, незрозуміло і дуже дивно.

Люди, які пропагують раст такі фанатичні, і чомусь нагадують мені фанатиків системГ і ленарта поцтерінга. Вони хочуть зламати все, що будувалося десятиліттями, та збільшити хаос і так в хаотичному світі GNU/Linux. Пхають свій пакетний менеджер cargo всюди. Навіщо мені в Дебіані ще один пакетний менеджер? В мене вже є dpkg і apt, і вони чудово працюють.

Також в цій темі чомусь не піднімалося питання того, що за раст стоїть комерційна контора --- Mozilla. Світ вільного програмного забезпечення не може покладатися на комерційні компанії, це протирічить вченню Річарда Столмана і взагалі ідеології Free Software.

А ось для мов C/C++ існують вільні реалізації від GNU.

Якщо буде раст від GNU, можна буде на нього подивитися.

[yvs115]

Відсутність стандартизації тут гарантовано 100% недолік, тобто порівняємо нп з сі - булоб щось на зразок код відповідно стандарту c99.
А тут нп умовному мейнтейнеру ще прийдеться боротися як то з "поточною ревізією git" все то підтримувати.

Чекайте но, якої саме стандартизації не вистачає в Rust? До кожної програми і її залежностей вказується версія компілятора 2021, 2024 і тд.

версія програми немає ніякого відношення до стандарту мови (с99 був як приклад) чи його відсутності (у випадку раст)

cargo ... як і в будь якому пакетному менеджері, якого з коробки в C ... немає

з сі повезло що не пішли свого часу в пакетний хаос отриманого з вбудованими пакетними менеджерами, тобто по шляху perl python node rust etc.

[ps]

Мені, як людині, яка вивчала C і C++, код на rust виглядає некрасиво, незрозуміло і дуже дивно.

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

Люди, які пропагують раст такі фанатичні, і чомусь нагадують мені фанатиків системГ і ленарта поцтерінга.

Якщо буде раст від GNU, можна буде на нього подивитися.

борони боже пропагувати, просто написав чому воно мені бляха подобається)
з іншого боку, хто є фанатичними ідеологами - це послідовники Столмана що добре чухає на захисті авторських прав і є далеко не дурнем, на відміну від своїх фанатиків
через яких половина опенсорсу не використовується в комерс проєктах, якщо це не AGPL - підприємства обирають MIT/Apache, подалі від носів авторського "копілефту"

[ps]

версія програми немає ніякого відношення до стандарту мови (с99 був як приклад) чи його відсутності (у випадку раст)

ну я ще так подивився що мабуть про інші стандарти мій комент, користувацького рівня.

з сі повезло що не пішли свого часу в пакетний хаос отриманого з вбудованими пакетними менеджерами, тобто по шляху perl python node rust etc.

ніхто ж не примушує будувати софт на базі cargo - можна обрати іншого постачальника, або взагалі виключити пакетні залежності як Redox OS та набір бібліотек std як на прикладі ардуіно
https://arduino.ua/art220-yak-programyvati-mikrokontroleri-na-movi-rust

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

[kostiantyn.hermash]

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

Мені здається, що раст придумали для того, щоб код писав штучний інтелект.

Бо штучному інтелекту начхати на красу коду. А мова влаштована так, що буде пробачати усі помилки.

С/C++ --- це мови для людей, а не для машин. )))

через яких половина опенсорсу не використовується в комерс проєктах

OpenSource і Free Software --- це різні речі.

Ну то й що, що вільне ПЗ не використовується в комерс проєктах? Це нормально.

Комерційні контори також не сильно дружать зі спільнотою вільного ПЗ. Наприклад, компанія Nvidia вже два десятиліття не може народити нормальний драйвер для своїх відеокарт з відкритим джерельним кодом. Навіть Лінус Торвальдс був змушений показати їм середній палець.

Тоді чому розробники вільного ПЗ повинні дозволяти заробляти гроші комерційним конторам на своєму вільному коді?

[BeSiDa]

Люди, які пропагують раст такі фанатичні, і чомусь нагадують мені фанатиків системГ і ленарта поцтерінга. Вони хочуть зламати все, що будувалося десятиліттями, та збільшити хаос і так в хаотичному світі GNU/Linux. Пхають свій пакетний менеджер cargo всюди. Навіщо мені в Дебіані ще один пакетний менеджер? В мене вже є dpkg і apt, і вони чудово працюють.

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

А той стиль то ... "дія фашистів" (то "стиль поведінки" який "людина" може вирішити змінити).
Вони+стиль розказують всім що то лише "їх особистий вибір" і "особисто їм так приємніше" (поки їх менше 30%, так вони пінгують оточення та обчислюють свою кількість), а потім перемикаються на пресування словами "більшість за раст!", "все інше НІКОМУ не потрібно!", "не витрачайте час на пустощі!", "зробимо все _ефективним_ як у камінюки без мізків!" (коли більше 30%), а далі підуть розстріли (фізичне знищення всіх "терористів" які не згодні з "растом як єдиним вірним вибором" та ще й "роблять дії!!!!!!" проти ).

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

Не звертайте уваги та робіть своє
Бо інакше... то "війна" (для їх уяви).