Vlákno názorů k článku Nové grafiky Matrox LUMA na bázi Intel Arc, sudo a su v Rustu od Calculon - Ten Rust je fakt všude. Tak nevím, co...

Tak je fakt, že Java se do jádra Linuxu jen tak nedostane :)

Maly zeleny robertek se nesmele chichota v koute, jak fikane vsechny pretahl :P

GraalVM Native Image

Java se samozrejme stejne jako kod v libovolnem jinem jazyce (treba i javascript) da prekompilovat do binarni podoby. V tom zadny rozdil neni.

Stejne tak jako aktualni kompilator typicky neprekompiluje 20let stary kod, tak stary kod javy nepobezi na aktualnim jre. V tom taky zadny rozdil neni.

Presne proto se to pouzivat presne tak, jak se to pouziva. Ty jazyky a jejich nastroje nejsou kompatabilni ani samy se sebou. A presne proto se pouziva C/C++ ... protoze tu kompatabilitu udrzuje zdaleka nejlepe.

Uniká ti očividný fakt, že externí knihovna napsaná v Rustu bude pořád používat to samé unsafe C API.

Jak jsi přišel na takový nesmysl? Proč by knihovna v Rustu měla používat C API? Když to bude v Rustu, tak to bude nativní Rust knihovna bez potřeby unsafe. Prosím už se raději k Rustu nevyjadřuj, zjevně nerozumíš úplným základům.

Víš, jak fungují dynamické knihovny? Douč se to, pak se můžeme vrátit k Rustu ;)

Kdo mluvil o dynamické knihovně? Víš o tom, jak funguje cargo a že můžeš externí knihovnu linkovat i staticky? Douč se to a pak se můžeme vrátit k Rustu.

On to bohužel myslí vážně. Až zkusí něco v nějakém projektu refaktorovat do Rustu, poženou ho svinským krokem :)

Vy jste všichni hrozně omezení svým viděním z C světa. Pravda je taková, že dynamické knihovny se v Linuxu hodně používají, ale je to spíš takový relikt minulosti, který se hodí jen pro C kód (není to dobré aní pro C++ ). Důvody jsou následující

1. S dynamickou knihovnou nejde udělat link time optimalizaci ani inlinovat exportované funkce. To má docela zásadní vliv na výkon i velikost kódu (v dynamické knihovně musí být veškerý kód, i ten který nikdo nikdy nezavolá, a který by se normálně při link time optimalizaci vyhodil).
2. Dynamické knihovny musí udržovat stabilní ABI. Jediný jazyk, který má stabilní ABI, je C, protože se už prakticky vůbec nevyvíjí. O stabilní ABI se snaží i C++, ale tam to má svoje problémy. Jednak se jim to úplně nedaří (viz např. změny ve stringu v C++11, kdy zmizel reference counting) a pak jsou taky velké kontroverze ohledně udržování stabilního ABI ve standardní knihovně, což vede k nižšímu výkonu a trucpodniku od Goodle známemu jako Carbor, protože Google a další velcí hráčí potřebují rozbít C++ ABI.

Můžete namítat, že při bezpečnostní chybě v dynamické kníhovně (ta bezpečnostní chyba je typicky v C ne v Rustu :--)), nemusím znovu překládat všechny aplikace, ale stačí vyměnit dynamickou knihovnu. Tento argument přestal být relevantní s nástupem kontainerizace a dockeru, protože se typicky provozuje jedna aplikace v kontajneru a stejně se musí vyměnit celý kontainer.

Mimochodem Rust umí vyrobit i nativní dynamickou knihovnu (viz dylib) s Rust ABI, prakticky to ale nikdo nepoužívá z výše uvedených důvodů, má to spoustu nevýhod.

@linuxák
btw: ty mas pro sudo kontejner? ;-)

sudo nemám v kontajneru, ale jsem naprosto v pohodě s tím, když bude PAM staticky přilinkovaný k sudo. Ty bezpečnostní záplaty, kvůli kterým se typicky dělá upgrade dynamické knihovny, budou totiž s Rustem asi tak 10x méně častné než s C. Bonusy jako LTO a vyšší výkon aplikací jsou tak nějak v ceně.

