Já jsem ho pochopil tak, že uznává, že nemá cenu lpět na C a že k tomu jsou dobré důvody. Je opatrný pokud jde o to, jestli tím bude zrovna Rust, resp. čeká, jestli se využití Rustu v jádře osvědčí a doopravdy přinese slibované výhody. Někde se vyjádřil tak, že nasazení Rustu do jádra zatím bere jako experiment.
Proč byste něco dodával? Mne jen zajímalo, kdo je ten zamlčený podmět "my" v té větě. Protože, jak už tu někdo podotkl, žádná solidní diskuse na toto téma zatím opravdu stále ještě neproběhla. Jen spousta nadšenectví a neustálého opakování mantry "memory safety", zatímco vážné připomínky a upozornění na reálné praktické problémy jsou buď ignorovány nebo bagatelizovány. I jen to, aby Miguel Ojeda a spol. přiznali, že opravdu chtějí nastolit stav, kdy by přinejmenším všichni maintaineři a revieweři museli ovládat rust a rozumět jeho integraci do jádra do takové míry, aby byli schopni provádět review a adaptovat kód (což není ani zdaleka triviální), trvalo několik měsíců, během kterých usilovně mlžili a ignorovali přímé dotazy.
Takže ne, opravdu zatím, na rozdíl od autora zprávičky, nevidím nic, na základě čeho bych očekával rustifikaci jádra během roku 2022. Můj osobní názor na to, jestli by k ní vůbec mělo dojít, je úplně jiná otázka, to už jsem před časem pochopil, že v prostředí jako tady nemá smysl řešit.
“Jen spousta nadšenectví a neustálého opakování mantry "memory safety", zatímco vážné připomínky a upozornění na reálné praktické problémy jsou buď ignorovány nebo bagatelizovány.”
Nadšenectví patří ke každému hypu. Před dvaceti lety panovalo stejné nadšení okolo Javy.
15. 12. 2021, 09:23 editováno autorem komentáře
Ta diskuze probíhá, jenom na trochu jiné úrovni, než jsou komentáře na root.cz. Číst ji můžete stejně jako kdokoli jiný, odkazy najdete mimo jiné třeba in a this-week-in-rust.org. Důvody jsou známé, stejně jako názory (celkem tomu otevřené) stěžejních vývojářů jádra. Známé jsou i odpovědi na otázky a námitky. Ano, mít v kernelu víc jazyků znamená, že review a integrace jsou složitější, to nikdo nikdy nepopíral. Jde o to, jestli výhody za to stojí a i tady jsou známé a solidní argumenty, včetně toho, že pro dohlednou budoucnost se uvažuje o používání Rustu v leaf modulech jádra tak, aby se to centrálního jádra zatím nedotýkalo a aby bylo možné vyhodnotit náklady a přínosy. Dalším důvodem k tomuto přístupu je jiná rozumná námitka, a sice že Rust oficiálně nepodporuje řadu architektur, na kterých jinak Linux funguje. Naopak memory safety není žádná nadšenecká mantra, je to extrémně důležitá vlastnost zejména pro software, jako je jádro.
Že zrovna vy jste se neobtěžoval si nic z toho vyhledat na tom nic nemění. To, že já Rust neumím a nechci se ho učit a proto se nesmí používat taky není rozumný argument. Je to jako se vším. Jste vývojář jádra? Pokud ano, uveďte své seriózní námitky v příslušném kanále (LKML) a třeba budete vyslyšen, třeba ne a podřídíte se. Pokud ne, nekňučte a berte, co se vám dává, nebo si Linux forkněte a udržujte verzi zaručeně bez Rustu. Pokud najdete dost lidí, kteří budou tenhle váš pohled sdílet, třeba se z toho stane životaschopný projekt.
Ta diskuze probíhá, jenom na trochu jiné úrovni, než jsou komentáře na root.cz.
Ne, root.cz jsem opravdu nemyslel.
odkazy najdete mimo jiné třeba in a this-week-in-rust.org
Ne, ani tohle jsem nemyslel.
Jste vývojář jádra? Pokud ano, uveďte své seriózní námitky v příslušném kanále (LKML) a třeba budete vyslyšen
Zkoušel jsem to v LKML i na LWN a byl jsem ze strany rust fans zcela ignorován, stejně jako mnoho dalších. Teprve po několika měsících konečně na rovinu přiznali, jaký stav je jejich skutečným cílem. Tedy že nejde jen o nějaký izolovaný experiment pro pár driverů, kterých si ostatní nemusejí všímat.
Právě protože sleduji ty relevantní diskuse, vím, že ta věc není ani zdaleka ve stavu, kdy by se dal očekávat brzký merge, a že nějaká vážná diskuse o principiálních otázkách, jako je efekt na procesy správy jádra, ještě vůbec neproběhla. Pořád je to v rovině "rust is memory safety, memory safety is good, mkaaay, you need rust, mkaay."
Takže blábolíte.
https://lwn.net/Articles/829858/
https://security.googleblog.com/2021/04/rust-in-linux-kernel.html
atd.
Nikdo nemusí nic "přiznávat", není žádný tajný "skutečný cíl". Že by někdo chtěl Linux úplně přepsat do Rustu je jisté, a je to stejně naivní jako ti, co se jakékoli představě o Rustu předem brání. Mimo to ale existuje realita a na ní není nic tajemného. Jestli jste zkoušel na LKML vznášet podobné "argumenty" jako tady, tak se při vší úctě nedivte, že to nikomu nestálo za odpověď.
Ale podle všeho to bude zase nějaká konspirace jako systemd, co? ;)
Tým "COBOL"-om som skôr mal na mysli veľký hype v oblasti business sektoru. Práve teraz sa kopec systémov prepisuje do javy. Korporáti zistili, že náklady na migráciu javy z platformy na platformu sú mizivé, miesto windows servera a UNIX-ov sa nasadzuje Linux. Java na linuxe beží dobre, o 40 rokov budú najímať šedivých programátorov, čo prepíšu softvér z javy do jazyka, ktorý bude vtedy novým COBOL-om.
Objective C nebolo nikdy populárne kvôli uzavretosti ekosystému a microsoft preferoval skôr C++.
[Michal Kubeček]
"Proč byste něco dodával"
Protoze, kdyz vidim, jakym zpusobem to cele probiha, formu diskuze s mistnimi fans a ktere firmy to uz delsi dobu podporuji, rapidne to snizuje moji duveru. Jenze ani ja - stejne asi jako vy - nechci se o tom proste hadat s mistni fans, proto k tomu nic nechci dodavat.
Jinak s Vami naprosto souhlasim.
15. 12. 2021, 11:36 editováno autorem komentáře
Kdyz to tak vezmete, tak moderni prohlizec anebo SQL databaze maji a architekture OS kernelu celkem blizko.
Jakmile nejaky projekt implementuje vlastni memory management, vlastni scheduler, runtime a zamykani a tak uz to ma OS celkem blizko.
V coding guideline Mozilly, vybrali urcitou podmonozinu C++, kvuli ruznym problemum, kterym celili. Dale napr, nebylo mozne otevirat a zavirat soubory mimo hlavni thread a resilo se to tim, ze se posilala zprava do hlavniho threadu, aby nejaky soubor otevrel. Neco z tome pripomina omezeni, ktera prinasi vyvoj kernelu. Nakonec se nedivim, ze ten Rust vznikul.
Opravdu by mne zajimalo, jak by fungoval Unixovy operacni system "z druhe strany", ktery by nekdo naprogramoval stylem ze by vzal nejmensi mozne monolyticke jadro typu 4.xBSD/"SystemV", inspiroval se nejakymi chytrymi features typu IPC Mach (OS/X) a binder, pridal k tomu slusne udelane kernelove eventy + se mirne inspiroval u "user32" WinAPI kde jsou nektere veci vyresene lip nez v POSIXu.
A do toho narval zakladni userland z OpenBSD + dalsi baliky z Ubuntu.
Misto systemd, rustu, ruznych 'fancy' compositoru, atd.
Myslel jsem to typove, kdyz clovek otevre zdrojaky userlandu OpenBSD/NetBSD a nekdy i FreeBSD a srovna to s ekvivalentem v Linuxu a OS/X, tak rozdil v pristupu je obrovsky.
Videt to je znacne i ve 'library version hell' (nebo jak se tomu rika). Ted jsem zrovna neco prekladal na Debianu na ARMu a nejak se mi system dostal do stavu, kdy dynamicky linker u meho primitivniho programku byl nespokojeny se symbolem strcmp ... to mne dostalo.
sed obecne umi hovno, hlavne dialekt regularnich vyrazu je dnes hodne zastaraly. naucte se perl https://blog.parseltongue.io/2020/10/25/perl-sed-grymoire.html
1. Napíšou: https://www.redox-os.org/
2. S tím przněním bych brzdil. Linux nebyl, pokud vím, zamýšlen jako pomník jazyku C a jestli tam má nebo nemá být jiný jazyk vyšší úrovně, si zaslouží seriózní debatu.
Pokud se použije jen podmnožina Rustu jako “lepší C”, přinese to aspoň bezpečnější kód. Pokud se použijí i (rádoby)sofistikované abstrakce, bude z toho nakonec bolehlav. Rust je nízkoúrovňový jazyk a IMHO se do jádra hodí, ale bez některých konstrukcí vyšší úrovně, které kód spíše komplikují, než aby pomáhaly.
Do jisté (malé) míry na tom něco je pokud se bavíme o nízkoúrovňovém kódu. Tam je někdy opravdu důležité, aby zdroják a výsledný assembler si pokud možno odpovídaly 1:1. Ranné verze Rustu měly výjimky, dědičnost i GC ale tyhle věci byly odstraněné právě proto, že usoudili, že do systémového jazyka nepatří (na rozdíl od např. jazyka pro GUI aplikace jako je Swift).
Tam je někdy opravdu důležité, aby zdroják a výsledný assembler si pokud možno odpovídaly 1:1.
Dulezite to je, ale dnesni prekladace delaji pri optimalizacich opravdu divoke kousky a korespondence 1:1 ke strojovemu kodu je dnes jen iluzi davnych dni a misto toho je nutne blbnout s volatile, aby prekladac nevyhodil neco duleziteho.
Zajímavé, že nové projekty se C++ v jádře nijak nebrání. Třeba Zirkon používá subset C++17:
https://fuchsia.dev/fuchsia-src/development/languages/c-cpp/cxx
Trvat na tom, že nějaká feature je v projektu zakázaná se dá řešit přímo na úrovni CI. Možná Linus jen nemá rád C++ - ono když něco nesnášíš, argumenty si vždycky najdeš. Ale rozhodně bych to neinterpretoval tak, že C++ v jádře je špatné...
Klíčové je slovo “subset”. Rust i C++ mají společnou množinu problematických vlastností, které tolik nevadí v jádře, ale na vyšší úrovni ano. Pro Rust asi hovoří jednoduchost syntaxe oproti C++. Nicméně jádro jde psát v kde čem, Microsoft si napsal jádro OS v C# a v Japonsku měli výzkumný projekt, v jehož rámci napsali jádro v Prologu (resp. jeho paralelizované variantě), to jen Unix a jeho dědicové závisí na C (ostatně C vzniklo kvůli portaci Unixu).
Jenže C++ je otesánek, který nemá nikdy dost. Přidává další a další vlastnosti a způsoby, jak řešit totéž. S každou další revizí budeš pořád dokola s někým řešit, že tohle je fakt cool vlastnost a hodilo by se ji povolit.
Zircon, pokud se nepletu, je pořád výzkumný projekt a hračka Google. Argumentovat tím, že někdo napsal nějaké jádro v nějakém jiném jazyce sice můžeš, ale bylo by dobré srovnávat srovnatelné a s Linuxem se může srovnávat máloco.
Tak Rust se tím ani netají, že se v jistém slova smyslu hlásí tam, kde je C++ doma. Taky jsem opakovaně zaznamenal, že máš vůči Rustu výhrady (zmiňoval jsi runtime) - no proč ne. U mě je Rust poměrně kvalitně zamaskovaný funkcionální jazyk s imperativní syntaxí. Něco, co mi asi sedí filosofií nejvíce.
Normální je mít výhrady ke každému jazyku, Rust je ještě v pohodě, důležité je používat jazyky v kontextech, kam patří. Že je Rust kvalitní je pravda (sedí na LLVM), všechny moderní jazyky jsou dobře implementované. BTW Rust žádný runtime nemá (a je to IMHO dobře, zvlášť pro nasazení v jádře). Nicméně skutečně funkcionální není, na to má moc slabý typový systém (přítomnost flatMap z něj funkcionální jazyk nedělá).
> BTW Rust žádný runtime nemá (a je to IMHO dobře, zvlášť pro nasazení v jádře).
Ano, tohle jsem měl na mysli. I když - co Tokio a spol.? Nebo třeba https://blog.mgattozzi.dev/rusts-runtime/
> Nicméně skutečně funkcionální není, na to má moc slabý typový systém (přítomnost flatMap z něj funkcionální jazyk nedělá).
Nejde o flatMap, jde mi o to, že je z velké části založen na výrazech a ne na příkazech, má ADT a pattern matching, je defaultně immutable apod. Určitě věřím, že to někoho neuspokojí a představoval by si nějakou Mirandu, Agdu nebo nevím co. Ale doufám, že je aspoň trochu jasné, kam mířím.
Tokio je technicky knihovna, ne? BTW zrovna Tokio asi v jádru chtít nebudou :)
To s tím ADT apod. je právě někdy problém, fláknout na nízkoúrovňový jazyk ADT a další superabstraktní koncepty, to prostě musí zákonitě někde drhnout. S mírnou nadsázkou je Rust jednoduše asembler s monádama :) Už teď pozoruju, jak se v různých projektech rozhodují jen pro podmnožinu Rustu (stejně jako v C++), to není úplně dobrý směr vývoje, to je přesně pozice "too high a level for systems programming, too low a level for general programming". To druhé už je (pře)obsazené, tak ať se Rust drží svého kopyta, tam má šanci.
Nicméně skutečně funkcionální není, na to má moc slabý typový systém (přítomnost flatMap z něj funkcionální jazyk nedělá).
To je hrozna blbost. Typovy system funkcionalni jazyk nedela, viz cela rodina Lispovych jazyku. Co dela funkcionalni jazyk funkcionalnim, je referencni transparentnost a tady je videt u rustu velky posun timto smerem (ve srovnani s jinymi jazyky pro systemove programovani).
"Rust nemá runtime" je od nich ale je to vědomá nadsázka a není myšlená tak úplně vážně (podobně jako třeba "Rewrite it in Rust"). Rust má podobné runtime jako C++: inicializuje zásobník, alokátor a další struktury, převezme env proměnné a argv, zavolá případné konstruktory statických proměnných, nastaví handler na panic s příslušným výstupem, (pokud program není zkompilovaný, aby při panice rovnou abortoval) atd. a nakonec zavolá main. Po návratu z main ještě provede příslušný cleanup a pokud main vrací Result, vyhodnotí ho.