Názory k článku
Ovladače napsané v Rustu jsou téměř stejně rychlé jako ty napsané v C

A není Rust vlastně akorát Cčko, kde vás za spoustu věcí kompilátor vyhejtí jako školáčka a odmítne program přeložit, ale jinak za běhu jsou prakticky totožné? (Resp. Rust je subsetem C z hlediska schopností)

Není. A nastuduj si to.

I bez praktické znalostí C vidím, že v Rustu se píšou jinak algoritmy, jinak se pracuje s pamětí, má jiné datové struktury atp. Pak uvažte třeba monomorfizaci generik a celou oblast toolchainu a optimalizací kompilátoru. Rust je něco jiného než C.

Ten dojem, že mě rustc vyhejtí jako školáčka, mám však občas taky :-)

Na stranu druhou, slušnější chyby než vyhodí rustc jsem u jiného jazyku neviděla. Často zvládne úspěšně poradit jak problém napravit, nebo rovnou navrhne funkční řešení.

Jak dojde na lifetime, tak mě hejtí, až z toho tluču hlavou o klávesnici...

Tak to hejtování je jen na začátku, když se to člověk učí, ne? Je to vlastně skvělý způsob, jak se ten jazyk rychle naučit :)

Ne, Rust je jak dizajnem jazyka, tak paradigmou a zaroven i funkcionalitou uplne odlisny.

Paradigma pseudo-OOP?

Tak předně je to úplně jiná rodina jazyků. C je Algol family, Rust je z velké části založený na ML, takže klade velký důraz na funkcionální programování. Což v C prakticky neexistuje.

Ty garance dané kompilátorem tu navíc nejsou jen pro "vyhejtění programátora". Kompiler má třeba díky mnohem přísnějšímu typovému systému lepší představu o pointerech, díky čemuž může být výsledek rychlejší než C. (Díky aliasingu - ze starších jazyků tohle umí Fortran)

Veru Rust som na
https://www.levenez.com/lang/

nenašiel

Jó, Fortran, ten vynikal v mnoha věcech.

Subset z akeho hladiska? Rust ti nebrani urobit cokolvek v ramci unsafe bloku, co je AFAIK prave v ramci kernelu pomerne casto potrebne. Cize ta memory safety cast nemusi byt nutne z hladiska vyvoja jadra zas taka podstatna. Tu je status update z Jula, zhruba od 15-tej minuty tam hovoria o async ako jednej z motivacii pouzivat Rust v jadre.

Unsafe blok nevypíná všechny garance, takže je to pořád bezpečnější než C.

Jasne, ja som len reagoval na to, ze Rust compiller "odmítne program přeložit", nechcel som tvrdit ze je unsafe kod automaticky nebezpecny.

Z tohoto pohledu jsou si vsechny jazyky rovne, protoze at uz pisete v C, C++, ASM ci Rustu, vysledkem bude strojovy kod, ze ktereho lze odvodit hezci nebo skaredsi reprezentaci zpetne ve vyssim jazyku.

Ale C++ a Rust prinasi trocha vice pohodli pro autora, stejne tak jako C prineslo vetsi pohodli do sveta ASM, na ukor eliminace nebezpecnych kostrukci (treba v cistem C neudelate jump do prostredku instrukce, zatimco v ASM ano).

První kdo ten dotaz pochopil a rozumně odpověděl.

Rust má kromě buzerujícího překladače také kontroly za běhu.

Pokud se na to díváte z hlediska výsledného strojového kódu, tak asi nebude celky rozdíl mezi C a Rustem, byť se nějaké detaily (třeba kontrola hranic pole, eliminace alokaci na heapu, …) najdou. Z hlediska komfortu programátora je ale rozdíl větší, než píšete. Rust nabízí i různé zero-cost abstrakce. V Rustu lze mnohem snáze řešit chybové stavy. Rust má lambdy a closures.

Zrovna u tech kontrol mezi poli bych cekal, ze je compiler vetsinou vyoptimalizuje pryc. (Nezkousel jsem, ale skutecne by mne prekvapilo, kdyby trebas u


for i in indexes of a
print(a[i]


nejaky moderni jazyk/runtime ten check nechaval.)

IIRC často ano (obzvlášť bych to čekal u konstrukcí jako map), nicméně vždy se najdou případy, kdy to kompilátor nezvládne odstranit ani omezit*. Snad bych s trochou snahy zvládl i formální důkaz redukcí na problém zastavení. Pokud takový kód kompilátor neodmítne a nechce obětovat memory safety, zbývá jen kontrola za běhu.

*) Omezit – někdy může například dávat smysl vyhodit kontrolu mimo smyčku, a v optimistickém případě zvolit rychlou variantu. Kontrola tak nezmizí, ale provádí se méně často.

Tak urcite, a[random(funkce())] vyoptimalizovat nejde ;-)

No nevím Rust je možná víc komfortní, ale C zase zná mnohem víc lidí a mnohem víc lidí v něm dělá než v Rust.

Dnes nepochybně ano. A IIRC má širší podporu platforem, takže v Rustu lze pro kernel vyvíjet jen části, které nebudou pro všechny platformy. Jen nevím, jak to souvisí s tématem.

To asi jo, ale není tak náročné se jej naučit.

C má taky lambdy a closures, akorát jen v clangu. Snad se jednou dostanou do standardu.

Bez ohledu na to jaký rust je ci není. Jako lidé máme perf schopnost tříštit síly.

Bez té "schopnosti tříštit síly" byste neměl variace, které jsou nezbytné proto aby se mohlo dojít k pokroku přirozenou cestou.

13. 9. 2022, 17:56 editováno autorem komentáře

Co je perf schopnost?

Očekával bych 'perfektní'.

A je to hovadina, kterou se dá odstřelit každý pokrok.

I kdyby ne, tak tam má stejně chybu. To, že na 20 podobných projektech pracuje 20 000 lidí neznamená, že by jich stejný počet pracoval na pouze jednom projektu.

13. 9. 2022, 19:32 editováno autorem komentáře

> vyžaduje na LLVM založený kompilátor, nicméně bylo též prezentováno počáteční řešení GCC Rust, plánované na vydání GCC 13 (nicméně to bude běh na delší trať, než GCC srovná v podpoře Rustu krok s LLVM).

Proč srovnávat krok GCC s LLVM v Rustu, když LLVM funguje dobře? Jaký to má smysl?

rekl bych ze majorita kompiluje kernel s gcc a ne s llvm

V clanku ani slovo o srovnani velikosti vysledneho kodu c x rust.

Plnotučné Rust binárky jsou větší, ale když zapnete LTO a povypínáte některé věci (runtime kontroly přístupu do pole, unwind on panic přepnete na immediate abort atd.), tak se dostanete na velikost C.

https://github.com/johnthagen/min-sized-rust

V embedded nejvíc místa zabíraly Debug implementace, formátování čísel a podobné funkce nutné pro pěkný backtrace.

V kernelu to bude možná úplně jedno, protože se budou používat kernel API a panic asi úplně povolený nebude..

A jak je to s sestavením takového jádra?

Používá to Cargo? Jestli jo, půjde jádro sestavit offline? Kolik to stahuje závislostí z někama, které nespravuje klasický package management?