Problém je v tom, že v něčem tak obrovském jako Linux ty dynamické knihovny používá kdeco, většinou půjde o programy v C (nebo C++, prostě cokoliv závisle na C ABI). Linkovat knihovny přepsané do Rustu staticky znamená nafouknutí všech binárek, co nějakou takovou knihovní používají. Prostě když třeba nějaké CL utility A, B, C používají knihovnu L, je blbost linkovat ji všude staticky a ještě ji mít jako dynamickou pro aplikace D, E, F, které ji taky potřebují a zatím nebyly přepsány do Rustu.

P.S. Možná by pomohlo mít něco jako pluginy v Go, ale to pořád neřeší ten starý kód napsaný v C(++).

1. 5. 2023, 10:28 editováno autorem komentáře

Ano, aktuálně se v Linuxu používají dynamické knihovny napsané v C s C ABI. To ale neznamená, že to tak musí zůstat. Má to totiž spoustu nevýhod:

1. Bezpečnost. V C naprosto tragická. C ABI je unsafe z principu. Spousta programů v Linuxu tak používá unsafe knihovny s potenciálně velkým množstvím bezpečnostních děr.
2. Výkon. Nejde udělat link time optimalizace ani inlinovat exportované funkce.
3. Nutnost udržovat stabilní ABI. Problém pro všechny jazyky kromě C (které se už prakticky nevyvíjí). I v C++ je to velký problém a kontroverní téma a udržování stabilního ABI stojí spoustu úsilí a výkon, protože nejde měnit ABI standardní knihovny.

Statické knihovny netrpí ničím z toho a velikost výsledné binárky nemusí být nějak extra velká, když se použije LTO.

I v Rustu jde vyrobit dynamickou knihovnu s Rust ABI, ale není to úplně dobrý nápad, protože by to znamenalo nutnost udržovat stabilní ABI a kam to vede, nám ukázalo C++.

Swift má taky stabilní ABI a nikdo si nestěžuje.

Swift nedělá monomorfizaci generik, zkompiluje jednu instanci funkce pro všechny typy a řeší se to pak v runtime. Tím se zjednodušuje udržení stabilního ABI, ale stojí to výkon. Rust ani C++ touto cestou nejdou, preferující vyšší výkon a vytváří instanci pro každý typ v compile time. Vždycky je to něco za něco.

Mohli by to dělat jako Go, které v tomto jde zlatou střední cestou.

Tak jest, do dynamických knihoven člověk necpe funkce, které jsou inlinovatelné. Ta režie tam bude minimální.

1. Sice je pravda, ze nejde urobit tree shaking, ale je to uplne bezpredmetne. Pokial je funkcia v binarke na disku, nech si tam je. Do pamate bude nastrankovana len vtedy, ak ju nieco realne pouzije (resp. pouzije nieco v tej istej 4k stranke).

Naproti tomu to, ze dynamicka kniznica je zdielana medzi rozlicnymi procesmi prinasa radovo vyssie uspory v spotrebe pamate.

2. Ano, musia udrziavat stabilne ABI, a pokial s tym ma jazyk problem, je to problem jazyka, nie konceptu ABI. Pokial kniznice priebezne menia ABI/API, tak to vytvara zbytocny churn pre vsetkych.

3. Co tu nebolo spomenute je to, ze dynamicke kniznice sa pouzivaju aj ako pluginy, na rozsirenie funkcnosti. V glibc je to napr. cely nsswitch, pam samotny ma modulov tiez pozehnane. Zalinkovat vsetky do kazdej binarky tiez nie je riesenie, pouzivatel moze doinstalovat dalsie a nakonfigurovat system tak, aby sa pouzivali (vid napriklad sssd).

Tedy mě prosím opravte:
- na počátku to bylo tak jak říkáte, tři aplikace používali jednu dll/so knihovnu, kterážto byla díky tomu v paměti jen jednou.
- následně se začalo šašit s bezpečností, a tak díky bezpečnosti i když tři aplikace pužívají tu samou sdílenou knihovnu, tak každý z nich ji má načtenou znova protože soukromej paměťovej prostor.
- změnilo se od té doby něco?

To už záleží na OS, jak si to ošetří.

Private mmap stale zdiela pamat medzi procesmi; r--p a r-xp vzdy, rw-p zdiela data zo suboru a len zapisy su privatne. Takze zdielana kniznica je stale v pamati len raz.

Díky

"změnilo se od té doby něco?"

Presne takto se to zcela jiste nedela. Naopak, pokud pouzijes virtualizaci, tak se muze sdilet pamet i pres ruzne virtualy. Bydefault se sdili v ramci vm a presne proto funguje overcommit = muzes vyuzivat "vic" ram nez kolik mas.

