«Не змушуйте нас працювати з вашою модною мовою!»: чому Linux-розробники воюють проти Rust

Останнім часом серед розробників ядра Linux розгортаються справжні баталії: чи варто додавати Rust у кодову базу, яка десятиліттями будувалася на C?

Що сталося

Розробники проєкту Rust for Linux намагаються інтегрувати Rust у ядро, але стикаються з жорстким опором з боку частини супроводжувачів. Один із них, Крістоф Хеллвіг, відверто заявив:

«Не нав’язуйте мені вашу модну мову. Підтримка багатомовних проєктів — це зайва складність, якою я не хочу займатися. Якщо ви вирішили використовувати щось, окрім C, будь то асемблер чи Rust, то працюйте через C-інтерфейси та самі розв’язуйте всі проблеми сумісності», — написав він.

Розробник Red Hat Даніло Круммріх зазначив, що ядро на C залишається незмінним, а драйвери на Rust просто використовують централізовані абстракції. Проте саме впровадження цих абстракцій у ядро викликало гостру критику з боку Крістофа. Він жорстко зауважив:

«Якщо ви хочете зробити Linux неможливим для підтримки через багатомовну кодову базу, то робіть це у своєму драйвері, а не поширюйте цю ракову пухлину на основні підсистеми!»

Серед основних переваг впровадження Rust у Linux відзначають:

  • Зменшення критичних помилок управління пам’яттю, які є основним джерелом вразливостей у C/C++.
  • Підтримку з боку технологічних гігантів, таких як Microsoft, Google, а також державних установ, які зацікавлені у підвищенні безпеки.
  • Офіційне включення Rust до ядра Linux у жовтні 2022 року, хоча його використання поки що залишається обмеженим.

Після суперечки з Хелвігом Гектор Мартін, один із ключових розробників Linux, залишив проєкт :

«Я більше не вірю в процес розробки ядра чи підхід до управління спільнотою», — написав він у примітці до списку розсилки ядра Linux.

Що буде далі

Усе залежить від Лінуса Торвальдса. Раніше він залишався нейтральним, але тепер його рішення може визначити майбутнє Rust у Linux.

А що думаєте ви? Чи варто Rust витіснити C у розробці ядра Linux, чи це «ракова пухлина» ?

Читайте також: «Зелене світло» для Rust: Лінус Торвальдс підтримуює інтеграцію в ядро, Конфлікт в Linux продовжується: Крістоф Хелвіг залишає посаду мейнтейнера

👍ПодобаєтьсяСподобалось7
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

ретрогради ще би писали ядро на Коболі і верещали би б’ючись в Кобол-код як дятел об дерево: «Мейнфрейм грузицця з перфострічки — не чіпай»

Найбільш зручно системний код писати на системній мові з яким і під який та система створювалась. Нп якщо колись на pdp машинах це був фортран, на ньому було значно комфортніше програмувати в їх системах — навіть маючи більш сучасні сі і паскаль — користуватись ними було незручно. Теж само Unix — системно це Сі і під нього вся екосистема заточена і створювалась, і наскільки б краща (з когонебудь точки зору) не була будьяка інша мова — по зручності не порівняти з системною для системного програмування.
Теж саме стосується і rust — коли буде ОС задізайнена з самого початку для rust і написана на rust: — тоді питань нема і всі найретроградніші ретрогради будуть грузитись з перфофлешки і казати — зручно і не чіпай і не треба тут той новомодний сі.

p.s. мова програмування це тулза, а не самоціль

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

це догма, чи неофітство? go системна?

мова програмування це тулза, а не самоціль

К.О.

Go — прикладна і задіяти як системну фактично не можливо з низки причин. C, Pascal, Ada — в цілому можна використати як системні, краще за усе пристосована саме С по суті в синтаксисі нема прикладних зав’язок, усе перекладено на бібліотеки в тому числі на стандартну — CRT, Gnu lib C і т.д.
В С++ — вже статичні перемінні, thread local, RTTI та Exceptions — треба виключити пори системному програмуванні і не можна користатись. По суті new та delete теж не усюди і взагалі не бажано. Новітні корутини С++ 20 або
Rust — із файберами async/await і т.п. це безкінечно далеко усе від системного програмування. Це усе для розробки прикладного ПЗ.
Тим не менше наприклад ядро FreeBSD — має 30% C++ коду, ядра L4 — - 50 та більше, так само BeOS та інші ядра доволі великий процент складних платформо не залежних абстракцій пишуть за допомогою абстракцій які надають мови типу С++.
Go і зовсім, не відключаєма збірка сміття на рантаймі, про системне програмування одразу забуваймо. Тобто ядро якось дуже хитро треба буде писати із екзо архітектурою і т.п , та були ядра де велика частина була якраз так зроблена — що платформо незалежні частини на чомусь типу Java. Розповсюдження так собі — навідміну від канонічного монолітного Unix дизайну а-ля System 5, в подобі Linux.

Docker це системне програмування чи прикладне?

Прикладне на базі можливостей операційної системи Linux до створення середи — контейнера, або Windows підсистеми ядра WSL чи гірервізора HyperV. І це тільки частина яка runc, а там ще купа усього.
Хоча я би такий соф, як і скажімо віртуальну машину Java або наприклад Node, виділяв би в окремий клас софту. Бо з одного боку — це системний рівень логічно, тобто середа для виконання іншого ПО при чому подекуди це декілька рівень среде як то Linux-Kubernetes Engine-RunC-[Java-Tomcat-Java/Kotlin Spring Boot App, Node->TypeScript Express.JS/Next.JS App, Python Django App, Go lang Beego/Kit app , Rust Rocket App, С++ Poco app ] і т.п. безліч комбінацій. Так само бази даних різних типіві на усі смаки бажання та архітектури, хмарні хранилища даних і т.д.
Але і сама по собі середа вимагає іншої середи виконання як то ядра ОС і абстракцій ОС. Це наслідок дуже суттєвого укладення абстракцій під поточні потреби. Так розвилось історично, хоча від початку те що є зараз задумувалось одразу як Multix та реалії «на землі» програмно-апаратних комплексів зробили от таку над складну інфраструктуру, щоби реалізувати те що задумувалось саме як Multix.
От на кінечному прикладному як бекенд рівні так і певному фронтерд рівні клієн-серврної архітектури у нових мов як то : D, Go lang та Rust є безперечні переваги над конкуруючими технологіями як то Java, C#.NET, Python та Node.

Rust — із файберами async/await і т.п. це безкінечно далеко усе від системного програмування

та ні, ідея файберів, корутин, вона офігенна, але найкраще реалізували цю ідею в... Сшці
така корутина нічого не коштує, і ось така теж порівнянно з «ручним» закодовуванням FSM там, де повинна бути послідовна «асинхронна логіка»
(й то якраз той кейс, коли Сшний підхід краще поюзати в С++ ніж юзати «нові та модні» переускладнені С++ні корутити, хоча вони й не мають тих обмежень/граблів, які має Сшний аб’юз Duff’s device))

PS. «порівнянно з „ручним“ закодовуванням FSM», є ще хвалений маркетологами і облизаний продажниками qp фреймворк, але мало хто його юзає правильно (просто як спосіб створити скелет для станів та переходів), натомість там тайпкаст на тайпкасті і тайпкастом поганяє...

Зато менеджери/сейлзи вміють його грамотно втюхати команді/клієнту як немавідь який прорив в підходах

А взагалі щодо Rust спекуляцій, які піднімають ідейні раст-исти з ціллю технологічної конкуренції як завжди, бо вивчення мови і технології це інвестиції. Код ядра Linix перейшов рубіж в 40 мільйонів строк коду 30 січня 2025 цього року (так такий собі показник, та в цьому випадку трохи має сенс через головну мову програмування і напевно є величезна купа легасі яке має сенс викинути)
github.com/torvalds/linux
98.3% коду — при цьому приходиться на мову С, тобто абсолютна переважна більшість. Друга за кількістю 0.7% — це ассемблер (і це показник сам по собі, наприклад FreeBDS має 2% ассемблерного коду, NetBSD — 3%). На Shell (Bash) скріпти доводиться 0.4%, білд та пре процессорні скріпти на Python — 0.2%, GNU Makefile — 0.2%, Perl — 0.1%, і на усе інше 0.1%

Ответ Торвальдса по поводу блокировки Rust враперов к DMA подсистеме: https://lore.kernel.org/rust-for-linux/CAHk-=wgLbz1Bm8QhmJ4dJGSmTuV5w_R0Gwvg5kHrYr4Ko9dUHQ@mail.gmail.com/

...

Honestly, what you have been doing is basically saying “as a DMA
maintainer I control what the DMA code is used for”.

And that is not how *any* of this works.

What’s next? Saying that particular drivers can’t do DMA, because you
don’t like that device, and as a DMA maintainer you control who can
use the DMA code?

...

That’s kind
of the promise here: there’s that “wall of protection” around C
developers that don’t want to deal with Rust issues in the promise
that they don’t *have* to deal with Rust.

But that “wall of protection” basically goes both ways. If you don’t
want to deal with the Rust code, you get no *say* on the Rust code.

Put another way: the “nobody is forced to deal with Rust” does not
imply “everybody is allowed to veto any Rust code”.

Для тех, кто не следил за темой, короткое описание конфликта, связанного с патчем: dou.ua/...​rums/topic/52446/#2933472

Тут головне питання так і не має відповіді: якщо на боці «няшного C» (якраз в тому коді/структурах даних, що юзаються з Rust) хтось вносить таку зміну, яка ламає Rust частину, то хто тоді буде правити Rust частину?

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

хтось вносить таку зміну, яка ламає

а у вас як на проекті: «хто робить коміт в основну гілку, то й фіксить», чи як?

головні граблі й головне неприйняття:

якщо змінюється контракт/API до Асемблера то хто буде правити Асемблер частину?

а у вас як на проекті

Це — не відповідь. Власне ж тут весь корінь «срача»: якраз, щоб не співпрацювати додатково (до асемблера)) ще й з тими, хто знає Rust (щоб не включати додаткових персонажів для вмовлянь й биття поклонів бюрократії узгодень та рів’ю)

Це — не відповідь.

яре питання — така і відповідь 🤷‍♂️.
Хтось виправить. або необов’язковий раст викинуть як і багато чого шо залишається без супровдження в кернелі.
Ти ж не питаєш хто буде виправляти ламаючі зміни в 100500 драйверах на С, які залежать від DMA. Чи ти гадаєш шо код на С самовиправляється?

Ні, то не відповідь!
Відповідь, то коли сам Лінус прийме рішення за фразою з мого оригінального допису «Тут [тобто в пості на який я там відмовідаю!] головне питання так і не має відповіді: якщо на боці „няшного C“ (якраз в тому коді/структурах даних, що юзаються з Rust) хтось вносить таку зміну, яка ламає Rust частину, то хто тоді буде правити Rust частину?»...

Тобто «срач» не закінчиться тою дипломатичною відповіддю Лінуса про «does not
imply» процитованою в дописі вище від мого комента, до якого власне я і написав свій комент! І тим більше оригінальний «срач» не закінчиться намаганнями інших дописувачів «образумити» мене, коли я стверджую, що оригінальну проблему так і не вирішено (тому риторично-філософські роздуми про "

а у вас як на проекті

" — це сміття в контексті вирішення оригінальної проблеми)

Й стейтмент з прийнятої доки «Rust for Linux», що визначає правила, теж насправді не катить і не вирішує проблему:
«However, exceptionally, for Rust, a subsystem may allow to temporarily break Rust code. The intention is to facilitate friendly adoption of Rust in a subsystem without introducing a burden to existing maintainers who may be working on urgent fixes for the C side. The breakage should nevertheless be fixed as soon as possible, ideally before the breakage reaches Linus.»

бо це тільки накручує одну сторону відтягувати фікс (нема нічого більш вічного за тимчасове), а іншу примушує і далі ходити по граблях чераз зміни в Сшці, які ламають Rust!

Як справжній солюшен для тих, хто не хоче юзати/правити Rust було б правило для цього ніколи більше не змінювати те, що попадає в EXPORT_SYMBOL, а якщо щось таки треба змінити, то це має бути новий EXPORT_SYMBOL для нового імені, і продовжувати сапортити старий символ... що насправді підхід вінди з її «ЯкатоАпішка» та «ЯкатоАпішкаEx», замість правити оригінальну АПІшку, а також і правило включати sizeof структурки першим полем (щоб всередині рорізнити версію)... тобто фіксація «опаблікованого» АПІ «навіки» навіть всередині ядра! А якщо таки «брейкінг чейндж» тому має бути залізно subsystem may NOT allow to break Rust code а не то ото, що є зараз (проблему не вирішено!)

А для Rust розробників було б набагато простіше, якби існувало не тільки -fdump-ada-spec а й -fdump-rust-spec і не треба було б набивати рули для мапінга між «няшною Cшкою» та Rust вручну, і рів’ювити їх щоразу, коли в Сшній частині щось змінилося...

А для Rust розробників було б набагато простіше, якби існувало не тільки -fdump-ada-spec а й -fdump-rust-spec і не треба було б набивати рули для мапінга між «няшною Cшкою» та Rust вручну,

Я цього немає? Як на мене, має бути. Особисто я б з цього починав Rust for Linux як перший крок.

> a subsystem may allow to temporarily break
>
наскільки я розумію це протирічить одному з принципів якого дотримувався Лінус: — якби треба то не було, не поламайте змінами з бінарною несумісністю інший софт.
(колись бачив в його інтерв’ю то відносно змін які можуть зачепити юзер софт, але думаю це стосується усіх підсистем також)

наразі саме так пише (як я розумію офіційна) дока
rust-for-linux.com/...​a-build-with-rust-enabled

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

щодо бінарної сумісності, то тут гарантії є тільки для юзерспейсу...
а в межах самого «монолітного» ядра ніяких гарантій на сьогодні нема,
саме через те й з’явився dkms, коли «дрова» перекомпільовуються на прямо машині в юзера під нове ядро...

що також, очевидно, ще один «баттхерт», адже щоб дрова на Rust також змогли поюзати бенефіти dkms, то треба на юзерську машину притарабанити й Rust з його примочками, що мав би ще й працювати через якийсь умовно bindgen (який зовсім «нето», ніж якби сама gcc-шка мала б «умовно» -fdump-rust-spec)

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

та нє, мова не про кастомне ядро... dkms раниться сам з коробки в умовному десктопному MX Linuх при апдейтах, ніякого «шаманізму» не потрібно, збирати самому ядро не потібно...

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

> дрова на Rust також змогли поюзати бенефіти dkms, то треба на юзерську машину притарабанити й Rust з його примочками
>
Ще може буде проблемою нп знайти з якою версією rust компайлера можна то взагалі зібрати

p.s. я якось раст софт відкатував довго і нудно, поки по фічастості дійшов до потрібної версії його компайлера

Ще може буде проблемою нп знайти з якою версією rust компайлера можна то взагалі зібрати

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

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

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

p.s. з полісі
Is Rust for Linux driven by the «Rust community»?
— No, ...
Are companies involved in Rust in the kernel?
— Yes, ...

так як воно є на зараз

dkms юзається!

ядро не треба білдити на локальній машині, але бінарна сумісність для модулів ядра не гарантується, єдина раціональна стратегія — взяти хедери до готовенького ядра, й зібрати модуль разом з ними, то власне і є вся ідея dkms!

ясно, «хьюстон у нас проблема» якраз з цією раціональною стратегією (те що воно погано вписується в концепт dkms генерації з sources)

якщо змінюється контракт/API до Асемблера то хто буде правити Асемблер частину?

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

АРІ не кожен день змінюються, раз зробив і забув на роки

Тут головне питання так і не має відповіді: якщо на боці «няшного C» (якраз в тому коді/структурах даних, що юзаються з Rust) хтось вносить таку зміну, яка ламає Rust частину, то хто тоді буде правити Rust частину?

rust-for-linux.com/...​a-build-with-rust-enabled

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

Это продлится недолго. Несколько раз наблюдал на рабочих проектах, когда появляется какая-то новомодная хрень, которая показывает серьезный потенциал.

Появляется 3 категории людей:

1. Старые мейнтенеры, которые не хотят разбираться с этой хренью
2. Старые мейнтейнеры, которые не против разбираться с этой хренью
3. Новые мейнтейнеры, которые «did not know any better», по дефолту буду работать с этой хренью, и даже не будут знать, что когда-то было не так.

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

Люди из категории 2 за счет своей готовности работать с чем угодно получают досутп к новым проектам и получают серьезный буст к карьере, обгоняют людей из категории 1, получают промо на 1-2 левела. Некоторые переростают текущее место и куда-то переходят на повышение.

Люди из категории 3 за счет отсутствия ментельного тормоза, быстро продвигаются по карьере до уровня близкого к людям категории 1.

В итоге вопрос не в том «Кто будет фиксить, когда изменения в старой хрени ломает новую хрень», а «Когда мы уже сможем полностью избавиться от старой хрени, с ней уже никто не знает как работать».

В опенсорсі — заорфанили пакет(и) які проблематично підтримувати — і там вони надовго в очікуванні що може хтось візьметься за підтримку. У випадку rust бажаючих не дуже видно свійже постійний rolling софт підтримувати. Якщо примусово — то простіше.

Несколько раз наблюдал на рабочих проектах, когда появляется какая-то новомодная хрень, которая показывает серьезный потенциал.

А скільки часу потрібно, щоб побачити потенціал? Проекту Rust for Linux п’ять років, увесь потенціал більше на словах. За цей час Linux дійшов від ідеї написати OS (1991) до появи Red Hat (1995), тобто повноцінне комерційне використання. У разі Rust for Linux... Що люди казали п’ять років тому, то й кажуть зараз, а практичного результату майже немає.

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

давай ліпше із substrate для крипти

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

Якщо брати конкретно користь від Rust у розробці драйверів Linux, то через п’ять років раптово з’ясувалася, що треба робити якусь підтримки DMA, і тут у мене питання «а де ви всі були увесь цей час?»

Як Трамп, а де ви були ці роки із своїми DMA драйверами на С?

то через п’ять років раптово

то через п’ять років з’ясувалось шо мейнтейнер підсистеми DMA просто мудак якій на рівному місці вставляє палки в колеса і закатує істеріки.
підозрюю шо він не один такий. Чувак тупо забув шо він не цар і Б-г. І не розробники дров для нього а якраз то він для розробників дров. і в тому числі дров на расті.

Для цього навіть термін є — синдром вахтера.

то через п’ять років з’ясувалось шо мейнтейнер підсистеми DMA просто мудак якій на рівному місці вставляє палки в колеса і закатує істеріки.

Ну... щось мені нагадує один випадок, коли працівник півтора тижні рапортував про виконання задачі, а потім з’ясувалося, що у нього немає доступу до репозиторія.

5 лет не были написнаы раст враперы для DMA:

Где вы были все это время? Почему не пишите поддержку DMA на расте?

Запилет патч для раст враперов для DMA:

No rust code in kernel/dma, please.

де ви всі були увесь цей час?

Люди пилят со скоростью, которую считают нужным, и не пытаются подстраиваться под ожидания кого-то, кто никакой помощи не оказывает.

А скільки часу потрібно, щоб побачити потенціал?

Куча людей не хотят идти контрибьютить в RfL потому что хотят, чтоб все, кто тормозит прогрес, узбагоились и перестали тормозить.

У многих люедй есть экспертиза делать, но нет желания кому-то что-то доказывать и общаться с людьми, у которых отсутствуют soft skills — время, когда быдлятское общение в имейл группах было нормой прошло.

Когда появится достаточно момента, процес пойдет. Уже близко, я гарантирую это.

Проекту Rust for Linux п’ять років, увесь потенціал більше на словах. За цей час Linux дійшов від ідеї написати OS (1991) до появи Red Hat (1995), тобто повноцінне комерційне використання.

Целых 5 лет? С момент создания первого компьютера до момента создания первого компьютера а хранимыми программами прошло всего 3 года. 5 лет прошло с момента создания первого компьютера на дискретных транзисторах до первого компьютера с интегрированной микросхемой.

А тут 5 лет понадобилось, чтоб довести ОС до состояния, в котором даже нескучных обоев не было (т.е. по сути наколбасить кучу текста в редакторе и скомпилировать)? Збс.

Ну... Rust розробники можуть святкувати :-)

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