Medzi VM sa pouziva kernel same page merging; to je brute force, a zlucuje rovnake stranky az potom, ako urobi scan a identifikuje rovnaky obsah v rozlicnych strankach. Mmap funguje naopak, zacina sa s jednou a tie sa mnozia pomocou CoW.

"Vy jste všichni hrozně omezení svým viděním z C světa"

A ty ses zjevne blazen. Zadny dodavatel zadne aplikace nebude denne kompilovat nove verze proto, ze se v nejake z tisicovek knihoven ktere ta aplikace at uz primo nebo neprimo pouziva, objevil nejaky bug.

Nejen ze to nebude kompilovat, on se tim vubec nebude zaobirat, protoze neni v nicich silach ani jen sledovat co kde ma zrovna dneska novou verzi. Natoz resit, ze se opet pomilionpate zmenilo api, a je treba neco nekde prepsat.

Proč hned blázen? Stačí říct nezkušený.

Záleží, co dodáváš.

Binární aplikaci koncovému uživateli? Fajn, tam mají tvoje argumenty asi trochu smysl a může být řešením linkovat to proti dynamickým knihovnám v C, pokud neřešíš bezpečnost. Ale i to je diskutabilní, ty dynamické knihovny v C musíš každou chvíli updatovat, protože bezpečnost C je tragická a stále se objevují nové chyby. Pokud bys linkoval staticky Rust kód, nemusíš updatovat kvůli paměťovým bezpečnostmím chybám, ty tam nebudou. To ušetří spoustu práce a administrativy s updaty. Jako bonus máš navíc vyšší bezpečnost a výkon.

Pokud dodáváš service jako docker kontajner do cloudu pro spustu uživatelů, tak to je úplně jiná písnička, tam je dynamické linkování s C knihovnami přímo kontraproduktivní, nemá to žádné výhody, jen spoustu nevýhod, plus to s sebou nese tragickou bezpečnost C kódu. Použití Rustu se statickým linkováním Rust knihoven je mnohem lepší volba.

Jakej zas kontejner? Bavíme se o CL utilitách v rámci OS.

Ne, nebavíme. Fixovat se na jeden konkrétní problém a nevidět širší souvislosti, je dost juniorní přístup. Časem získáš zkušenosti a větší nadhled.

Přepis z C do C++20 by nedával žádný smysl, pořád by to byl kód s tragickou bezpečností naprosto nesrovnatelnou s Rustem.

Evidentně nevíš nic o C++20. Zapomeň, co víš o C++ z 80. let.

Ehm, C++20 mě živí a troufám si tvrdit, že toho vím docela dost. A nic to nemění na mém tvrzení, že je to jazyk s tragickou bezpečností naprosto nesrovnatelnou s Rustem.

To bych ti i věřil, každý mainstreamový jazyk živí hodně juniorů :)

Na osobní útoky nebudu reagovat, zjevně už ti nic jiného nezbylo. Jen k tomu poznamenám, že mě živí i Rust (ale tady je menší poptávka, C++ je pořád ještě více rozšířené), takže mám srovnání.

Nechutná ti vlastní medicína? :) Hele, já ti to přeju, ať tě živí, co tě baví, to je nejlepší.

To ano, ale přepis do například C++20 by měl podobné výhody.

To by měl i "přepis do C", tj. kdyby ho někdo dneska napsal znovu od nuly a pořádně. Ono je dost nefér porovnávat historický kód, který vznikl v určité době, za určitých okolností a pak se ještě dlouho vyvíjel, s kódem napsaným čistě od nuly. On ten rust driver taky za dvacet let nebude vypadat tak krásně - pokud by se tedy těch dvacet let opravdu používal a udržoval. Ale do propagandy se takové srovnání samozřejmě hodí, jakkoli to o vhodnosti jazyka pro daný účel vypovídá pramálo.

Druhá polovina problému je samozřejmě i to, že jakýkoli nově napsaný driver nevyhnutelně bude míst své nové vlastní chyby. A uživatelé jsou obvykle citlivější na to, když najednou přestane fungovat něco, na co byli zvyklí, že to fungovalo. Nebo i na to, když se něco začne chovat trochu jinak, než byli zvyklí.

To je pravda. Kolega IMHO prostě myslel, že defaultní úroveň (paměťové) bezpečnosti je u Rustu vyšší než u (moderního) C nebo C++. Což je taky v zásadě pravda, ale je otázka, nakolik je tento faktor důležitý vzhledem k jiným, zmíněným výše.