Ну... Для мене якість та успішність проєкту важливіше ніж почуття розробників. По-друге, сама посада мейнтейнера це спілкування з тими, хто просуває гімнокод. Якщо кожен зможе комітити усе що завгодно, то проект швидко почне деградувати. Тому в принципі я би оцінював його діяльність більше з позицій того, наскільки якісно написана система DMA в ядрі, а не те, як він поводився. Був у мене на початку кар’єри один менеджер, який намагався з усіма погодитися... Не раджу з таким працювати.

А от на мою суб’єктивну думку, один Крістоф Геллвіг зробив для проекту Linux набагато більше корисного, ніж уся спільнота Rust For Linux за усі роки. Поки що.

Для мене якість та успішність проєкту важливіше ніж почуття розробників

www.youtube.com/watch?v=WCIKxVe4_Xw

Ну... Для мене якість та успішність проєкту важливіше ніж почуття розробників.

Мягко говоря скотское отношение к людям, которые в основном бесплатно пилят успешный проект, которым ты можешь бесплатно пользоваться :)

По-друге, сама посада мейнтейнера це спілкування з тими, хто просуває гімнокод.

Кэп говорит, что те, кто могут нормально общаться, достигнут гораздо больших результатов, чем те, кто нормально общаться не способен.

Був у мене на початку кар’єри один менеджер, який намагався з усіма погодитися... Не раджу з таким працювати.

yes man это сильное отклонение в другую сторону, что тоже не хорошо. Но большинство вещей, созданых в истории человечества, созданы людьми, которые смогли достичь точки согласия с другими людьми, а не теми, кто предпочитает вместо этого хамить и сраться.

> бесплатно пилят успешный проект
>
пилять, то точно, а звідки інфо що то безкоштовно?

p.s
Is Rust for Linux driven by the “Rust community”?
— No, ...
Are companies involved in Rust in the kernel?
— Yes, ...

А почему скотское ? Его что порят когда сено раскидывает или забивабт на мясо, когда лает мало молока ?
На мой взгляд майнтейнер просто съехал на язык программирования, хотя там явно комитили откровенно гомнокод, лиш бы на Rust. Линус в былые времена ща это дело материал прямым текстом и говорил как есть. Да у этого есть обратная сторона — к сожалению были случаи суецидов, при таком количестве народу могут быть люди с проблемами с психикой и т.д. Опять же решается скажем статическим анализом кода — которого к сожалению тоже нет.

Мягко говоря скотское отношение к людям, которые в основном бесплатно пилят успешный проект, которым ты можешь бесплатно пользоваться :)

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

Кэп говорит, что те, кто могут нормально общаться, достигнут гораздо больших результатов, чем те, кто нормально общаться не способен

Ой, це притягує паразитів, які тільки й спілкуються, але нічого не роблять.

Но большинство вещей, созданых в истории человечества, созданы людьми, которые смогли достичь точки согласия с другими людьми

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

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

Для мене якість та успішність проєкту важливіше ніж почуття розробників

Чомусь Стів Джобс згадується в цьому контексті з його
«My job is not to be easy on people. My job is to make them better.»
Але, якщо відкинути крайнощі то має бути певно якийсь баланс між повністю потаканню всім примхам і необхідністю щоб робота робилась.

Старые пеньки во главе с Линусом допрыгаются до глобального форка, если будут дальше говорить с другими в стиле «я не хочу потому что не понимаю и понимать не хочу»
Главными акторами могут быть гугль и мелкомягкие, а там и другие подтянутся
Посмотрим что будет бухтеть линус, если от него свалит те, кто дает больше половины кодов базы

Старые пеньки во главе с Линусом допрыгаются до глобального форка

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

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

Усі проекти з часом помирають, буде шанс написати нову OS на Rust. А взагалі проблеми треба вирішувати по мірі їх виникання.

А в чем проблема ? Кто и когда запрещал делать форки в Open Source и Free проектах ? Вообще без комьюнити оно ничего не стоит вообще. Альтернативных ядер и ОС сколько угодно много, самый известный FOS конкурент — Free BSD. А там куча всего и семейства BSD — NET BSD, Dragon Fly BSD і т.д. Аналогично семейства ядер : Hurd, Minix, L4 и т.д.
Почему при таком выборе куче народу и корпорации в первую очередь IBM, Intel, Google, Amazon, Ebay и т.д. отдали предпочтение именно Linux ? Очень просто — да Линус и его команда дели и делаю очень жосткий код ревью, отбирая лучшие надёжные и часто консервативные решения, уже опробованные где-то скажем в Unix System 5 и хорошо себя зарекомендовавшие. В том числе и прямо покрывая матами тех кто пытался пропустить в исходный код наскоро сделанную лажу.
Ключевой показатель для коммерческого ПО — это его надёжность и безотказность. Если с ядром серверного ПО или скажем мобильного телефона происходят разные : kernel panic, blue screen of doom и т.п. то такая система никому не нужна нахрен. Что касается Rust то Mozilla все время рекламирует, что этот язык якобы делает защиту от плохого программирования, но это не так принципиально это все ещё Algol 60 просто с доработками, для решения небольшой части типичных ошибок программиста — в целом решаемыми и другими методами. Достаточно посмотреть что Rust-тисты уже там накомитили и увидеть что это сплошной говнокод, только на Rust — закоментированныные блоки кода, отсутствие четкого код стайла, магические константы и т.д. Когда менйнтенеры ругаться на это — правильно делают. Потому как именно чепуха в исходном коде делает его в итоге не поддерживаемым.

Очень просто — да Линус и его команда дели и делаю очень жосткий код ревью

Ну... Як на мене FreeBSD жорсткіше, але це впливло на динаміку розвитку проекту.

Стали пізніше, коли по факту їх стали підтримувати Apple, після розмови Стіва та Лінуса яка не задалась. Довго проект тормозило наявність оригінальних кодів Bell labs, що потрапили до Берклі, які довелось повністю переписати щоби вони відповідали ліцензії BSD. В проектах де вакханалія і нема вагомої підтримки від корпорації, там кожен робить — що захоче, впилює які завгодно мови включно з власне створеними неначе Кен Топсон та, Деніс Річі тільки толку нема. BTW Самим Річі та Томпсону вдалося умовити керівництво робити Unix, тільки під приводом створення софту для бухгалтерії, тому вони працювали в ночі доки в день бухгалтери працювали на комп’ютері. І ситуація із Linux в даному випадку унікальна, усе почалось із фінського аспіранта в університеті в Хельсінкі, який надихнувшись книгою професора зі Швеції створив ядро яке стало цікавим фактично усьому світу. І сперечання щодо консервативного монолітного дизайну в стилі Річі та Томпсона та новомодної мікро ядерної архітектури, С++ (хоча станом на зараз можна використовувати усі минулі проблеми з ранніх 90-х давно вирішені) і т.д. почались в 90-ті роки минулого сторіччя. Minix 3 та L4 семейство фактично так нікого особливо не зацікавили в комерційному плані, та залишились академічними проектами.

Я скоріше про свій досвід середини 2000-х, тоді Free BSD складав конкуренцію, був стабільніше, Linux крешився, але... з часом стабілізувався, а по кількості фічей обійшов. Такі були відчуття.

Я знаю багато людей які і зараз вважають FreeBSD суттєво кращім за Linux, часто це адміни із великим стажем роботи. І напевно в чомусь мають рацію, там і з Rust не експериментували і ревью жорсткий. По фітчам часто навпаки рішення BSD зараз часто тягнуть в Linux.

В freebsd дискутували достатньо навколо rust, наскільки я зрозумів акумулятивно всього достатньо набралось, але головна причина чому невзлетіло — бо нема ресурсів. Тобто freebsd гірше чи краще за linux, то іррелевантно.

Ключевой показатель для коммерческого ПО — это его надёжность и безотказность

комерсанти можуть писати своє пропроетарно елітне Ядро і мати спокій

отсутствие четкого код стайла,

cargo fmt

Потому как именно чепуха

може таки розказувати смак устриць буде той хто їх пробував

Red Hat так почали патчити у власному форку і сворили дістрібутив в 1993-му. Лінус фактично завжди асоціювався із компанією — також мав опціон. В 2009-му році вони були включені в список S&P 500 тобто увійшли в список 500 компаній США із найвищою капіталізаціїєю, в США заарестовано 18,2 мільйона компаній. В 2012 році річна виручка компанії перевищила мільярд долларів з урахуванням інфляції це 1.4 мільярди долларів на 2025. В 2018-му шляхом скупівлі акцій IBM поглинули Red Hat за 34 мільярди доларів ( 38.4 мільярди на 2025).
Canonical почали патчити Debian а також робити різний внесок і розвивати екосистему, чистий прибуток станом на 2024 — $251 мільйонів долларів.
Ну і самий відомий проект на ядрі Linux — це Android, прибутки в десятки мільярдів Google не публікує скільки конкретно приносить проект, відомо тільки що разом з тим за патенти теж багато заробляє Microsoft при чому дуже багато, більше навіть ніж власним софтом.
Linux та Open Source як такий давно не Just for Fun, це комерційна діяльність здебільшого і бізнес модель.
FreeBSD — теж активно підтримується Sony, яка використовує для Play Station та Apple які щось використовують від проекту. Також вклад робить AMD.

якщо згадуються BSD я б ще додав MacOS, тим більш якщо наведено як приклад Linux->Android. (До речі MacOS називають останній з живих сертифікованих Unix)

Глобального форка не будет. Будет POSIX совместимая ОС, написанная с нуля на Rust. Какие-то фрики, работающие где-то в Big Tech притянут ее вопреки здравому смыслу на какой-то production workload и все будут ржать, пока через некоторое время внезапно не выяснится, что 80% новых ворклоадов в облаке работает на этой ОС (аналогично тому как было с ARM в датанцентрах). Запомните этот твит.

То ніби-то вже є Redox OS... Який за 10 років так і не став стабільним. То як гадаєте, то буде Redox, чи інша OS? Та скільки років чекати появи до першого production workload?

Перевага ARM достатньо очевидні — ціна та електроспоживання.

З досить відомого ще є Cosmic DE (не настільки ще древній, але все ще десь між alpha і beta). А з довгограючого згадується ще растерізація gnu coreutils, де десь за років теж 10 підійшли до ~%70 від початкового функціоналу.
Тобто поява на раст софта production рівня залежить майже тільки від того наскільки готові в нього фінансово вкластися big tech компані для проштовхування, навчання, і супроводу того всього (бо cі комьюніті щось не дуже проявляє бажання переписувати софт на раст) — це варіант схожий з Java хісторі. Ще варіант — примусово адміністративний (як колись пишуть було з ада замість фортрану).

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

Так, не зважаючи що всі ці проекти пов’язує це використання раст — то не OS проекти. Наведено як комент до
«скільки років чекати появи до першого production»
— думаю що проблеми з якими стикаються rust проекти приблизно однакові, і тому можна то приблизно оцінювати по іншим крупним проектам з використанням того самого підходу.

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

Ну... розробка OS, як на мене, ще більше збільшує та додає проблеми. По-перше, не дуже очевидні переваги Rust, вони стають частковими. По-друге, ніша заповнена. По-третє, складність та терміни.

Чесно кажучи я думаю це win-win ситуація і для C і для Rust, бо якщо є здорова конкуренція то це заставляє і Сі також розвиватися (нп почали з’являтися перші [поки що не дуже вдалі] спроби зробити Сі safe як і в Раст розумінні під час компіляції). І якби не ці драми навколо Rust-vs-[X] булоб все еволюційно і гарно.

p.s. порівнюю з С незважаючи на imho що Rust це більш конкурент C++ (то для чого rust і створили колись в Мозіла як фікс с++ кода наскільки я розумію)

До Rust існувала Ada, та й зараз є, що теж цікавий вибір. Проблема у тому, що ніша зайнята, багато легасі, конкретно Linux це моноліт зі свома властивостями.

А так я згоден, розробники Rust та C++ мають приблизно однаковий склад мислення.

як варіант «криптогіганти» зроблять свою ОС з растом і поетесами

А скільки років знадобилося лінуксу, щоб стати хоч якось приблизно стабільним? Перша версія 1991, а перше віддалено нормальне стабільне ядро 2.6 вийшло в 2003, тобто 12 років.

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

ніхто не юзав в проді лінукс до версії 2.6, тоді була або BSD яка була базою для всіх постсовкових адмінів, або щось комерційне, на території колишнього ссср це був Solaris, бо Sun тоді мав офіси в рашці, і це все доходило до нас, ну і вінда. Linux прийшов в прод, на початку 2000х років якраз в розпал доткомів, а в лідери взагалі вибився, коли більшість великих вендорів відмовились від власних систем, тобто близько 2012 року. В 90х лінукс був курсачом туповатого фінського студента, і ні для чого не годився. Впринципі і зараз нічого не змінилося, лінукс все ще ні для чого не годиться, але його всюди сунуть.

))) ну продовжуйте далі хто що юзав включно з комерційніми віндами 90х ...

> лінукс все ще ні для чого не годиться, але його всюди сунуть
>
З цього треба було і починати — яку суть пробували донести — «я думаю що лінукс ні для чого не годиться, але його всюди сунуть», а не про 90ті

Що тобі розказати? Історичні факти, ну от Windows Server 2003 якраз і почав втрачати позиції в сторону лінукса бо саме з неї переходили на лінукс, коли начали переводити серваки на 2.6. Стек LAMP якраз хайпанув, він з’явився в 98, але популярним став в 2002 коли вийшов апач 2.0, і в той самий час популярність платних веб серверів упала. Плюс бульбашка лопалась якраз в 2001 був пік і до 2003 спадав, і для лінукса зійшлись всі зірки, хайп доткомів, необхідність в серваках, і безкоштовний апач, от воно і почало захоплювати ринок на фоні кризи, але це було в 2000х роках, а не в 90х. Лінукс це повністю штука з 2000х років. А після кризи 2008, всі гіганти почали загибатись, і вже на місце соляріса приперли лінукс, який був у всьому гірший, але безкоштовний.

Підсумую: — все почалося з ламп і віндовс серверів... потім апач захвачує доткоми просуваючи непригодний лінукс який в свою чергу захвачує ринки.. і все це на фоні кризи яка призвела до загибелі титанів.
Клас

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

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

агласітє весь спісак, в чому саме «в усьому»? ))

лінукс все ще ні для чого не годиться, але його всюди сунуть.

сказав як відрізав

А скільки років знадобилося лінуксу, щоб стати хоч якось приблизно стабільним?

Що означає «стабільним»? Навіть зараз можна знайти десь Kernel Panic та сказати, що він ще нестабільний. Як на мене, Red Hat Linux заснована у 1995 році, що показує, що Linux був достатньо стабільним для комерційного використання.

Знову, є такий фактор як іноваційність. У нас може бути стабільна OS (FreeBSD наприклад), яка не підтримує нове обладнання, нові фічі, ... Це може призвести до того, що вигідніше буде ставити менше стабільну OS, але яка дає тобі більше можливостей. Тому швидкість розробки також важливий фактор.

Знову, якщо брати Linux, то 1991 ідея, 1999 рік Google почав використовувати Linux на серверах. Беремо Redox OS, 2015 ідея, 2025...

Всі пошукові сервера гугла до 2019 року були на HP-UX

Розробники проєкту Russia for Ukraine намагаються інтегрувати Russia у ядро, але стикаються з жорстким опором з боку частини супроводжувачів.

Не стримався

Нєхєр своїми ржавими руцями лізти куди не просять, дядько все прально сказав — не поширюйте свою ракову пухлину на весь організм

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

Якщо не домовляться, буде форк.

не будет. Там количество человеко-часов на то, чтобы просто повторить то, что есть невообразимое. А еще надо новое развивать.

Один з основних замовників раста у ядрі — гугл.
це той самий гугл який вже багато років троимає свою гілку ядра для андроіда.
другий замовник, як не дивно, майкрософт.
це той майкрософт який як базу для edge використовує хроміум (тоб то забобон використовуати гугловий код немає).

Так вперед, що в цьому поганого?

Форк зробити можуть, але практичний результат переписування і тестування важко очікувати на такому масиві коду.
Для прикладу — rust community переписує gnu coreutils вже напевно з років 10, і по функціоналу ще досі не зрівнялась (десь %70 початкового досягла якщо не помиляюсь), і це по готовому практично без змін коду значно меншого проекту.

Немного технического контекста про саму драму.

Во-первых, стоит привести ссылку на саму дискуссию, а не читать перевод какой-то статьи: https://lwn.net/ml/all/[email protected]/

Команда Rust for Linux сделала diff, который добавляет Rust обертку над некоторыми функциями DMA подсистемы Linux. DMA это фича, которая требуется для большинства серьезных драйверов, которым нужен высокий перформанс, которую использует куча драйверов.

По сути, они добавили еще одного пользователя DMA, в добавок к тем, что уже существовали.

На 8 ревизии мейнтейнеру DMA (который не работал с этим дифом до ревизии 8) этот подход не понравился, и он сказал, что (таки да) не должно быть отдельного файла с Rust обертками, вместо этого каждый драйвер должен реализовать свои обертки, по сути копировать их с одного драйвера в другой. (Просто вдумайтесь в логику этого требования вне контекста ядра линукса, а просто в контексте разработки программного обеспечения, чтоб понять уровень аргументации противников Rust, которые хотят чтоб было как раньше.)

Когда ему возразили, что это противоречит тому, как делается code reuse в линуксе, чувак объяснил что просто намере блокировать добавления Rust любыми способами и срач вышел за пределы mailing list.

Боже, які люди! Так давно вас тут не бачив, як ся маєте?

Ну абстрагуючись від ядра Linux всеодно звучить дуже дивно.
Є код написаний на c. Є різні драйвери які юзають цей компонент через свої обгортки. Поки все вірно?
Так чому я маю ці обгортки на усі на світі мови пхати до основного ядра?
Ні ніхто не має копіпастити у кожний драйвер. Зробіть окрему репу Dma for rust і підключайте у проект драйверу
Наче ж так виглядає розробка здорової людини

Ні ніхто не має копіпастити у кожний драйвер.

Чувак, который заблочил работу над дифом, гооворит, что таки должны копипастить.

Зробіть окрему репу Dma for rust

Это было бы разумно (и так бы сделали), если б линукс было разбит на неколько репозиториев и была система сборки, которая может с ними работать. Но это не так — весь линукс это один монорепозторий.

Это было бы разумно (и так бы сделали), если б линукс было разбит на неколько репозиториев и была система сборки, которая может с ними работать. Но это не так — весь линукс это один монорепозторий.

Ну... є приклад модуля ядра Linux на Zig, був проект Ada Linux Kernel Module Framework, який дозволяє писати модулі ядра на Ada, при цьому жодної підтримки цих мов у ядрі не треба. Тому я не дуже розумію, навіщо потрібна підтримка Rust у ядрі. Так, можливо архітектурно це буде виглядати краще, зменшиться копіпаста, ... Але це не виглядає критичним, щоб блокувало розробку: викликається твій ko, ти в нульовому кільці на можеш робити усе що тобі заманеться.

А от маркетинговий ефект від підтримки Rust в ядрі є — у менеджерів буде більше довіри дозволити розробку модулів на Rust.

Ну... є приклад модуля ядра Linux на Zig, був проект Ada Linux Kernel Module Framework, який дозволяє писати модулі ядра на Ada, при цьому жодної підтримки цих мов у ядрі не треба.

github.com/...​a_Kernel_Module_Framework

Последний комит: 7 years ago
ок

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

А так одна людина, як хобі проект, за рік (з перервами на декілька місяців), ніяк не турбуючи розробників ядра, в окремому репо робить проект, який дозволяє використовувати Ada як мову написання драйверів Linux.

І ми маємо Rust for Linux, який почав роботу в 2020 році, спонсорується корпораціями, вимагає якоїсь підтримки, дьоргає розробників, ...

дьоргає розробників, ...

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

По-перше, хочеш плати, хочеш — не плати. По-друге, в Linux Foundations є не тільки ядро. По-третє, цікава частка тих, кому цікавий Rust.

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

То что кто-то что-то запилил 7 лет назад, забросил, чем никто не пользуется, значит что практически этот проект мертвый и приводить его в качестве аргумента где люди пытаются сделать живой проект неуместно.

І ми маємо Rust for Linux, який почав роботу в 2020 році, спонсорується корпораціями, вимагає якоїсь підтримки, дьоргає розробників, ...

Да. Еще куча срачей по поводу того, нужен ли Rust в ядре вообще или нет. Это признаки того, что проект подает признаки жизни и имеет шанс на дальшнейшее развитие.

Заметь, нет ни одного срача на тему нужна ли Ada в ядре или нет, или пушбека от мейнтейнеров. Странно, да?

кто кто-то сделал, протолкнул, убедил других в их жизнеспособности, создал достаточно инерции, чтоб оно двигалось, на чем начали работать критические вещи.

Якщо брати великі корпорації, то там дуже багато політичних питань. У випадку Rust, як я розумію, знайшов кошти в бюджеті великих корпорацій. Такі проекти відкриваються та час від часу закриваються. Але дивимося на прогрес. Проект почато у 2020. Перший реліз жовтень 2022. А ще досі треба «особлива» підтримка з боку ядра, якої, в принципі, не мало би бути. І ще досі дискусії, чи це треба, тобто за п’ять років це доволі неочевидно.

Заметь, нет ни одного срача на тему нужна ли Ada в ядре или нет, или пушбека от мейнтейнеров. Странно, да?

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

Як на мене, варіант, коли одна людина за рік як хобі переконалася, що писати драйвери на Ada можлива але нікому не треба, набагато краще, ніж коли створюється проект, залучаються розробники, п’ять років намагаються щось розробляти, конфліктують з ключьовими розробниками, ... До речі, я бачив оцінку, що якщо проект не вистрілює за три роки, то його варто закрити. Ну то таке.

Станом на зараз Rust цілком опціональний, його легко можна викинути з ядра, легко можна скомпіляти ядро без Rust:

scripts/config --disable CONFIG_RUST
більше того, якщо Rust не знайдено, то так і буде. Тому для мене це більше спроби більше піару та знайти виправдовуння... От ми, якби нам дали шаблю, всіх би порубили, ....
Станом на зараз Rust цілком опціональний, його легко можна викинути з ядра, легко можна скомпіляти ядро без Rust:

===========вы находитесь здесь===========

* Вот когда раст станет обязательным для сборки ядра, тогда и погооврим

Умные люди уже поняли, что Rust в ядре это факт, он или станет мейнстримом или будет в мейнстримовом форке, на который перейдут самые крупные пользователи линукса. Умные люди, занимающиеся разработкой линукса, уже закупили учебники и учат как использовать борроу чекер, остальные, судя по всему, пока что затягиваются копиумом.

Вот когда раст станет обязательным для сборки ядра, тогда и погооврим

Але попереджаю, у цьому році мені виповниться 50.

на который перейдут самые крупные пользователи линукса.

Була така байка, як великий банк витратив два мільярди доларів, щоб переписати код з COBOL на Java, але потім відмовився.

У багатьох ще Linux Kernel 3, їм вистачає. Переписувати купу існуючого легасі коду... Анріл.

оптимісти весело проводять час, песимісти запасаються тушонкою, реалісти АК і набоями

Цей враппер, легко може бути окремою лібою в окремому репозіторії, для Rust. Власне у Rust є Сargo щоби боротись із DLL Hell, навідміну від С — через наявність якого Linux, історично моно репозіторій. Станом на зараз Linux дуже поважний по віку программний проект, який є системним фактично увесь ІТ копіює модель його роботи, від розшарених папок 1991 до усього того що ми вважаємо сучасною системою розробки і побудування росподіленої через інтеренет ІТ команди і т.д.. Докі Лінус не вирішив цю проблему написавши свій аналог : dpkg, Conan, pacman і т.д. як він створив Git замість Mercurial, чегової поділки Mozilla яку просували як і тепер Rust. Власне для прикладного рівня частково pkg-config вирішує проблему (дивлячись що за репозіторій і т.д.), та не для ядра.

Цей враппер, легко може бути окремою лібою в окремому репозіторії, для Rust.

Т.е. все растовские враперы будут в репозитории ядра линукса [1], раст драйверы в репозитории ядра линукса [2], а враперы для DMA будут где-то в отдельном репозитории? Из-за одного упрямого мейнтейнера одной подсистемы люди начали терять способность логически мыслить и принимать рациональные решения

1. github.com/...​d437e99e119e3/rust/kernel
2. github.com/...​s/gpu/drm/drm_panic_qr.rs

Логически — ядро имеет архитектуру, модульный монолит и то что сейчас есть в репозитории модульным назвать очень сложно. Там все в куче, скажем если я захочу собрать ядро для x86_64 то или буду смотреть форки дистрибутивов ядра от создателей дистрибутивов, скорее всего или затяну к себе просто все с кодами для : ARM, PowerPC, RISC V и т.д.
Но чтобы иметь возможность нормально мейинейнить большой проект с кучей зависимостей каждый из которых лежит и мейнтецнится где-то в отдельном репозитории, нужен пакетный менеджер зависимостей типа : Maven (исторически один из первых) Cargo, Conan, pacman и т.д. Линус как известно все такие тулы пишет исключительно самолично.

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

Отзыв инженера, который написал видеодрайвер для Линукса на расте, причем сделал это еще в 2022 году (когда поддержка Rust в ядре была в гораздо более примитивном состоянии):

x.com/...​&t=-xZcnMAhYrlA7iFS9WNz9w

Усе залежить від Лінуса Торвальдса. Раніше він залишався нейтральним, але тепер його рішення може визначити майбутнє Rust у Linux.

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

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

вирішують проблеми, яких не було

www.cvedetails.com/...​t/vendor_id-33/Linux.html

Искать по ключевым словам «out of bounds access», «use after free»

Я пролистав декілька сторінок і бачу, що практично всі ’use-after-free’ помилки задетекені Касаном були саме в драйверах. Пан Торвальдс же з барського плеча дозволив всім бажаючим обмазуватися растом в драйверах. То в чому тоді проблема? Нехай покажуть себе пока в цьому, а там буде видно.

Вы почитали тред на lwn? Проблема в том, что мейнтейнер DMA не хочет, чтоб был Rust врапер для DMA API, который требуется (checking notes) для разработки драйверов на Rust. В этом проблема.

Не те, щоб критично потрібен. Ще можна подивитися щоб додати модуль rust-wrappers.ko якій би усі використовували. Але в принципі позиція зрозуміла, він не хоче, щоб кодова база, за яку він відповідає, розросталася, особливо тим, у чому він не тямить.

Не те, щоб критично потрібен.

Не то чтоб «критически» нужен, просто без DMA нельзя реализовать большинство драйверов, которым важен перформанс, а так в принципе больше ни для чего не нужен.

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

Ну это очень тупая и непродуктивная позиция.

Завтра кто-то напишет драйвер на C, в котором у него не будет времени, квалифиакции и желания разбираться. и отакжется от какой-либо помощи. Он так же остановит разработку драйвера?

Оскільки я зрозумів, то використовувати DMA можливо, але треба копіпастити код. Тобто мова йде про архітектурне покращення, а не про критичну неможливість використовувати DMA. Тому фікс не критичний.

Завтра кто-то напишет драйвер на C, в котором у него не будет времени, квалифиакции и желания разбираться. и отакжется от какой-либо помощи. Он так же остановит разработку драйвера?

Він відповідає за ядро, а не за окремі драйвери, які пиши хоч на паскалі. То не його проблема.

Просто тре викинути всіх цих старих пнів з лінукса, торвальдса першим, і всіх інших за ним.