Kolega IMHO prostě myslel, že defaultní úroveň (paměťové) bezpečnosti je u Rustu vyšší než u (moderního) C nebo C++.

V tom právě vidím ten největší problém, v tom dokolečka opakovaném dogmatu, že cokoli napsané v C je automaticky fuj a cokoli napsané v rustu je automaticky super (a super bezpečné). S důsledky téhle zaslepenosti si bohužel asi užijeme ještě spoustu legrace.

Tak ona to není do určité míry pravda? Ta rovnice je IMHO takto:
Abyste v C napsal dobrý program, musíte bejt fakt dobrej.
Abyste v Rustu napsal špatný program, musíte bejt fakt blbej.
To znamená, pro průměrně inteligentního/schop­nýho programátora je C fuj, a Rust supr. Rust není samospásný, ale dává možnosti které C prostě nemá.

To by ale platilo pro každý jazyk s GC. Rust akorát místo toho, aby nabídnul automatickou správu paměti, buzeruje s lifetimama, dokud kód neprojde překladačem.

No a?

Java je bezpečnější jak C.
Rust je bezpečnější jak C.
Python je bezpečnější jak C.
Ledacost je bezpečnější jak C.

Rust navíc zabodoval nízkou cenou výkonu.

Kdo to neumí ocenit, jeho věc. Ať s používá C dále.

Abyste v C napsal dobrý program, musíte bejt fakt dobrej. Abyste v Rustu napsal špatný program, musíte bejt fakt blbej.

Děkuji za velmi názornou ukázku toho, o čem jsem mluvil.

To asi byla nadsázka. Spíš je problém v tom, že Rust je těžší na naučení. Znám pár vývojářů, co to vzdali.

Já jsem pochopil Rust tak, že jeho benefitem (oproti) C je v tom, že buzeruje.
Je to stejný jako zásada, že máte psát program/funkci co dělá jednu věc. Protože člověk má omezené mentální kapacity, a tak, pokud musí hlídat všechno (C/C++), tak mu zkrátka nezbude kapacita ohlídat všechno. Zatímco, když tu hrubou práci odvede stroj (Rust), tak se může soustředit na další problémy a odchytá toho víc.
Samozřejmě čas teprve ukáže o kolik Rust tu laťku bezpečnosti/u­žitečnosti posunul. Už teď je ale vidět, že je to o dost.

Benefit to je. Rust buzeruje s lifetimy, jazyky se silnými typovými systémy zase s typy. To je princip odhalení chyb při překladu.

V tom se překladač Rustu zlepšuje, dříve se mi stávalo celkem často, že se korektní kód nepřeložil. Jsem si říkal, jak se v tom Rustu zlepšuju, než jsem někde v release notes našel, že menší frekvence výskytu těchto nepříjemností je vylepšením překladače :)

He, napadlo mě ještě lepší přirovnání, díky tomu, že se momentálně věnuju parserům:

Můžete mít parser, který vám oznámí, že v kódu je chyba. Neřekne kde ani jaká.
A nebo můžete mít parser, který vám řekne, že na řádce 30, sloupci 5 očekává jednu z těchto možností (A, B, C).

Ano, někdo jako pan Kubeček, může prohlásit, že v tom nevidí rozdíl. A má pravdu, že pracovat se dá i s prvním případem. A rozhodně má pravdu, že v obou případech je v kódu chyba.

Já si ale dovolím být rebel, a ignorovat jeho názor, a budu psát parsery přeci jen tím druhým způsobem ;-)

Což nic nemění na skutečnosti, že se mýlíte.

"V tom právě vidím ten největší problém, v tom dokolečka opakovaném dogmatu, že cokoli napsané v C je automaticky fuj ..."

Cokoi napsane v cemkoli je fuj, pokud to pise prase. A jelikoz takovych je cim dal vic, tak to presne podle toho vypada.

Ja si covolim naprosto kacirsky tvrdi, ze kod v C je daleko bezpecnejsi - pokud ho napise nekdo, kdo vi co a proc dela. Zatimci v rustu (nebo dalsich) se spoleha na to, ze se o to postara nekdo jiny.

Zatim se totiz (opakovane) historicky ukazuje, ze pan Ono Seto Samo .. neexistuje.

A tak zas Rust to umí, stejně jako třeba typová kontrola pomáhá zachytit spoustu chyb, i když bychom mohli psát přímo v asembleru bez typů a struktur.