Сильно багато пнів прийдеться викидати. RJW не потягнуть, обісруться. Може в такому разі растерам варто написати свій кернел на расті? Чи їм слабо?

Нащо писати нове, якщо треба ремонтувати старе.

Ну, кльово, так у хулі тоді растери лізуть в сраку Торвальдсу?

Rust for Linux был приглашел и поддерживается самим Торвальдсом.

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

проблема в тому, шо ти чогось пише про растерів і сішників.
але 90+% коду ядра додають працівникі корпорацій. також корпорації платять внески в Linux Fundation, де більшіть мейнтейнерів і працевлаштована.

тому не "

так у хулі тоді растери лізуть в сраку Торвальдсу?

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

Отже, мало заплатили тому діячу, що «зарубав» зміну...
Або ж він попав в ті 10-%, що якраз працюють нахаляву на громадських засадах...

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

рубанув правду матку як Вєнтс в Мюнхені

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

підтримка повинна залишатися на комфортному рівні для тих, хто цим займається

Внезапно, люди, которые пилят поддержку раста в ядре линукса и начинают пилить драйверы на расте — это и есть «те, кто этим занимается».

Разработка ядра линукса не была «на комфортном уровне никогда», это мягко говоря токсичная агрессивная среда, куда большинство людей идут по острой необходимости.

свербить все будувати на Расті і він лізе туди, куди його не кликали з цим.

Понимаешь, чтоб замерджить поддержку Раста в ядро линукса, нужно самому быть разработчиком ядра линукса? И как бы не то, чтоб активно звали, но у Rust for Linux поддержка серьезных мейнтейнеров Линукса (в т.ч. самого Торвальдса). Т.е. ситуация немножко не «вы принесли Rust куда вас не звали».

Постає інше питання, а нахера той Раст потрібен в проекті, який написаний на С? Я розумію плюси цієї мови, нахера він конкретно тут?

Я не знаю насколько хорошо вы знаете Rust. Опишите плюсы Rust, которые вы понимаете, я могу описать зачем они в ядре линукса, или укажу, что вы не знаете о некоторые плюсы.

Опишите плюсы Rust, которые вы понимаете

«Впевненість якщо щось збирається, то воно буде добре працювати».

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

«Впевненість якщо щось збирається, то воно буде добре працювати».
fn main() {
    todo!();
}

Вот это тоже собирается, но работать хорошо оно не будет.

dou.ua/...​rums/topic/52446/#2933423 — вот тут привел один пример фичи (enums), которая вмолне себе приносит плюсы в ядро линукса.

Це цитата не від мене, то було однією з причин коли за-orphane-ли bcachefs-tools в дебіан бо неможливо їх супроводити (майже зразу після їх rust-изації). Тобто в переписуванні на rust зараз бачуть більш мінусів (по цьому прикладу) ніж плюсів, це те що вже з чим стикнулися (навіть при тому що rust софта мізер в репозиторіях).

p.s. без загальної картини розгляд якоїсь однієї фічі в раст чи сі тут іррелевантен

Я боюсь что никто не будет делать вам серьезный анализ общей картины, если вы не в состоянии проанализировать хотя бы одну фичу, на описание которой уже потрачено время.

> серьезный анализ общей картины
>
і того ніхто й не очікує на неспеціалізованому форумі де відбувається обмін думками і поглядами на ту чи іншу тему з різних аспектів. Потім — якщо ви подивитесь уважно — то нотатка щодо (ір)релевантності стосується спроби привести якусь одну специфічну фічу (щей доволі невдалу в порівнянні) у відповідь на акумульовану характеристику (вважайте її фіча в плюс чи в мінус в залежності від своїх поглядів) характеристику сподівань у значної частини раст кодерів (з точки зору супроводу софта).

p.s. взагалі я досить скептично відношусь до пропозицій мірятись ее.. довжиною окремих фіч, і цей випадок не виключення

нахера

у вас DRY не дотримується в одному абзаці

залишатися на комфортному рівні для тих, хто цим займається

Тобто розробка на С комфортніша за Rust? Звиняйте.

Ті хто в основному пишуть на сі — звичайно скажуть що сі значно комфортніше, ті хто пишуть go — зручніше на go, ті хто юзають раст — скажуть раст, і т.д.
Тут же питання в сумісності з існуючою базою, кодом, апі, і т.п. Нп навіть підтримка раст софта може бути проблематичною — бо обрали зовсім інший підхід до стандартизації (обираючи постійний rolling, зміну abi, ..).

а вдобна С екосистема, це автмейк, лінк, білдрут, йокто ...
а є розробники ПЗ, які користуються кількома мовами програмування, а не одною

підтримка раст софта може бути проблематичною

а може і не бути
а в С це не проблематично, бо ...

> а вдобна екосистема, це автмейк ..
>
зручно те що зручно комусь персонально і підходить для вирішення задачі,
якщо комусь достатньо autotools (autoconf/automake) — він їх буде використовувати,
комусь зручніш буде значно meson нп, а ще хтось обере білд тулзу з фреймворка який використовує.
— коли білд тулза існує тільки одного типу (в dart/go/rust/...) тоді навіть розділу на зручно/незручно не існує по суті — все одно нема з чого обирати — тулза тількиж одна

> розробники ПЗ, які користуються кількома мовами програмування
>
так і є — зручно використовувати для якоїсь задачі python — пишуть на пайтон, зручно десь go — пишуть на go, і т.д. Вибір тулзи(фреймворку, мови програмування, і т.п) залежить від задачі, а не навпаки (знаю пайтон — все треба писати на пайтон, знаю сі — все треба писати тільки на сі, знаю раст — все треба ...)

> а може і не бути
>
може і не бути, але достатньо відомі приклади протилежні до «може і не бути»

проблема в *toml вписати версії модулів, чи в чому?

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

а якщо кілька рівнів, одна на С++, друга на Java/Котлін і це поверх білдрута з ядром і драйверами на С, скриптами зборкою bash та gradle, плюс SQL, JSON, YAML, XML, HTML ...?
То якщо проблема, то проект зупиняється, бо «я майнтейнер і не змушуйте працювати з вашою модною мовою»?

> проблема в *toml вписати версії модулів, чи в чому?
>
це щодо богатого вибору в рамках однієї тулзи? — білд тулзи взагаліто то трохи більш ніж вписування номеру версії

> То якщо проблема, то проект зупиняється, бо кожен тільки в свій клітці
>
оця драма з rust якраз на цю тему — що якщо схрестити сі і раст, і чи чекати на проблеми...
— питання відкрите

ніби ж проблеми одні й ті ж «відстрілювання кінцівок», не так як С++ але дехто каже, що не буду пристібати ваші модні ремні безпеки, бо це не для чотких пацанів

Дехто (звичайні м̶е̶н̶т̶е̶й̶н̶е̶р̶и̶ ретрогради звичайних лінукс дистрибутивів) — та ну його.. ресурси жре неміряно, постійно новий тулчейн несумісний бінарно: — ні, ми пас, підтримуйте самі. А rust кодери так — нє-нє, ми тільки код пишемо, і якщо у нас збирається значить буде скрізь робити, а ваші модні ремені безпеки це з минулого століття, треба все по новому (але ми самі робити не будемо, краще ви).

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

шо мішає переписати форк?

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

Ось перший-ліпший приклад форків en.wikipedia.org/wiki/Kamailio#Timeline
А ще Хроміум десь форкався з Еплом туди-сюди.

А ще Хроміум десь форкався з Еплом туди-сюди.

Куди він форкався? Blink не являється форком вебкіта.

Chrome initially used the WebKit rendering engine to display web pages. In 2013, they forked the WebCore component to create their own layout engine Blink. Based on WebKit, Blink only uses WebKit’s “WebCore” components, while substituting other components, such as its own multi-process architecture, in place of WebKit’s native implementation.
en.wikipedia.org/wiki/Google_Chrome

Навіть у Linux можна пригадати Android Kernel, та подивитися на Real-time Linux, Zen Kernel, ...
Я думаю, що спільнота прекрасно розуміє, що саме форк яскраво покаже, що Rust нікому не потрібен, бо нічого не дає.

OpenTofu — форк Терраформа. Дженкінс — форк Хадсона. ЛібреОфіс — форк офісу від Оракла. Якщо пошукати, то таких прикладів буде не мало.

І тут аналогію можна знайти:
як при попередньому хайпі з safe language (Java) — додавши в зовсім іншу і несхожу мову слово java і схоже трохи лого — javascript притягнув якусь долю менеджерів і уваги з того хайпу завдяки схожості для тих хто не в айті, навіть не маючи нічого спільного з java. Так і тут може бути — інвестиції в раст-лінукс десь підуть на розробку за допомогою сі. А бо ще цікавіше — назвати мову trust (safe language 2nd generation), і на чистому місці притягнути купу уваги і іншого в новий проект.

думаю, щодо С++ марні сподівання

Народ каже, що їм в автомотів проект просочився компонент на Расті. Результат:
* Час збірки _усього_ проекту збільшився в рази
* Збірка почала жерти стільки оперативи, що на ноутах доводиться ставити менше потоків збірки ніж наявна кількість ядер процесора.

doc.rust-lang.org/...​go/reference/timings.html

Проверить что именно тормозит, проверить, нужно ли оно или нет.

Часто подключают какую-то зависимость с кучей фич, включенных по умолчанию, которые не используются, которые сильно замедляют компиляцию, и которые можно отключить.

которые можно отключить

Да фиг тебе кто-то даст отключить, если включил менеджер, который считает, что Раст нужен.

Часто подключают какую-то зависимость с кучей фич

Так, і ця залежність — сама по собі собі збірка растового тулчейну з cargo, а також LLVM для збірки того тулчейну, коли до цього все обходилось одним GCC, бо хтось в сішний проект захотів зручненько імпортнути растову лібу з cargo.

Так, можливість таких різких і потужних змін залежностей це специфіка Yocto, так, можна підняти локальний сервачок з закешованим пребілдженим тулчейном, але причин ненавидіти раст різко додає.

Rust релизится раз в 6 недель. Если вам приходится его пересобирать его чаще, то проблема скорее всего не в самом Rust.

Так, проблема в стандартах розробки emdebbed: спочатку треба збілдити тулчейн, а потім вже ним білдити образ для стабільності, щоб уникнути використання різних несумісних тулів.

Можно сбилдить тулчейн, сохранить собраные артефакты куда-то на дисковый сервер, и потом оттуда его использовать, пока не зарелизят новый тулчейн.

Какой смысл пересобирать тулчейн каждый раз, когда изменил одну строчку кода в своем приложении?

Проблема у тому, що треба переключатися між бранчами. Наприклад, треба переключитися на баг, який репродюситься на версії 3.14 де був інший тулчейн.

Нажаль, розробки нелінійна.

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

але причин ненавидіти раст різко додає.

На моей прошлой работе у меня вырасле ненависть к Ruby. Мне даже не приходилось писать на нем, просто пересобирать несколько раз в день, и одна сборка занимала где-то полчаса. И для тех кто не знает, Ruby — интерпретируемый язык, который вообще не требует компиляции.

Есть builder tools, котоыре сделаны по дибильнмоу, нужно понимать где проходит граница между проблемами дибильных builder tools и тулчейна самого языка программирования и адресовать ненависть в правильном направлении.

Borrow checking і може ще деякі analysis, то головний чинник дуже повільної компіляції (порівнюючи з c). А без цих «фіч» це вже не rust буде, та й не відключаються вони.

Есть вариант с переписыванием на Го

Хочется чтоб не просто компилировалось медленно, но еще и работало медленно?

Попробуй что-то нормальное запустить типа Mimir, Tempo, VictoriaMetrics а не свой говнокод — вероятно увидишь разницу
А так компиляция быстрая если использовать нормальный проц а не ноут прабабушки на амд 2007 года
Ну и если не учитывать кодоген

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

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

зато вона працює а не просто збирається

Хто вона? Якщо мається на увазі ліба, то вона і сішною працювала. Оця до речі самовпевненість в раст комьюніті що «якщо збирається то працює» — було однією з причин чому викинули іншу одну софтінку з дебіан репо.

От не надо тут про раст комюніті сказки розказувать.
Типу прийшли злі растомани і всіх паламали.
бо, як і librsvg перевів на раст некій Federico Mena Quintero, який підписується як GNOME co-founder (gitlab.gnome.org/federico), так і в ядро раст пхають не ззовні. Ініціаторами виступили діючі мейнтейнери.

> раст комюніті сказки розказувать
>
це з дебіан комюніті «сказки», які наведені бо — «якщо збирається то працює» — дуже нагадало reasoning того що відбулося з супроводом bcachefs-tools в debian

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

Оця до речі самовпевненість в раст комьюніті

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

GNOME co-founder

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

> чувак. давай ка
>
хмм.. цікавий спосіб дискутувати..

> слідкуй за контекстом
>
чувак дуже влучно (так правильно починати речення?)
«Час збірки _усього_ проекту збільшився в рази, Збірка почала жерти стільки оперативи»
— що співпадає з моїм особистим досвідом збирання однієї rust ліби на low-profile залізці,
який і розшарив. Якщо є досвід протилежний — велкам поділитися.

> GNOME co-founder, а не якийсь нонейм з раст-комюніті
>
це іррелевантно до кількості ресурсів які потребує збірка rust софт.
Якщо ж є бажання вийти далеко за рамки контексту і поговорити (і не для драми) про rust в gtk проекті і reasoning в цьому окремому випадку — створіть окрему тему на неї (якщо є досвід роботи з gtk офкос).

> також весь цей срач відбувається навколо додовання раста в кернел... платінеові спонсори і діючі мейнтейнери
>
немаю нічого проти дискусій про додавання раст в linux project (хоча і не дуже подобаються драми навколо того)

>> зато вона працює а не просто збирається
> самовпевненість в раст комьюніті
>
цитую частину різонінга «Orphaning bcachefs-tools in Debian»:
I found this a bit disturbing, but it seems that some Rust people have lots of confidence that if something builds, it will run fine.

раст плохо миксуется с си и такой микс зачастую приводит к unsafe коду в расте, сводя на нет его главное преимущество

плюс ядро ОС достаточно специфичная штука, нужны правильные специалисты, которые выработают новый дизайн, который был дал максимальный профит от использования раста

короче, или кто-то со светлой головой, прямыми руками и полномочиями диктатора передизайнит на хрен все ядро (что мало вероятно) или профит от использования раста будет минимальный и постоянно будут такого рода срачи

раст плохо миксуется с си и такой микс зачастую приводит к unsafe коду в расте, сводя на нет его главное преимущество

плюс ядро ОС достаточно специфичная штука, нужны правильные специалисты, которые выработают новый дизайн, который был дал максимальный профит от использования раста

Собственно, эти правильные специалисты и занимаются тем, что пилят Rust инфраструктуру в ядре линукса и потихоньку ее мерджат.

короче, или кто-то со светлой головой, прямыми руками и полномочиями диктатора передизайнит на хрен все ядро (что мало вероятно) или профит от использования раста будет минимальный и постоянно будут такого рода срачи

В lkml такого рода срачи продолжаются последние 30 лет, Rust for Linux ничего особого не добавил и не убавил в качестве дискуссий.

Там дискусія давніша, зліша і фундаментальніша...

Є правило: той, хто вносить «брейкінг ченджз», повинен поправити й всі місця де він поламав... зокрема якщо така зміна в Сшці, то тепер Сшний автор повинен буде фіксити й депендент частини на Rust які зміна поламає, отже, власне, знати Rust, що й викликає відповідний супротив...

А самі Rust розробники теж дуже «не в захваті», що ніде не специфіковані явно оті лайфтайм та овнершип штук, з якими вони взаємодіють з Rust... Єдина порада «наслідуй існуючий драйвер, фоловай його конвеншенам», що, насправді, зовсім нічого не говорить про оті лайфтайми (певно, їх не знають й самі Сшні розробники, а це велика печалька:))

PS: Окрема «баттхертна» тема: а що тепер для dkms треба буде не лише Cшка а й Rust на кожній машині?

Треба переписати усе на Rust. У цілому усе ядро побудовано на двозв’язних циклічних списках, які просто неможливо реалізувати на Rust без unsafe. А з unsafe незрозуміло, де зменшення критичних помилок управління пам’яттю.

C та Rust просто не сумісні у стилі розробці, тому міксувати їх не вийде. Спілкування можливе лише через чіткі інтерфейси у межах незалежних систем.

Спілкування можливе лише через чіткі інтерфейси у межах незалежних систем.

Для цього потрібне стабільне ABI, якого у расту офійійно відсутнє.

Для цього потрібне стабільне ABI, якого у расту офійійно відсутнє.

Rust поддерживает C ABI в обоих направлениях (C вызывает Rust код и Rust код вызывает С код), собственно именно так делается интеграция между C и Rust компонентами последние 17 лет.

Also в Linux Kernel также нет стабильного ABI. ABI стабилизирован между ядром и user space, но не между компонентами ядра.

Rust поддерживает C ABI в обоих направлениях

Загортання якого-небудь skb туди-сюди буде вбивати весь перфоманс, потрібна більш пряма інтеграція. А де можна обійтися повільним стабільним ABI, там можна просто винести драйвер в юзерспейс, зоопарк FUSE-файлових систем наглядно демонструє переваги і недоліки такого підходу.

Треба переписати усе на Rust.

объем работы себе представляешь? сколько нужно времени и денег для этого?
прекращаем развитие и уходим на ближайшие 5 лет в полное переписывание? чтобы через три года понять, что это была плохая идея и все выбросить в мусор?

Так, я розумію обʼєм. Я розумію ризики, що результат вийде навіть гірше. «Треба» означає, що міксувати мови взагалі не варіант, ІМХО. Тому єдиний шлях писати у ядрі на Rust це написати власну OS на Rust. С++ я можу уявити, Zig теж можна уявити, але Rust...

С++ я можу уявити

Скажи, что ты ничего не понимаешь в разработке ядра Линукс, на говоря, что ты ничего не понимаешь в разработке ядра Линукс.

Це не те, що я можу уявити, я бачив С++ у кастомному модулі драйвера Linux на власні очі, бо треба були шаблони. Які проблеми це зробити?

Які проблеми це зробити?

Проблема в том, что все попытки сделать это втечение последних 30 лет встретили сопротивление, которое не сравнимо с сопротивлением, которые имеет Rust for Linux

У власному (проприєтарному) модулі пиши хоч на Haskell. Зроби форк та пиши на Zig. Тут мова не йде про домовленості та суб’єктивне бачення. Тут мова йде про принципову можливість, чи можна прийняти таке рішення.

Те, що Лінус «вперся» проти С++ ніразу не значить, що С++ в ядрі «принципово неможливий»! Якщо переступити через «затяті принципи» й обрати правильний сабсет «плюсів», той, що «C з класами без RTTI та ексепшенів» тоді навіть деякі «модні штуки» типу отих всіх Result та Either цілком можливі, бо вони, насправді, недалеко втікли від std::optional та std::variant))

Так, так, я знаю що Result правильно трекає юзедж і все таке, а всякі [[nodiscard]] це «нето», але факт в тому, що своєю впертістю проти «плюсів» те лінухове ком’юніті злосно обіср@лося (так само, як воно зараз обіср*ться ще й своєю впертістю проти Rust)

PS. Втім, в «неприйнятті» C++ також є заслуга й самих «плюсів»: вірніше того, як їх викладають, і як то «зазвичай прийнято» все робити в такому стилі, ніби то була Джава...

PS. Втім, в «неприйнятті» C++ також є заслуга й самих «плюсів»: вірніше того, як їх викладають, і як то «зазвичай прийнято» все робити в такому стилі, ніби то була Джава...

Заслуга не только в этом, а в том, что подмножество C++ настолько сложное, нелогичное, и, прошу прощения за мой французский, епанутое, что даже Rust не лежал близко по уровню сложности, нелогичности и епанутости.

Случай не втом, что кто-то демонстрирует необоснованную враждебность к C++, связанную с незнанием, случай в том, что люди демонстрируют обоснованную враждебность к C++, связанную со знанием.

Небольшой анекдот. У меня был опыт обширный опыт работы и с C и с Rust. Я смог осилить C и Rust на уровнях, где я могу комфортно и продуктивно работать.

На новой работе мне дали работать с C++. Я думал, что раз я осилил C и Rust, я осилю С++. После прочтения нескольких книг с довольно глубоким проникновением в некоторые фичи С++, я понял, что я сильно ошибался.

И чтоб не быть голословным, начну с того факта, что есть книга, которая называется C++ 11 move semantic, в ней 264 страницы. На этом и закончу.

Це питання доцільності, тут я підтримую.

Все вірно, тому й кажемо про сабсет... ;)

C++ 11 move semantic, в ней 264 страницы

Автор просто заробляв гроші за кількість сторінок...
А зрозуміти ідею «move semantic» легко «на побутово-інтуітивному рівні» без вникання в божевільні деталі glvalue, xvalue, prvalue і тд... «move semantic» — то є спосіб перевантажити за темпорарі значенням (звісно «представлення переміщується» не так елегантно й довершено, як передача овнершипа в Rust, але, втім, інтуітивно дуже проста штука)...
...легко запам’ятати конкретний юз (й цього, зазвичай, достатньо), ніж всю ту божевільну «механіку» внутрішньої термінології С++, як воно мапується на правила мови))

«професійні книжкопісатєлі», здається, самі не програмують, тільки читають С++ стандарт й одразу пишуть свої книжки... а якщо читати стандарт, то дійсно нічого незрозуміло, проте все то само про, наприклад, до... ЖС. ECMA-262 читати практично неможливо й практично нічого незрозуміло з того брєда, зате є MDN, де не пишуть такої фігні, й можна зрозуміти мову побутово-інтуітивно))

Справжнє зло (й трагедія) С++ в тому, що люди тулять надмірні абстракції там, де того непотрібно, й пишуть на С++ так, якби це була Джава (або MFC)!
Тому так, для новоно проекту на роботі я б обрав Rust саме для того, щоб відсікти тих людей в кого «MFC головного мозку» (я й сам вже «старпер» але «ті» способи, що були «прийняті» в той час я завжди ненавидів...)

А зрозуміти ідею «move semantic» легко «на побутово-інтуітивному рівні» без вникання в божевільні деталі glvalue, xvalue, prvalue і тд.

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

А компілятори най реалізовують згідно формальної спеки))
Кожен «простий смертний» не пише компілятора, йому не треба формальна спека.

Для «простих смертних», хто не брав участь в «дискусіях комітету», всі оте (наприклад) про «value categories» — до лампочки. Для роботи на проектах має бути саме «побутово-інтуітивне розуміння», що можна присвоювати, й до чого саме можна присвоювати, й коли тимчасове значення можна «стирити» ))

Але якщо «рядових девелоперів» заставляти завчити на пам’ять формальний брєд, типу такого, то це аналіз-параліз, й ніхто не зможе працювати... Неможливо ні за які терміни заставити людей буквально зазубрити як мапуються ті перечислення частинних випадків, що повністю покривають кожен юз в формальному докові, зато можна дати можливість інтуітивно зрозуміти ідею «за допомогою && стирити мувнути контент від того тимчасового значення, яке зараз зникає»...

То само й про решту мов програмування: формальні спеки — для розробників компіляторів (також для ср@чів, в стилі про JavaScript WTF коли формальна спека приписує дикі, неочевидні та неінтуітивні речі, що «то так і має бути»))...

Неможливо вивчити ЖС читаючи брєд сивої кобили стандарт ECMA-262 (зато теж й всі реалізації ЖС працюють «приблизно однаково», бо ECMA-262 все заспецифікували детально! і це прекрасно)... Але в ЖС є свій MDN, а в С++ — нема... (cppreference не годиться, бо то майже такий же формальний брєд! Стандарт мови — це чудовий ресурс для спору про те «чи то по стандарту», «чи не по стандарті» (щоб доказати впертюхам, що в стандарті ніякого __attribute__ cleanup не існує, і що улюблені багатьма «пакращення» у вигляді -fplan9-extensions, то теж ніразу не стандарт !!!), але формальний ресурс абсолюстно непридатний для навчання мові програмування)...

То саме, до речі, й навіть про... математику: поняття похідної та інтегралу дуже прості, легкозрозумілі та інтуітивні (звісно, доти, доки не почати то все формально доводити через неспадаючі/незростаючі збіжні послідовності, «правило Лопіталя», та решту «лем» за якими 99% випускників вже не розуміють правдивої інтуітивної суті)... Та навіть арифметику буде неможливо викладати в школі, якщо почати дітям доводити теорію чисел через аксіоми Пеано...

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

Кожен «простий смертний» не пише компілятора, йому не треба формальна спека.

Це так. Але простий смертний користується компілятором. І може бути, що йому треба бути перейти на інший компілятор, де у його інших розробників було інше інтуїтивне розуміння move-семантики, та його код перестає працювати — це проблема.

Думаю, що формальна спека писалася с конкретної реалізації, яку писали не дурні, яки наступили на багато граблів при цьому, це просто відображення складності, яку нікуди не діти. Але вона буде стосуватися невеликого відсотку випадків. Комусь не повезе, більшість не помітить.

От коли той інший компілятор (або цей який прямо зараз) реалізує цю формальну спеку неправильно, тоді й доведеться «простому смертному» лізти в ті «нечитаємі» спеки й досліджувати «що нетак» (й взнавати, чи то старий компілятор був фіговий, чи то вже новий став фіговий)...
Допоки такого не сталося, то можна покладатися на надію, що автори компілятора (й бібліотек) строгу поведіку згідно стандартної формальної спеки реалізували самостійно!)) Ви ж не валідуєте формально щоразу по окремості кожну фішку компілятора супроти формальної спеки в стандарті, правда? ))

Але зазначу: «за всі довгі роки» траблів конкретно в розумінні «простими смертними» тої move-семантики, так щоб хтось наплужив саме через то, я не зустрічав ніразу.

Так, дійсно бувало, що люди «забирали контент» через std::move, а потім про це «забували» і продовжували юзати старий інстанс, а там вже «нічого не було» (отут якраз Rust й порішав би все класно, ага)...
Але оце «юз афте мув», то не є проблема «нерозуміння std::move», це інша проблема, того ж порядку що й «юз афте фрі», чи «подвійні деліти», та решта приколів, коли люди добре знають й чудово розуміють, що «так робити не варто/неможна», але продовжують так робити не «від нерозуміння», а через «неуважність». І, знову ж таки, руткоз не в «заскладній мові» а якраз в тому, що жива біологічна людина нездатна за всім вслідкувати.

Всі мови програмування однакові (якшо мова про «Тюрінг комплітнес»), але необхідність «слідкувати», «бути уважним та старанним», то також «складність» в мові (в програмуванні нею), вона є «найгадіша», бо таку складність неможливо «вивчити раз і назавжди», й в кожній ситуації «треба бути уважним по новому», тому, чим більше «бойлерплейту» вимагає програмування — тим гірша мова! Тому «ручками» malloc/free чи new/delete, «старанне та уважне» слідкування за відповідністю між read_lock й read_unlock — клінічний мазохізм... RAII — musthave фішка нормальної мови (і тому Rust класний, бо він насаджує ту фішку силою, а не як опцію!), «хоч якесь» RAII — musthave, або хоча б якийсь defer як в go, хоча б using як в C#, хоча б with як в Пайтоні (а оті всі goto Cleanp; то особливий клінічний затятий мазохізм, втім, як й набивання табличок VMT ручками, коли люди роблять «ООП на Сшці» й всі танці з бубном довкола ініціалізації (та клінапу в правильний момент) таких «класів»...)

____
PS. а лізти в стандарт весь час доводиться якраз для боротьби з нестандартними фічами та «розширеннями» що їх юзають розробники (-fplan9-extensions — це ж треба додуматися до такого, щоб спецом поюзати то, з іншого боку класна фішка, як й __attribute__ cleanup, тільки, нажаль, не в стандарті, втім defer був би ще краще).
Тобто по факту стандарт потрібен лише для тих юзкейсів щоб «натовкти мордочкою»: «це не мій компілятор кривий, то ти поюзав нестандартне розширення»...

Звісно, окрема біда-печаль та джерело траблів — UB, й зокрема strict aliasing (отут якраз, насправді, з «вордінга» в стандарті ніфіга не очевидно які то має «жахливі наслідки» для любителів робити cast, й тому гуглити статті з прикладами — саме то)

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

Я про те, що якщо немає формальної спеки, то це питання часу та везіння.

Але зазначу: «за всі довгі роки» траблів конкретно в розумінні «простими смертними» тої move-семантики, так щоб хтось наплужив саме через то, я не зустрічав ніразу.

А я от вже пригадав пару історій, коли реалізація вектора через елементи з конструктором переміщення не запрацювала. Коли я запитував як вирішили — відповідь була — переписав на вектор вказівників. Це про «інтуїтивне розуміння».

Так, дійсно бувало, що люди «забирали контент» через std::move, а потім про це «забували»

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

Всі мови програмування однакові (якшо мова про «Тюрінг комплітнес»),

А якщо мова не Т’юрінґ повна? Або якщо змушує розрізняти тотальні та не тотальні функції? Це дуже провокаційний вислів, тому треба пояснити яка «однаковість» мається на увазі, наприклад, що будь яка програма, написана на мові програмування A, може бути переписана на мові програмування B, як це тут. Це достатньо очевидно в більшості випадків, але знову, якщо ми відмовляємося від повноти по Т’юрінґу, ми можемо отримати гарантії що функція не зациклиться, не крешнеться та завжди поверне результат.

і тому Rust класний, бо він насаджує ту фішку силою, а не як опцію!)

Але усе має свою ціну, тому треба завжди оцінювати переваги та додаткові витрати.

Я про те, що якщо немає формальної спеки, то це питання часу та везіння.

а я про те, що мув семантику, лямбди, всі приколи з RAII (включно з праивлом трьох п’яти) суть темплейтів (якщо не заглиблюватися в «метапрограмінг») можна пояснити буквально «на пальцях»)) й C++ «не такий страшний як його малюють»...

Тобто я не проти «формальної» спеки, я про те, що в неї, зазвичай, лізуть коли «щось треба», а от «вивчити» її «всю» практично неможливо (вивчити по ній мову — практично неможливо))

А я от вже пригадав пару історій, коли реалізація вектора через елементи з конструктором переміщення не запрацювала. Коли я запитував як вирішили — відповідь була — переписав на вектор вказівників. Це про «інтуїтивне розуміння».

«щось тут нете»)) стандартний вектор при std::move переміщує своє представлення, а не свої елементи...

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

ем, з чим саме, з вектором? «щось тут нете» (ц)

Це дуже провокаційний вислів, тому треба пояснити яка «однаковість» мається на увазі

Я лише про те, що «всі на світі програми» можна переписати хоч на асемблері, хоч на брейнф@кові... (якщо кількість комірок нескінченна), але, все ж, на деяких мовах писати зручніше, ніж на інших. З того ж (умовно) С++ можна обрати «підходящий сабсет» (той ж RAII, темплейти, й халявне заповнення VMT самим компілятором, замість мейтененса табличок вручну, більша безпека типів і тд) сабсет такий, що чудово лягає і на написання ядер і на ембед...
Але ж ні «релігія не дозволяє»...
натомість всі оті
#define list_for_each_entry(pos, head, member) ...
всякі uthash... та «йо майо», ото такий «дженерік програмінг», ага...

Але усе має свою ціну, тому треба завжди оцінювати переваги та додаткові витрати.

гіпотетичний read_guard має таку ж ціну як й пара read_lock й read_unlock, але «поборці за читоту ядра» вперлися що лише окремі read_lock й read_unlock правильно (ну зараз дискусія вже не зовсім про те, але суть не змінилася... не хочуть люди примусового RAII, але деяким навіть опціональне не канає, причому у варіанті C++ інтеграція з існуючою Cшкою взазалі «нахаляву» бо C++ бачить всі хедери як є, й не треба повторювати APIшки переписуванням...)