Zatim se totiz (opakovane) historicky ukazuje, ze pan Ono Seto Samo .. neexistuje.

Přesně to jsem měl na mysli. Za dobu, co se programováním zabývám, jsem už zažil tolik (údajně) zázračných a revolučních jazyků, o kterých jejich věrozvěstové hlásali, že v nich nejde psát špatně a že v nich budou dobré programy psát i špatní programátoři. Některé upadly v zapomnění (prolog anyone?), některé se se skřípěním zubů stále používají, protože v nich v tom svatém nadšení byly napsány velké projekty, které není praktické zahodit a přepsat od nuly, některé se stále používají i bez velkého skřípání zubů, ale také už bez toho velkého nadšení. Jedno ale mají všechny společné: žádný nesplnil ty nerealistické sliby, jak v nich zázrakem nepůjdou psát špatné programy a že v nich bude psát skvěle i špatný programátor.

> o kterých jejich věrozvěstové hlásali, že v nich nejde psát špatně
Což jsou ale vaše slova. Myslím, že o Rustu to nikdy nikdo netvrdil. Tvrdí se, že Rust je lepší jak C. Ne že v něm jde tvořit bezchybné programy.

Což jsou ale vaše slova. Myslím, že o Rustu to nikdy nikdo netvrdil.

Tak se trochu porozhlédněte přímo v této diskusi. Najdete tu např. tato slova: Abyste v Rustu napsal špatný program, musíte bejt fakt blbej. Dokonce to napsal někdo, kdo zákeřně používá úplně stejný nick jako vy... :-)

Což není to samé, jako tvrzení, že v Rustu nejde napsat špatnej program, které tu tlačíte vy.
Přečtěte si moje příspěvky. V každém, doslova v každém jsem napsal noticku o tom, že Rust není všespásný. A v každé, doslova každé vaší reakci je ignorována. Vaši motivaci nechápu.
Smiřte se s tím. Rust je celkem dobrej počin.

Což není to samé, jako tvrzení, že v Rustu nejde napsat špatnej program, které tu tlačíte vy.

Rozdíl je minimální - a hlavně zanedbatelný proti tomu, jak daleko jsou obě verze toho tvrzení od reality. Realita je taková, že rust do značné míry brání jednomu specifickému druhu chyb, které se v programech mohou vyskytnout. To není málo, ale nezabrání všem ostatním chybám a už vůbec nezabrání psaní špatných programů. A ne, na to, aby někdo napsal v rustu špatný program, vůbec nemusí být "úplně blbej", rozhodně ne o nic víc než na to, aby ho napsal v jakémkoli jiném jazyce.

No jo, moulové jako “linuxák” výše si myslí, že když jim nejde C++, tam v Rustu jim to půjde líp. Chyba lávky.

Realita je taková, že ten jeden specifický druh chyb, kterému Rust zabrání, je zodpovědný za 70% všech bezpečnostních chyb: https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/

Zbavit se 70% bezpečnostních chyb je velká věc, proto se Rust tolik tlačí. Firmám to totiž v dlouhodobém horizontu ušetří spoustu peněz, bezpečnostní chyby jsou hodně drahé. Peníze stojí jak samotné opravy, tak i administrava s updaty, to jsou přímé náklady. Pak tu máme nepřímé náklady ve formě možného úniku citlivých dat a případná ztráty reputace, když se nějaká chyba medializuje. Tohle se špatně vyčísluje, ale levné to nebude.

...je zodpovědný za 70% všech bezpečnostních chyb

Bohužel mám poměrně dobrou představu, čemu je dnes zvykem říkat bezpečnostní chyba (hint: mezi vývojáři se zkratka CVE často cynicky interpretuje jako "CV Enhancement"), takže jakkoli to číslo zní drsně, samo o sobě mne moc neohromuje.

...bezpečnostní chyby jsou hodně drahé. Peníze stojí jak samotné opravy, tak i administrava s updaty, to jsou přímé náklady.

Námět k zamyšlení: myslíte že "nebezpečnostní" chyby drahé nejsou? A co třeba neefektifvně napsané programy, kde operace nebo výpočty trvají zbytečně dlouho? Nebo třeba neprakticky navržené uživatelské rozhraní, kvůli kterému uživatelům práce trvá déle a navíc je ještě frustruje? To nestojí spoustu peněz?