ну але ок, проїхали, давайте полишимо С++, але ж Rust за продуктивністю практично нічим не гірше а його також «зафукали» як й C++...

«щось тут нете»)) стандартний вектор при std::move переміщує своє представлення, а не свої елементи...

Сортування злітало, конструктор переміщення був написаний для типу елементів контейнера.

Я лише про те, що «всі на світі програми» можна переписати хоч на асемблері, хоч на брейнф@кові... (якщо кількість комірок нескінченна), але, все ж, на деяких мовах писати зручніше, ніж на інших.

Я погоджуюся, просто є технічне зауваження, що якщо мова не повна по Т’юрінгу, до певні речі там не напишеш. Але зазвичай такі мови все ж таки дозволяють писати повні по Т’юрінґу програми з додатковими позначками типу unsafe.

ну але ок, проїхали, давайте полишимо С++, але ж Rust за продуктивністю практично нічим не гірше а його також «зафукали» як й C++...

Не деяких задачах може бути за замовченням навіть краще... Бо restrict проставити інколи досить муторно. Але алгоритм танцующих зв’язків реалізувати складно за вудсутності нормальних двозв’язних цикличних списків.

А насправді людей, яким Rust взагалі не цікавий, примушують в цьому розбиратися. От і реакція.

Сортування злітало, конструктор переміщення був написаний для типу елементів контейнера.

це вже більше деталей, але, все ж «тут щось нете»... а що, коли тільки з звичайним конструктором копіювання — працювало? (там мають бути обидва, а ще операція порівняння operator<, куди ж без того).

Для «стандартних контейнерів» це все — коммон кейс, що його вже, мали б «вилизати» в попередні роки... але є багато інших сюрпризів, наприклад, «бійтеся Winsows.h»: якщо алгоритм юзає min або max то у Winsows.h про це своя особлива думка (і не лише в нього) і не лише про min або max, в ще й про small, Yield, ANY, та решту штук (то все макроси й дефайн NOMINMAX та WIN32_LEAN_AND_MEAN не рятує)... але й без вінди всякі «допоміжні» ліби (навіть створені в межах компанії, або на боці замовника й жоден впертюх не поступиться щоб додати префікс) мають свої уявлення про «прості слова», всякі IO, IN, OUT, а ше і далі дефайнять всякі u16, u32 (хоча stdint.h вже давно існує) і навіть буває «канонічні» open, read, write макросами (POSIX плаче кривавими сльозами, вони також ті прості слова юзають) в кращому випадку не скомпілиться/не злінкується, в гіршому «вилізе боком» десь потім...

Я погоджуюся, просто є технічне зауваження, що якщо мова не повна по Т’юрінгу, до певні речі там не напишеш. Але зазвичай такі мови все ж таки дозволяють писати повні по Т’юрінґу програми з додатковими позначками типу unsafe.

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

Не деяких задачах може бути за замовченням навіть краще... Бо restrict проставити інколи досить муторно. Але алгоритм танцующих зв’язків реалізувати складно за вудсутності нормальних двозв’язних цикличних списків.

Це якраз та точка де всю «магію» треба «загортати разом», щоб «всередині» вона була «як проста Сшка», а тільки ззовні торчали зручні інтерфейси для обходів/модифікацій...
Не стану сперечатися про конкретні деталі, але, думаю, це можливо :)

А насправді людей, яким Rust взагалі не цікавий, примушують в цьому розбиратися. От і реакція.

ось це печалька, причому в двох вимірах:
1. Підходи в Rust — перспективна штука (не ручаюся за всю мову, але їхню «рекламу» й приклади я вже давно зацінив). Не знайти якогось рішення щоб «й вовки ситі, й вівці цілі» — велика сумулька...
2. Заставляти перевантажених людей, що й так працюють фактично у громадському проекті нахаляву, навалюючи нові додаткові обов’язки — то знущання.

то і є основна проблема всіх «халявних» проектів, ними починають займатися «бо це цікаво» (або «дуже треба»), а потім привалює нецікавих обов’язків нахаляву... звіти й та вся «пасивна агресія» й «токсичність» (типове «вигоряння»)

це вже більше деталей, але, все ж «тут щось нете»... а що, коли тільки з звичайним конструктором копіювання — працювало? (там мають бути обидва, а ще операція порівняння operator<, куди ж без того).

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

1. Підходи в Rust — перспективна штука (не ручаюся за всю мову, але їхню «рекламу» й приклади я вже давно зацінив). Не знайти якогось рішення щоб «й вовки ситі, й вівці цілі» — велика сумулька...

Так, перспективні, але не єдині, якщо чесно. Однозначної думки немає. Redox OS розробляється зі 2015 року (тобто 10 років) та ще не досяг стабільності. При тому, що Linux починав у 1991 році, та на початку 2000-х вже активно використовувався на серверах, RHEL з’явилася у 2000. Тому станом на зараз це скоріше експеримент, з цієї точки зору я не бачу жодної проблеми у тому, щоб розробники Rust копіпастили код, писали свої обгортки таке інше, доки дійсно не з’являться купа драйверів на Rust, і тоді це вже вийде за рамки експерименту, та матиме сенс.

Тобто була проблема, хотіли вирішити за допомогою конструктора переміщення, не взлетіло, він трохи порозбиралися, далі було шкода витрачати час, за 15 хвилин він переписав на вказівники.

іншими словами «рут коз» невідомий, й то могло бути що завгодно...
й «звалити все» на С++ — не зовсім вірно (умовний Сшний qsort теж міг би не видати бажаного)

я не бачу жодної проблеми у тому, щоб розробники Rust копіпастили код

як я розумію, там якраз проблема не в копіпасті, а вони хотіли бачити свою відносно стабільну коммон АПІ... (та й звісно, припахати того, хто змінює відповідний код ядра було б класно, а самому щоразу проходити «квест» то «нецікаво»)...

Якби Rust вмів якось «заімпортити» автоматом сигнатурки та структурки (отак, як С++ «сам одразу бачить»), це було б набагато веселіше, а правити код Rust вслід за Сшними файлами — нікому не цікаво...

PS. А заімпортити сигнатурки автоматом, то є фантастика та мрії, бо через макроси, дефайни і тд воно «стає остаточно видиме як має бути» лише gcc-шному компілятору, коли він, власне й працює над тими рядками з оголошенням сигнатурок при білді ядра... це, насправді, «ставить хрест» та «накриває мідним тазом» зручну інтеграцію з будь чим «чимось іншим», якщо то тільки не та сама Сшка (або «забанений» С++)

іншими словами «рут коз» невідомий, й то могло бути що завгодно...
й «звалити все» на С++ — не зовсім вірно (умовний Сшний qsort теж міг би не видати бажаного)

Якщо усе відразу запрацювало, як замінити vector<T> на vector<T*>, то... напевно проблема у конструкторі копіювання. Так, помилитися можна де завгодно, але це ілюстрація, що конструктор копіювання не дуже й інтуїтивно зрозумілий, там просто помилитися, а шукати де помилка може бути гарним квестом.

Якби Rust вмів якось «заімпортити» автоматом сигнатурки та структурки (отак, як С++ «сам одразу бачить»), це було б набагато веселіше, а правити код Rust вслід за Сшними файлами — нікому не цікаво...

Ну... є h2pas який це переводить хідер в модуль на паскалі. Щось таке, напевно, використовувалося у Delphi для перекладу хідерів WinAPI. В принципі, задачу можна вирішити, поставив обгортку над cpp.

Але так, це подарункові граблі.

Якщо усе відразу запрацювало, як замінити vector на vector, то... напевно проблема у конструкторі копіювання. Так, помилитися можна де завгодно, але це ілюстрація, що конструктор копіювання не дуже й інтуїтивно зрозумілий, там просто помилитися, а шукати де помилка може бути гарним квестом.

ем, все одно «тут щось нете»... а «намутити» з копіюваннями можна й в няшній Сшці... якщо копійований об’єкт передбачає якісь «правила», а його копіюють бездумно неуважно... BTW: С++ хоча б дозволяє забанити копіювання, а Сшці воно копіюється усім контентом, а потім якась АПІшка «звільнить» скопійоване поле, яке міг звільняти тільки оригінальний овнер (або навпаки оригінальний овнер більше не овнер), й потім ми вже звільнимо в «правильному місці» поле, якого не існує, і та адреса взагалі належить іншому об’єкту (і спробуйте тепер то віддебагати на ебеддед девайсі)

Навіть без ніякого копіювання все оте «ООП на Сшці», й ті «прості речі» з тими всіма «премудростями» то клінічний мазохізм, грубо кажучи (імена «трохи змінені» щоб не палити кантору не порушувати NDA):
struct MyClass instance;
MyClass_init(&instance);
...
MyClass_якатоОперація(&instance);
...
Object_delete(&instance);

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

В конкретному випадку вище бага: валідні пари або MyClass_init/MyClass_dispose або ж MyClass_new/Object_delete,
але тільки не вперемішку та хто ж це відслідкує?
При тому вже всі чудово знають і пам’ятають про валідні пари, знають правила як складати VMT, бо Object_delete то макро, що робить приблизно таке ((Object*)my)->vmt->dispose((Object*)my), а тоді tx_block_release й ви повинні не забути прописати MyClass_dispose в вмтшці (а ще MyClass_dispose повинен викликати ЙогоБазовийКлас_dispose, ага)

А тепер додайте туди MyClass_clone та MyClass_cloneTo, що робить «глибоку» копію (не забудьте MyClass_clone ще викликає СвійБазовийКлас_cloneTo, ще якщо MyClass_clone то потім треба Object_delete, але якщо MyClass_cloneTo то треба MyClass_dispose над тою пам’яттю куди заклонував) + одночасно всі звичайні memcpy, що присутнє, бо автори бавляться в «активні об’єкти» й ті «класи» вони таким способом «подорожують» між тими «активними об’єктами» і вважається що черга «забрала» об’єкт, тому тепер в «нашому» AO його вже не можна «діспоузити» або «делітати» (його вже повинен заделітити «той» АО), але якщо «наш» об’єкт перед «відправкою в чергу» був створений через MyClass_new, то треба не забути звільнити пам’ять, зарелізити блок самому ручками через tx_block_release вже без виклику MyClass_dispose (бо тепер його повинні викликати «там»... коротше Rust би чудово розрулив ту всю «катавасію»)

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

Й в кодстані від замовника в перемішку з правилами розстановочки пробільчиків та фігурних дужечок, правил для відступів, заголовків файлів та функцій, іменування і тд, ото все прописано «езопівською мовою» припускаючи що людина вже знає ООП й «сама здогадається» який з «конструкторів» базового треба викликати з «конструктора» похідного...

А ще помножте на то, що «премудрий та модний» qp фреймворк також має свої власні уявлення про ООП, а ще, що в результаті комбінації двох світів там тайп каст на тайп касті й тайп кастом поганяє... І в кращому випадку, якщо натупити, воно падає одразу, а в гіршому «живе» роками, поки не вилізе в якомусь важко репродюсаємому сценарії або на новій платформі... тому що ніякі Юніт та Інетраційні кейси того не передбачили, навіть попри те що «все зелененьке» покрито в кожній гілці згідно показів пропрієтарної кавередж г@внотули)

І варіанцій такого «г@вноООП» на Сшці вагон, в деяких замість vmt поінтери на функції прямо в структурках, деякі юзають -fplan9-extensions, деякі алокують тільки динамічно (і не з блокпулів, а з байтпулів чи й простим malloc)...
деякі юзають макроси для створення таких «класів», деякі інлайни, деякі вперемішку, хтось викликає методи напряму з VMT хтось добуває VMT макросом, а в когось доквола кожного «віртуального» метода є обгортка, щоб не писати obj->base->base->base->vmt->метод((Object*)obj), а одразу Клас_метод(obj)...
і так далі...
і хочеться запитати «люди, ви *б@нулися?»

Зато тепер нема ненависного С++, і взагалі все дуже «по ембедному», актор модел, все лок фрі, відповідає якимтотам стандартам, «цикломатік комплексіті не перевищує» та решта «відповідностей»...

В деяких «методи» декларуються як
MyClass_якатоОперація(struct MyClass* my, ...);
а в деяких
MyClass_якатоОперація(void* my, ...);
з кастом всередині (тому таким АПІшками можна взагалі передати будь-який поінтер і компілятор ніразу не матюкнеться)...
деяке «г@вноООП» схоже на «пародію на С++» а інше зовсім не схоже, але все одно «г@вно»...

А «в ідеальному світі» можна було б загорнути неподобство в тайпсейф класи, юзати блокпули через темплейт (щоб він одразу видавав пойнтер на потрібний тип «тайпсейф способом» і одразу статично асертив, чи заалокований сайз відповідає сайзу блока в пулі), і не засмічувати файли самописними VMTшками й тими всіма танцями з бубном)...
не юзати нестандартний та непортадельний -fplan9-extensions (його часто юзають, щоб не писати me->base->base->base->якетоПоле або не робити ((ОдразуТойБейсЩоТреба*)me)->якетоПоле і варіації довкола того, типу проміжного локального понтіра)

Коротше можна було б писати на C++ в стилі Ардуінки на «адвансед С з класами і темплейтами» (чим, по суті, і є С++ якщо не юзати ексепшени, RTTI і не зловживати контейнерами з динамічною алокацією)
й всі «фішки» про лок фрі, актор модел і тд чудово збереглися б!

Але, звісно, «няшна Сшка» має визначну перевагу, дивіться скільки ,бойлерплейт коду вище ми написали для «елементарних речей», скільки людиногодин можна на те зарепортити... то що треба!
А потім ще зарепортити довгі тижні на пошук і репродюс таємничих багів...

Ну... є h2pas який це переводить хідер в модуль на паскалі. Щось таке, напевно, використовувалося у Delphi для перекладу хідерів WinAPI. В принципі, задачу можна вирішити, поставив обгортку над cpp.

Але так, це подарункові граблі.

Звичайно, і щоб парсити Сшку, так щоб порозкривати всі дефайни та тайпдефи з щоб воно залежно від дефайнів порозкривало всі #ifdef та повключало правильні хедери з тих include directories «що треба», то треба щоб той h2pas отримав все готовеньке середовище вже запрепроцешений з тими ж опціями що й ядро файл, і серед того сміття, що натягнулося також і з усіх хедерів міг витягти саме ті АПІшки та структури, які нам треба поюзати в нашому коді... тільки ж біда чорна: що деякі АПІшки, то ніразу не АПІшки, а таки макроси, з них не візьмеш сигнатуру, бо в препроцешеному файлі того взагалі не існує...

Дуже великий лонгрід, ...

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

Якщо брати сішку, то будуть сортувати завжди масив вказівників. Там з копіюванням намутити складно. А щоб копіювали складні структури з вказівниками — такого не бачив.

Просто мова програмування С++ подібна Героїну: поначалу прикольно, потім не знаєш як з цього злізти. Тому ніби-то з конструктором переміщення ти отримаєш більш правильний та лаконічний код, але якщо щось не запрацює, то треба буде добре потрахатися.

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

   procedure Initialize (Obj : in out Some_Controlled_Type);
   procedure Adjust (Obj : in out Some_Controlled_Type);
   procedure Finalize (Obj : in out Some_Controlled_Type);

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

Коротше можна було б писати на C++ в стилі Ардуінки на «адвансед С з класами і темплейтами» (чим, по суті, і є С++ якщо не юзати ексепшени, RTTI і не зловживати контейнерами з динамічною алокацією)
й всі «фішки» про лок фрі, актор модел і тд чудово збереглися б!

Можна, але коли щось дозволено, то хтось це використає. Знову ж таки, якщо нам треба «адвансед С з класами і темплейтами», то це усе вже є в Ada, плюс контракти, плюс верифікація на базі трійок Хоара.

Дуже великий лонгрід, ...

вечір п’ятниці))

Просто мова програмування С++ подібна Героїну: поначалу прикольно, потім не знаєш як з цього злізти. Тому ніби-то з конструктором переміщення ти отримаєш більш правильний та лаконічний код, але якщо щось не запрацює, то треба буде добре потрахатися.

та ну... то якесь упередження, та ще й базовано на якомусь прикладі з невідомим руткозом... щоб ефективно заблеймити С++ слід було б спочатку провести подвійні сліпі, рандомізовані, плацебо контрольовані дослідження знайти руткоз, а він міг бути зовсім не в С++ (звичайно, можна сказати, що «забрали представлення неправильно» і «то все через те, що С++ є така можливість», але, все ж, memcpy та відправку класів з поінтерами через черги люди мутять... і гуішки навіть пишуть, з ієрархіями вкладених «контролок», й до гуішки присилають структуровані дані через месідж в гуішний срід і тд... а хто є овнером тих поінтерів? а чорт його знає, часом цього не знають навіть самі автори))

procedure Initialize (Obj : in out Some_Controlled_Type);
procedure Adjust (Obj : in out Some_Controlled_Type);
procedure Finalize (Obj : in out Some_Controlled_Type);

і мова перевіряє щоб викликати Finalize не забули? Чи викликає сама?
а як то все лягає на наслідування? (втім ADA то окремий «всесвіт» з своїми «примочками»... про GNAT я чув й сумні відгуки, тому ніц не скажу)

Можна, але коли щось дозволено, то хтось це використає.

ексепшени та RTTI забанити доволі легко опціями компілятора, а використання стандартних контейнерів можна знайти grep-ом))
Втім треба йти далі, щоб сам компілятор «бив по руках», тому Rust рано чи пізно переможе (так, я розумію, що існують альтернативні підходи, але вони доволі екзотичні та «занадто наукові»:))

плюс верифікація на базі трійок Хоара.

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

Ну й, звісно, «кому що болить»... я, попри певну «посвяченість», все ж, людина далека від науки та її теоретичних проблем... А от ловити всякі меморі ліки, меморі оверрани, юз афте фрі та решту приколів (і це ще добре, якщо ще є дата брейкпоінти, й знаєш де їх поставити!) — то все є нецікава і нетворча робота (це конкретно для мене, хтось може й любить «розгадувати таємниці», а конкретно я це завжди проклинаю, особливо якщо платформа не сапортить дата брейкпонтів)...

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

Дійсно «в ідеальному світі» строго математично це все мав би доводити компілятор, та наразі бачу, що конкретно Ada так і не отримала «достатньо реклами», щоб народні маси великі корпорації були так само імпрессед як Rustом)) Хоча знаю, що свого часу вони заімпресили МО в США...

PS. До речі, я вже не раз зустрічав С++ні класи, що трекають, наприклад, розмірності фізичних величин (щоб не додавали метри до кілограмів) та навіть діапазони значень (зараз сходу гуглиться тільки bounded::integer, але були ще), але, втім, сам на практиці ніколи того не юзав по причині «приземленості» вирішуваних задач (на всіх проектах, якщо й є якісь справжні «наукові формули», то вони, як правило, завжди готові від замовника, й відповідальність за їхню правильність теж виключно на ньому))

і мова перевіряє щоб викликати Finalize не забули? Чи викликає сама?

Усі три методи мова викликає автоматично.

а як то все лягає на наслідування?

Там звичайний record extension, які там можуть бути проблеми? Тому виглядає так:

procedure Adjust_Inheritance is
   type Base is new Controlled with record
      Data : String := "Base Data";
   end record;

   overriding procedure Adjust(B : in out Base) is
   begin
      Put_Line("Adjust for Base: " & B.Data);
   end Adjust;

   type Derived is new Base with record
      Extra : String := "Derived Extra";
   end record;

   overriding procedure Adjust(D : in out Derived) is
   begin
      Adjust(Base(D)); -- Виклик базового класу
      Put_Line("Adjust for Derived: " & D.Extra);
   end Adjust;
якщо воно вміє то в компайлтаймі з коробки, то дуже круто, але не маю лінків на готові приклади

Наприклад, VerifyThis Challenge in SPARK — приклад повністю верифікованого методу сортування. Там декілька рівнів, від «відсутність run-time помилок» до «збереження ключових властивостей» та наприкинці «повний доказ функціональних вимог». Верифікація вітсутня в Rust взагалі.

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

Проблема не в перевірці, проблема у тому, що робити. От у тебе гелікоптер на Марсі в польоті, і у тебе спрацьовує runtime перевірка вихід індексу за межі.

PS. До речі, я вже не раз зустрічав С++ні класи, що трекають, наприклад, розмірності фізичних величин (щоб не додавали метри до кілограмів) та навіть діапазони значень

Зробити перевірку runtime взагалі не питання. Але навіть на рівні мови контракти (Eifell, Ada) дозволяють це робити виразніше:

type Account is tagged private
   with Type_Invariant => Account.Balance >= 0;
      
procedure Deposit(A : in out Account; Amount : Integer)
   with Pre  => Amount > 0,
        Post => A.Balance >= Amount;

procedure Withdraw(A : in out Account; Amount : Integer)
   with Pre  => Amount > 0 and Amount <= A.Balance,
        Post => A.Balance = A.Balance'Old - Amount;

function Get_Balance(A : Account) return Integer;
Наприклад, VerifyThis Challenge in SPARK — приклад повністю верифікованого методу сортування. Там декілька рівнів, від «відсутність run-time помилок» до «збереження ключових властивостей» та наприкинці «повний доказ функціональних вимог

Круть, дякую за наводку, втім зазначу що топік потребує більш детального вивчення, отож «прямо вже» відгук не запровайджу...

Єдина дивна річ: чому ж така кльова фішка «не злетіла» в широких масах?...

Верифікація вітсутня в Rust взагалі.

Втім, як й в «няшній Сшці», я ж кажу то трохи інший підхід...
(й С++ове GSL то «нете», а мрії про expects, ensures, assert плачуть кривавими сльозами...)

Але в «няшній Сшці» треба ловити меморі оверрани «от вже»... І я б дуже хотів «чарівну паличку» що «працює негайно», щоб «заткнути» потік «меморі рілейтед» багів...

Проблема не в перевірці, проблема у тому, що робити. От у тебе гелікоптер на Марсі в польоті, і у тебе спрацьовує runtime перевірка вихід індексу за межі

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

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

Зробити перевірку runtime взагалі не питання. Але навіть на рівні мови контракти (Eifell, Ada) дозволяють це робити виразніше

Нє, нє, мова не про рантайм, а саме про компайлтайм трекання юнітів по параметрах шаблона в статиці, і якщо ми «метри в секунду» поділимо на «секунди», то воно «допре само» що це «метри в секунді за секунду» або «метри * (секунду^(-2))» й це автоматом закодовується в параметрах шаблону... типу ось такого й подібного (всякі «units» ліби, що (аб’)юзять шаблони, аби разом з типом в статиці тягнути компайл тайм інфу), той самий подібний підхід й до діапазонів тобто все перевіряється абсолютно статично в компайлтаймі, й якщо ми «протягли» всі обчислення через такий bounded::integer то ми точно знаємо діапазон на виході в статиці й воно не впливає на рантайм ну зовсім ніяк...

(тому й якось дивно бачити що Ada зовсім не на перших місцях за продуктивністю)

Єдина дивна річ: чому ж така кльова фішка «не злетіла» в широких масах?...

Складно. В принципі є Verifiable C, але треба розуміти, що у більшості розробників не дуже добре з математикою.

Але в «няшній Сшці» треба ловити меморі оверрани «от вже»...

Я бачив таке: listener.c

_IRQL_requires_max_(PASSIVE_LEVEL)
QUIC_STATUS
QUIC_API
MsQuicListenerStart(
    _In_ _Pre_defensive_ HQUIC Handle,
    _In_reads_(AlpnBufferCount) _Pre_defensive_
        const QUIC_BUFFER* const AlpnBuffers,
    _In_range_(>, 0) uint32_t AlpnBufferCount,
    _In_opt_ const QUIC_ADDR* LocalAddress
    )
{
тобто якась зовнішня система верифікації
(тому й якось дивно бачити що Ada зовсім не на перших місцях за продуктивністю)

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

Складно. В принципі є Verifiable C, але треба розуміти, що у більшості розробників не дуже добре з математикою.

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

Ці тули довкола Сшки, це ж, походу, треба починати з vst.cs.princeton.edu ... і далі їхня отака книжка а ще й оце

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

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

І ще, книжка пише

Verifiable C is a program logic (higher-order impredicative concurrent
separation logic) for C programs with these restrictions:
• No casting between integers and pointers.
• No goto statements.
• No bitfields in structs.
• No struct-copying assignments, struct parameters, or struct returns.
• Only structured switch statements (no Duff’s device).
• No varargs functions, except limited undocumented support for
calling printf and fprintf.

Та то вже зовсім печалька... Звичайно, я розумію, чому «No struct-copying assignments, struct parameters, or struct returns» (воно ж осуттєво спрощує аналіз), але, все ж, в плані трекання переміщень/клонувань структурок з поінтерами, то таке до могутності Rust далеко не дотягує...

Я бачив таке: listener.c

то є SAL, по ідеї й умовний Cppcheck мав би вміти щось подібне...

Ідея Ada перш за все надійність.

та якби реалізувати всі перевірки в статиці, то не мало б тормозити, але погоджуся, що, можливо автори тестів не дооптимізували...

Якщо тобі треба щось продуктивне, то ніхто не заважає написати на Сі, та викликати.

Але ж Ada не бачить Cшних хедерів напряму (так само, як й Rust) — сумулька...

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

Верифікація справа складна. Можливо в майбутньому знайдуть можливість спростити це. Так, є різні підходи, type dependent programming languages, це формальна математика це частина мови (Agda, Idris). Є трійки Хоара для імперативного програмування з інваріантами (Ada). Є використання зовнішніх пруф-чекерів (Verificable C, також я зустрічав і щось на Rust, ChatGPT допоміг: dialog, ніби-то усі проекти робочі.

Але навіть Rust я би не сказав, що це супер-проста мова: є проблеми оволодіти. Опір з боку мейнтейнера цьому свідчення.

Та то вже зовсім печалька...

Думаю, з часом допилять.

Але ж Ada не бачить Cшних хедерів напряму (так само, як й Rust) — сумулька...
g++ -c -fdump-ada-spec -C /usr/include/time.h
також я зустрічав і щось на Rust, ChatGPT допоміг: dialog, ніби-то усі проекти робочі

Тим більше на додачу до існуючих «з коробки» плюшок, навіть інтеграція з vscode (хоча й з «лєвими» депенденсями) або ж інтеграція з гітхабом... таки «мода» та «хайп» мають ефект))
(інше питання, чи довго то триватиме?)

Але навіть Rust я би не сказав, що це супер-проста мова: є проблеми оволодіти. Опір з боку мейнтейнера цьому свідчення.

тому проблеми одноразового оволодіння Rust «за один раз» ми обміняли на проблеми вічного шукання меморі рілейтед багів, кожен з яких має свій унікальний руткоз

g++ -c -fdump-ada-spec -C /usr/include/time.h

круть, але все ж «However, this option does not expose or include preprocessor macros in the generated Ada specification files. The primary purpose of this option is to create Ada bindings for C or C++ code, focusing on types, functions, and constants, but not on macros»...
втім, може і до Rust буде така опція... gccrs вже є ))

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

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

У мене більше проблем з логікою, але то таке.

круть, але все ж "However, this option does not expose or include preprocessor macros in the generated Ada specification files.

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

У мене більше проблем з логікою, але то таке.

То отже, більш цікава й творча робота, ніж шукати чужі меморі ліки в чужому коді))

А якщо їх треба білдити, то можна й згенерувати паралельно біндінги для твоєї мови.

Тому, насправді, канонічний, класичний dkms плаче...
Треба визнати, це «камінь в город» будь-якої «додаткової» мови, що на ній дрова треба білдити разом з ядром...
Це ж потім на кожній машині окрім звичайного Сшного барахла й Сшних хедерів ядра прийдеться притарабанити ще й кожну мову, на який писаний драйвер разом з усім її барахлом та інфраструктурою типу менеджерів пакетів...

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

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

С таки «франка лінгуа», не Басік же чи Фортран? Чи що?

У цілому усе ядро побудовано на двозв’язних циклічних списках, які просто неможливо реалізувати на Rust без unsafe.

А що не так з ансейф? Сішка вся ансейф, і нічого

Тоді незрозуміло, які переваги дає Rust.

Не усі вміють писати на С

Ніхто не вміє писати на С, це просто неможливо. Є просто ЧСВшні які кажуть, що вони вміють писати на С, але потім ти ідеш читати розсилку дирок в софті, і все стає на свої місця.

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

И раз в неделю принудительный ребут всех серверов из-за очередного супер важного kernel update, на который нет никаких release notes.

Це брехня. До кожного релізу ядра йдуть Release notes. Якщо якийсь вендор не включає список змін до оновлення в рамках одного релізу — це проблеми вендора, а не кернела.

І зовсім не потрібно перезагружати сервер при кожному оновленні ядра, системам рантайм-патчінгу ядра — 100 років або десь так. kpatch, kGraft, Ksplice, livepatch тощо.

І купа дистрибутивів, які підтримують оновлення ядра без перезавантаження і взагалі без зупинки роботи.

Red Hat Enterprise Linux, SUSE Linux Enterprise, Oracle Linux, Ubuntu, KernelCare, Amazon Linux, тощо.

Якщо якийсь дивак використовує десктоп-дистр Лінуксу для серверу — це тільки його сексуально-статтеві проблеми.

Це брехня. До кожного релізу ядра йдуть Release notes.

Большинство серьезных контор собирают свое ядро из своих форков. Отсутствие release notes — потому что контора получает инфу об уязвимости ядра по своим каналам до того, как она попадает в паблик, и по понятным причинам в release notes все это не указывается.

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

По факту Linux, git, CPython, ... працюють досить стабільно. А от що там Redox OS? Наразі немає відомих великих компаній чи проєктів, які використовують Redox OS у промислових продуктах або критично важливих системах. Якби вона хоч якось набула відомості, тоді може й теж почали б знаходити дірки.

Зазвичай такі питання мають підвох. Типу отримати список переваг, а потім сказати щось типу «у сі перформанс все-одно вищий, тому усі інші переваги — не переваги». Або «все одно доведеться юзати ансейф, тому раст такий самий в плані безпеки, як і сі (ні), тому нафіг його, далі юзаємо сі».

В цілому, Раст
— сучасна мова, з нормальним цілісним синтаксисом
— ПОТУЖНОЮ потужною системою типів
— нормальними макросами і кодогенерацією
— з зеро-кост високорівневими абстракціями (типу ітераторів тощо)
— з певними гарантіями безпеки памʼяті (так, навіть незважаючи на те, що не можна без ансейф написати двозвʼязний список)

Ансейф доведеться юзати у будь-якому випадку, у будь-якому більш-менш складному проекті. Але профіт у тому, що ансейф коду буде, наприклад 5%, і проконтролювати його значно простіше. Тим більше, що певні гарантії є і в ансейф.

через те що потрібно використовувати системне api, яке під капотом працює на C, правильно?

Взаємодія з С буде ансейф, так.

Але є випадки, наприклад, ті самі двозвʼязні списки, які без ансейф важко реалізувати нормально саме із-за особливостей дизайну мови. В Rust може бути лише одне посилання (у кожен момент часу), через яке можна змінювати значення. У випадку двозвʼязних списків нам треба мати два таких посилання (у попередньому і у наступному вузлі), тому ми через ансейф це обходимо (зберігаємо вказівники, і потім кастуємо до mutable reference).

Але у випадку списків це можна зробити один раз у структурі DoubleLinkedList, і далі усюди код, який використовує цю структуру, буде safe

Нам ще треба отримати батьківську структуру. Тобто треба

#define container_of(ptr, type, member) ({                      \
        const typeof( ((type *)0)->member ) *__mptr = (ptr);    \
        (type *)((char *)__mptr - offsetof(type,member));})

або