Bohužel mám poměrně dobrou představu, čemu je dnes zvykem říkat bezpečnostní chyba (hint: mezi vývojáři se zkratka CVE často cynicky interpretuje jako "CV Enhancement"), takže jakkoli to číslo zní drsně, samo o sobě mne moc neohromuje.

Takže nepopíráš, že 70% identifikovaných bezpečnostních chyb je způsobeno chybnou správnou paměti v C/C++, ale zároveň říkáš, že tě to neohromuje a vlasně to není až tak velký problém. To je opravdu zajímavý přístup, protože chybná správa paměti prakticky vždy vede k možnosti remote code execution, pokud má útočník možnost ovlivnit vstup programu (což typicky má). Docela dost to vypovídá o celé této diskuzi. Naštěstí jsou lidé jako ty v menšině (i když jsou docela hlasití), takže máme dobrý důvod věřit tomu, že se situace na poli bezpečnosti zlepší, i když to bude běh na dlouho trať.

Takže nepopíráš, že 70% identifikovaných bezpečnostních chyb je způsobeno chybnou správnou paměti v C/C++

K domu se nemůžu vyjádřit, ta data a metodiku jsem neviděl. Ale vzhledem k tomu, že vím, že výrazná většina toho, co se dnes označuje za bezpečnostní chyby, má ve skutečnosti zanedbatelnou závažnost a velká část jsou dokonce úplné ptákoviny, nemá to číslo, i kdyby nakrásně bylo pravdivé, moc velkou vypovídací hodnotu.

chybná správa paměti prakticky vždy vede k možnosti remote code execution, pokud má útočník možnost ovlivnit vstup programu (což typicky má)

K tomu se ale vyjádřit můžu, protože mi z podstaty mé práce těch "bezpečnostních chyb" rukami projde poměrně dost. Tohle tvrzení není pravda ani zdaleka. A navíc i ten předpoklad, že má (vzdálený) útočník možnost (v dostatečné míře) ovlivnit vstup, je sám o sobě hodně silný a většina CVE ho nesplňuje. Ve výsledku je (naštěstí) remote code execution spíš výjimkou než pravidlem* a i z nich je většina vázána na dodatečné podmínky, typicky že je natažený a aktivní nějaký nepříliš používaný modul. (Velké procento CVE vzniká tak, že nějaký nadšenec vypustí static checker nebo tool typu syzkaller na nějaký starý, dnes už téměř nepoužívaný a nepříliš udržovaný modul a nareportuje výsledek, obvykle aniž by se obtěžoval ověřit, jestli jsou podmínky té chyby opravdu prakticky splnitelné (nebo dokonce vynutitelné) a pokud vůbec ano, jestli se ta chyba dá i nějak využít. To by totiž bylo moc práce a on by nestihl nabrat tolik zářezů.)

* - tvrdíte, že 70 procent bezpečnostních chyb je způsobeno problémem s memory safety a zároveň tvrdíte, že tento typ chyb "prakticky vždy" umožňuje RCE; z toho mi vychází, že podle vás by asi tak dvě třetiny bezpečnostních chyb měly umožňovat RCE.

OK. Beru na vědomí.
Každopádně si dovolím váš názor ignorovat, a budu užívat výhod, které Rust proti C přináší. Za mě vše.

Jen ze zvědavosti, píšeš v čistém Rustu, nebo je tam sem tam unsafe?

Vzhledem k tomu, že v Rustu používám i cizí knihovny, tak tam určitě unsafe bude. A ne málo. Ve svém kódu se unsafe vyhejbám jak můžu. Možná časem mě okolnosti donutí. Co já vím.

Myslel jsem vlastní kód. Taky se tomu vyhýbám jak čert kříži.

Používat jazyk, jehož základním benefitem je schopnost hlídat bezpečnost, a pak ho sabotovat - to nedává smysl :-)

No právě :)

budu užívat výhod, které Rust proti C přináší

To si užívejte, proti tomu nic nemám. Pokud ale ve svém nadšení budete hlásat podobné věci, jako jsem citoval výše, budu se proti tomu i nadále ohrazovat.

Pokud se budete i nadále ohrazovat, že "lepší" je prakticky stejné jako "bezchybné" budu vás i nadále ignorovat jako ztracený případ.

...budu vás i nadále ignorovat jako ztracený případ.

Zatím jste mi nedal jediný důvod k tomu, aby ve mně tato skutečnost vyvolala jinou reakci než pokrčení ramen. Takže si poslužte...