macro_rules! offset_of {
    ($type:ty, $field:ident) => {{
        let tmp = core::mem::MaybeUninit::<$type>::uninit();
        let base_ptr = tmp.as_ptr();
        unsafe { ptr::addr_of!((*base_ptr).$field) as usize - base_ptr as usize }
    }};
}

pub unsafe fn container_of<T, U>(ptr: *const U, field_offset: usize) -> *T {
    (ptr as *const u8).sub(field_offset) as *T
}

let parent_ptr = unsafe { container_of::<MyStruct, ListNode>(node_ptr, offset) };

А далі... виникає ситуація, що більшість вказівників у нас mutable, бо отримані з двозв’язних списків, але без гарантій.

Насправді «няшно С-шний» варіант не менш жахливий, «statement exprs» то нестандартне розшинення (та й typeof з’явився лише в С23, а до того був лише розширенням деяких компіляторів)...

Тобто якби Лінукс написаний... «не на Сшці»
(втім, я погоджуся, що решення Лінуса про -fno-strict-aliasing вірне, щоб не аплаїти «модну Сшну фішку»))

А далі... виникає ситуація

Ем... а вона виникає і в Сшці, бо для «непосвячених» якщо не знаєш як правильно бавитися в оті всі «прийняті» RCUшні штуки, щоб похендлити коли той доступ можна робити, коли ні, і чи за той час, поки ми доступалися, той список не змінився/не покоцався...

І якщо не виконувати всі RCUшні «танці з бубном» правильно, то Сшний компілятор «не дасть по руках», й про то як і де «натупив» можна буде взнати лише пізніше (або й не взнати)...

Rust якби зробив спробу описати неявні штуки менеджмента доступу явно, але чи досить існуючого інструментарія, щоб якось «загорнути» RCUшний шаманізм так, щоб він ліг природньо на Rust-івські овнершипи та лайфтайми — я наразі собі не уявляю...

ті самі двозвʼязні списки, які без ансейф важко реалізувати нормально саме із-за особливостей дизайну мови

Связный список без ансейф реализовать очень просто:

struct Node<T> {
    previous: RefCell<Option<Rc<Node<T>>>>,
    next: RefCell<Option<Rc<Node<T>>>>,
}

* RefCell — обертка, которая позволяет обойти ограничение Rust compile time borrow checker, заменив его на runtime borrow checker (фактически RWLock)
* Option — обертка, которая позволяет иметь фактически Null значение
* Rc — счетчик ссылок

На всякий случай, это не потокобезопасный связный ссылок (и компилятор не позволит использовать его в многопоточной среде, где могут нарушиться гарантии безопасности многопоточности, которые дает компилятор), потокобезопасный вариант делается через

RwLock<Option<Arc<Node<T>>>>

Дело в том, что часто хотят не safe связный список, а unsafe связный список, а именно:

Не хотят счетчик ссылок и не хотят rwlock, это значит что компилятор не может проверить, не нарушаются ли правила pointer/reference aliasing, и не предотвращает null pointer dereference, use-asfter-free, double-free и memory lea (которые предотвращаются в безопасном варианте выше).

По правилам Rust такая реализация связного списка должны иметь unsafe интерфейс, в этом весь поинт.

От того, что часть кода будет работать с небезопасным связным списком, остальная часть кода не перестает работать, она может оставаться на safe rust, и на нее будет распространяться большая часть гарантий безопасности, предоставляемая компилятором.

struct Node {
previous: RefCell>>>,
next: RefCell>>>,
}

А навіщо T? Чому список не може мати елементи різних типів?

Я забыл про само значение, которое хранится в узле списка, должно быть так:

struct Node<T> {
    previous: RefCell<Option<Rc<Node<T>>>>,
    next: RefCell<Option<Rc<Node<T>>>>,
    value: T
}
А навіщо T? Чому список не може мати елементи різних типів?

Это generic структура. Когда ты ее используешь, ты указываешь какой именно тип данных в ней будет храниться.

Як раз це зайве, бо це не сішний стиль: рутовому елементу не треба взагалі даних типу T, по-друге, страшно уявити що буде, якще елемент T буде у п’яти різних списках.

Node<Node<Node<Node<T>>>>

через те що потрібно використовувати системне api, яке під капотом працює на C, правильно?

Для системного API можно написать полностью безопасную обертку на Rust.

Простой пример — doc.rust-lang.org/std/fs/index.html — полностью безопасная Rust обертка над «небезопасной» libc или небезопасным Win32API. По вышеупомянутой логике можно было сказать, что раз под капотом используется небезопасная C библиотека, то нет никакого смысла писать приложения на Rust, но на практике смысл огромный и куча приложений пишется на Rust.

Или, например, безопасный смарт поинтер doc.rust-lang.org/...​std/boxed/struct.Box.html, который является оберткой над небезопасным malloc. Точно такую же обертку можно сделать поверх небезопасного kmalloc, и тот факт, что где-то рядом используется небезопасные связаные списке не отменит того факта, что у нас так же есть безопасный смарт поинтер в память ядра.

В цілому, Раст
— сучасна мова, з нормальним цілісним синтаксисом
— ПОТУЖНОЮ потужною системою типів
— нормальними макросами і кодогенерацією
— з зеро-кост високорівневими абстракціями (типу ітераторів тощо)
— з певними гарантіями безпеки памʼяті (так, навіть незважаючи на те, що не можна без ансейф написати двозвʼязний список)

Це все так, але питання полягає у тому, наскільки ефективно можна змішувати Сі-код та Rust. Система типів потужна, але виникає питання, як ADT значення вичитувати з Сі при потребі? Ітератори... Ну це контейнерно-орієнтоване програмування на кшталт STL в C++. Але це зовсім не сішний стиль, це зазвичай двозв’язні цикличні списки (з цим проблеми), циклічні буфера та хіпи. Тому zero-cost дуже умовно. Гарантії безпеки пам’яті більше орієнтовані на userspace. Якщо ми беремо ядро, то треба розуміти, що та ж сама пам’ять це можуть бути сторінки, які мають завжди присутніми в фізичної пам’яті, сторінки, які можуть вигружатися, ... І вся ця система аннотацій &'a теж може бути проблемою.

Тому... на Rust можна написати операційну систему повністю. Але інтегрувати з Сі... При тому, що Linux моноліт... Поглибити фундамент існуючуї багатоповерхівки на 20 метрів... Переписати усе на Rust набагато простіше, як на мене.

Якщо ми беремо ядро, то треба розуміти, що та ж сама пам’ять це можуть бути сторінки, які мають завжди присутніми в фізичної пам’яті, сторінки, які можуть вигружатися,

Это распространенный аргумент, но можно так же упомянуть, что, например, большинство out-of-bounds memory access CVE в линуксе — это не потому что где-то выгрузилась страница, а потому что кто-то решил считать/записать что-то в буфер, не проверив размер буфера — проблема, которая отсутствует как класс при использовании Rust slice &[T], который будет работать даже в среде, где страницы могут выгружаться.

Тому... на Rust можна написати операційну систему повністю. Але інтегрувати з Сі...

Я писал драйверы на Rust (правда не под линукс, а под embedded среду без ОС), и не могу понять логику этого аргумента.

«небезопасная» часть драйвера — это часть, которая что-то читает и пишет в memory mapped registers, потому что это делается по сути небезопасными поинтерами. Это маленькая часть драйвера, и область памяти, с которой приходится работать в небезопасном режиме, очень ограничена — может быть пару десятков регистров.

При этом есть еще огромная часть драйвера, которая не имеет ничего фундаментально «небезопасного» — код, который реализует последовательность инициализации и конфигурирования устройства — обычно код, который просто читает/пишет в эти регистры кучу констант из даташита, преобразуя команды, которые получены из безопасного API от юзера (например flash_driver.write_at(offset, buffer)) в последовательность чтений/записи в регистры, и т.п.

Т.е. в теории код драйвера все еще имеет «unsafe», но на практике, любой разумный человек может понять, что от того, что код «трогает» несколько регистров через raw pointer, в нем ничего не ломается, и большинство (если не все) гарантии, которые дает компилятор Rust остаются в силе.

Может быть аргумент, что, например, менеджер памяти ядра, который собственно мапит страницы, получит мало преимуществ от переписывания на Rust, потому что он реально может себя «отмапить».

Но для контекста: самый большой спрос на Rust идет от тех, кто хочет переписать менеджер памяти, а именно от разработчиков драйверов, и даже злополучный diff, из-за которого разгорелся срач — это добавление Rust обертки для DMA подсистемы, которая, сюрприз, требуется для многих драйверов.

Это распространенный аргумент, но можно так же упомянуть, что, например, большинство out-of-bounds memory access CVE в линуксе — это не потому что где-то выгрузилась страница, а потому что кто-то решил считать/записать что-то в буфер, не проверив размер буфера — проблема, которая отсутствует как класс при использовании Rust slice &[T], который будет работать даже в среде, где страницы могут выгружаться.

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

Я писал драйверы на Rust (правда не под линукс, а под embedded среду без ОС), и не могу понять логику этого аргумента.

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

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

На практике они всего лишь происходит постоянно и ведут к критическим проблемам безопасности.

Открой список Linux Kernel CVE и посмотри сколько насчитаешь out-of-bounds memory access, buffer overrun на первой странице.

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

#[repr(C)]

Мавши період фуллтайм фіксання ядерних CVE, нечасто проблема була чисто в небезпечності коду. Зазвичай ще додавались умови типу крашу чи дисконекту пристрою на шині, нестачі системних ресурсів чи ще якихось позакодових факторів, вже на яких небезпечним чином ламався сішний код.

На практике они всего лишь происходит постоянно и ведут к критическим проблемам безопасности.

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

#[repr©]

Якби знати прикуп... На практиці у тебе вже є

struct Node<T> {
    previous: RefCell<Option<Rc<Node<T>>>>,
    next: RefCell<Option<Rc<Node<T>>>>,
    value: T
}

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

Тут такое дело, если ты не видел Rust и не видел ядро линукса или хотя бы не работал на достаточно сложном С проекте, то у тебя нет большого количества контекста, который бы позволил понять проблему и почему/как Rust помогает ее решить или упростить.

Ситуация еще усугубляется тем, что когда людям, которые видел ядро Линукса начинают это объяснять, то все заканчивается очень плохо.

Печально известная презентация дает пример одной функции ядра на С, некоторые особенности и правила ее применения, и как обертка на Раст может ее упростить. Предупреждаю сразу, видео очень кринжовое и смотреть его без стыда сложно, но можно попробовать хотя бы посмотреть два слайда без звука.

Первый таймстамп показывает функцию на С и правила ее использования:

www.youtube.com/...​tch?v=WiPp9YEBV0Q&t=1538s

Второй таймстамп — гипотетическая обертка на Rust для той же функции

youtu.be/WiPp9YEBV0Q?t=557

Для всех нормальных людей первый вариант на C это эталон простоты и лаконичности, свято следующий unix philosophy. Одна функция, которая возаращает один поинтер, что может быть проще? А при виде раст варианта начинается батхерт, потому что много угловых скобочек и вообще .

Но если с терпением копнуть поглубже, то выясняется несколько интересных вещей, а именно:

В C интерфейсе некоторые правила использования результата неявные, они или прописаны в документации, которая не всегда полная, не всегда up-to-date, не всегда вообще присутствует, и не всегда ее с терпением читают. Правила использования этой функции ничем не проверяются, и корректность использования зависит от разрабочтика, который ее использует, и разработчиков, которые делают code review, и даже не всегда нужный человек посмотрит на код, котоырй мерджится.

В варианте на Rust часть правил использования результата функции прописана в типе результата функции, а именно:

1. Функция может вернуть ошибку. Компилятор потребует, чтоб вызывающий код проверил, что лежит в результате — или успешный результат Result::Ok(...) или ошибка Result::Err(...) и не даст возможность считать успешный результат если былв возвращена ошибка.

2. В случае успеха один из вариантов может быть возвращен: или ново созданный элемент, или какой-то смарт поинтер на уже существующий элемент. Опять же здесь компилятор потребует разработчика явно обработать каждый возвращенный случай, и не позволит использовать результат как смарт счетчик ссылок, если был возвращен новосозданный элемент.

То есть даже если человек не читал документацию на функцию, он как минимум не сможет забыть про проверку результата на ошибку и про то, что результат работы функции может быть один из двух разных типов значений. Просто потому что иначе код не скомпилируется.

Как видишь, здесь вообще никакой речи не идет о safe/unsafe, лайфтаймы, и т.п. Просто банально интерпретировать результат работы одной замудреной функции, не выстрелив себе в ногу 3 раза.

И если думаешь, что проблема надумана, просто прими за факт, что большинство С разработчиков не смогут, имея на руках документацию, написать код, который копирует строку с помощью strcpy, не создав при этом уязвимость buffer overrun.

Я розумію переваги ADT, мені не треба пояснювати. Тут трохи інша історія, коли я починав писати user mode код на Rust, то відразу відчував, наскільки він убогий у порівнянні з Haskell, але то інший офтопік. Так, в Rust треба обов’язково перевіряти помилки, unwrap, unwrap, unwrap, ...

В будь якому разі, написати власну операційну систему на Rust — я тільки «за». Я навіть буду одним з перших, хто спробує туди перейти, як пробував Redos OS років п’ять тому. Отримав кучу крешей з пам’яттю, але я тільки «за».

Якби можна було писати на Rust відокремлено, я теж тільки «за». У glibc нам не треба підтримувати Rust, бо ми можемо чітко прописати інтерфейс, та сішному коду взагалі не треба знати хто його там викликає. Якби так працювало з Linux Kernel, то і ніякої підтримки Rust не було потрібно.

Але... писати одночасно і на Rust і на Сі... моноліт... Тут, моє ІМХО, то якщо код почне інтесивно міксуватися, на на цьому місці випливе така кількість складних багів, через які розробники пересваряться, а Rust викинуть взагалі, або буде форк Rusted Linux та Original One. Таке моє передбачення.

Это в теории. На практике проблемы технического характера решаются специалистами, идет прогрес и жестких технических блокеров нет. Основной пушбек идет от старых мейнтейнеров, и аргументация не «вот тут возникает техническая проблема, сложно делать интерфейс между Rust и C, и т.п.», а «уберите свой Rust из ядра, я не хочу ничего видеть, оставьте мне теплую ламповую сишечку, я не знаю как грепать Rust код, хипстерам не место в lwn, раньше было лучше, а вот сейчас....».

Я Rust бачив, а ви ядро Linux бачили?

До чого питання? Я запитував, бо переваги Расту в порівнянні з Сі в загальному випадку очевидні (звісно, це не значить що Раст завжди краще, ніж Сі)

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

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

У ядра ОС в принципі основна робота — це інкапсуляція процесів від заліза і одне одного. Там, де розділення добре формалізується і не має катастрофічних наслідків для перфомансу, там і раст не потрібен, свою нову файлову систему через FUSE, наприклад, можна і на Go писати.

Я в загальному випадку бачу недоліки. Порівняно зі старими стандартами С++ (котрі C with classes) — лише недоліки.

> Ви раст бачили?
>
Хто ж його не бачив, всі дешеві авто в расті ...

На C треба докласти зусиль, щоб написати safe. На Rust треба докласти зусиль, щоб написати unsafe.

На C треба докласти зусиль, щоб написати safe.

на C в принципе невозможно писать с compile time гарантиями безопасности

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

ніц не зрозуміло, доки не прочитаєш оригінал. А коли прочитаєш оригінал, то і тоді не дуже зрозуміло, чому так незрозуміло написано.

А що саме незрозуміло написано, якщо не секрет? Можливо треба десь внести корективи?

Розробник Red Hat Даніло Круммріх пояснив, що ядро на C залишається незмінним, а драйвери на Rust просто використовують
Якщо ви хочете зробити Linux неможливим для підтримки через багатомовну кодову базу, то робіть це у своєму драйвері

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

Де тут протирічча?

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

Дякую за зауваження. Трохи переформолював, сподіваюся так буде краще

Підписатись на коментарі