Vlákno názorů k článku
Christoph Hellwig odstupuje jako správce DMA-mapping v jádře od Ratbatcat - Dobre, dnes chteji decka psat v rustu, zitra...

Vzhledem k tomu, ze tu mame LTS kernely bych v tomhle problem nehledal ani z pohledu long live distribuci - to je jediny misto, kde by to "radove mene" mohlo skutecne vadit.

No hlavne to neni zadna prosta "soutez jazyku".

Co podle vas byl ten duvod? Proc to nevyhral jiny jazyk, ktery mel podobne kvality?

Protože žádný jiný mainstreamový jazyk s podobnými kvalitami aktuálně neexistuje :-). Teď vážně, aby měl nějaký jazyk v kernelu reálnou šanci, musí splňovat tyto podmínky:

1. Musí být dostatečně mainstreamový (rozumněj rozšířený), aby bylo relativně snadné sehnat programátory. S tím souvisí i věci okolo jako tooling, ten jazyk prostě musí být production ready.
2. Nesmí mít garbage collector, to je no go pro kernel (tímto eliminujeme většinu aktuálně používaných programovacích jazyků).
3. Musí být stejně rychlý nebo rychlejší než C.
4. Měl by být memory-safe. Není to hard requirement, ale když už zavádím nějaký nový jazyk, chci z toho významné benefity navíc. Nemá smysl přidávat nový jazyk, který by byl stejně unsafe jako C, to by nic nepřineslo.

Aktuálně tohle všechno splňuje jen Rust.

Ad (1): Takze jde hlavne o popularitu? Protoze tohle eliminuje vetsinu jazyku, nikoliv (2).

Ano, jde. Dokonalý jazyk, který není populární by neměl smysl. Ale to už vám predřečník napsal. Kritérium prostě není dokonalost, ale to, že splňuje pár základních požadavků a je populární.

Nikoliv hlavně. Ale je to podmínka, která musí být splněna.

Mohli si jazyk upravit a vylepšít. Jednotlivci dokázali přijít s jazyky, které řeší řadu problémů s C, ale zároveň jsou velice blízko C, takže možné to určitě bylo.

Když si mám vybrat, zda pro jádro použít jazyk, který používá spousta dalších projektů (a jejich počet se neustále zvyšuje), nebo jestli používat proprietární rozšíření jazyka C s proprietárním rozšířením nějakého kompilátoru, volím jednoznačně první možnost. A nedovedu si představit, že by někdo po promyšlení důsledků zvolil možnost druhou.

A nedovedu si představit, že by někdo po promyšlení důsledků zvolil možnost druhou.

Jako třeba že by se v linuxovém jádře použivala - a někdy dokonce jako doporučený coding style - rozšíření gcc, která se až mnohem později (a možná ani ne všechna) dostala do standardu jazyka? Hm...

Tak mne napadá, dostal se vlastně už rust v jádře do stavu, kdy by ho šlo překládat standardním překladačem bez specifických rozšíření jazyka, která si vymysleli pro tento účel? Ze začátku to tak totiž ani zdaleka nebylo...

Jako třeba že by se v linuxovém jádře použivala - a někdy dokonce jako doporučený coding style - rozšíření gcc, která se až mnohem později (a možná ani ne všechna) dostala do standardu jazyka? Hm...
Zamlčel jste (asi omylem) takovou „drobnost“ – je podstatný rozdíl mezi rozšířením, které už v sobě překladač má a které se používá i v jiných projektech, nebo které je dočasné, a proprietárním rozšířením, které by používalo jenom jádro a nikdo jiný.

Ostatně i to, že šlo jádro překládat jenom pomocí gcc, bylo považováno za problém, a byla snaha to změnit.

Tak mne napadá, dostal se vlastně už rust v jádře do stavu, kdy by ho šlo překládat standardním překladačem bez specifických rozšíření jazyka, která si vymysleli pro tento účel? Ze začátku to tak totiž ani zdaleka nebylo...
To ale v kontextu výběru jazyka není podstatné. Je nepravděpodobné, že by se na stříbrném podnose objevil nějaký jazyk, který se bude používat pro něco jiného a najednou se zjistí, že je vlastně možné ho beze změny použít i pro programování jádra. Ostatně neplatilo to ani pro to C, jak jste sám uvedl. Podstatné je, jestli se směřuje k tomu tyhle výjimky odstranit a potřebné vlastnosti dostat do standardního kompilátoru, nebo jestli si naopak ty proprietární vlastnosti začneme hýčkat, přidávat další a další, až jádro zamrzne na jedné konkrétní verzi kompilátoru, protože nebude schopen ty úpravy portovat na novější verze; a až bude programovací jazyk tak specifický, že když někdo bude chtít začít přispívat do jádra, bude se nejprve muset naučit specifický jazyk (čímž by se samozřejmě výrazně zvýšila bariéra pro vstup).

je podstatný rozdíl mezi rozšířením, které už v sobě překladač má a které se používá i v jiných projektech, nebo které je dočasné, a proprietárním rozšířením, které by používalo jenom jádro a nikdo jiný

Tou druhou možností jste ovšem popsal přesně to, co se dělo - a možná ještě děje - v případě rustu v linuxovém jádře…

až bude programovací jazyk tak specifický, že když někdo bude chtít začít přispívat do jádra, bude se nejprve muset naučit specifický jazyk

Vy asi s kódem linuxového jádra moc zkušeností nemáte, že? Jinak byste totiž věděl, že pokud opravdu chcete v jádře něco netriviálního naprogramovat, je potřeba se naučit docela dost věcí, které v userspace nepotkáte. A i když technicky nejde o rozšíření jazyka, protože příslušné konstrukce jsou implementované pomocí jeho stávajících prostředků, z hlediska vstupní bariéry to zásadní rozdíl není. Také si nedělejte si iluze, že výraznější rozšíření rustu v jádře by tuhle vstupní bariéru pomohlo nějak omezit, bylo by to přesně naopak, jen s tím, že by to vytvořilo novou bariéru i pro ty, kdo už se na vývoji jádra dávno podílejí, protože pak by bylo nezbytné znát příslušné obraty, postupy a kontrukce pro dva velmi odlišné jazyky.

Ono je velmi frustrující vést podobné diskuse s lidmi, kteří mají ohromné nadšení pro rust, ale mají mizivé tušení, co vývoj jádra obnáší v praxi, ať už z hlediska vývojářského nebo procesního. Asi dělám chybu, že když vidím moc velké nesmysly, nechám se vyprovokovat a znovu a znovu se do toho pouštím, i když už jsem mockrát viděl, jak marné to vysvětlování je.

Asi dělám chybu, že když vidím moc velké nesmysly, nechám se vyprovokovat a znovu a znovu se do toho pouštím, i když už jsem mockrát viděl, jak marné to vysvětlování je.

Nie nerobíte chybu, osveta je nutná. Ja sa tiež zas pripojím, ale teraz nemám čas.

Tou druhou možností jste ovšem popsal přesně to, co se dělo - a možná ještě děje - v případě rustu v linuxovém jádře…
Nikoli, Rust se používá v mnoha jiných projektech, ne jen v linuxovém jádře.

Jinak byste totiž věděl, že pokud opravdu chcete v jádře něco netriviálního naprogramovat, je potřeba se naučit docela dost věcí, které v userspace nepotkáte.
Přemýšlel jsem, zda to mám explicitně psát – a pak jsem si řekl, že to přece není nutné, nejsme malé děti. No, tak je to nutné: pokud se někdo chce dostat k vývoji jádra, zpravidla začne něčím triviálním, kde nepotřebuje znát specifika jádra. Teprve když se trochu rozkouká, dostane se k věcem, které jsou pro jádro specifické a musí se je naučit.

Také si nedělejte si iluze, že výraznější rozšíření rustu v jádře by tuhle vstupní bariéru pomohlo nějak omezit,
Já nepotřebuju, aby Rust tuhle bariéru omezil. Mně stačí, když ji nezvětší – což by Linux-C udělalo. A navíc si myslím, že Rust má potenciál některé ty znalosti navíc, které musí mít programátor v C, nevyžadovat po programátorech v Rustu.

Asi dělám chybu, že když vidím moc velké nesmysly
Možná děláte chybu v tom, že vidíte moc velké nesmysly i tam, kde je nikdo nepsal.

Pokud máte představu, že vývoj jádra je něco jen pro pár vyvolených, kteří když už něčím začnou, rozhodně to není nic triviálního, je pro vás pochopitelně frustrující diskuse o tom, jak zpřístupnit vývoj jádra se zachováním stejné kvality většímu množství lidí.

Nikoli, Rust se používá v mnoha jiných projektech, ne jen v linuxovém jádře.
Tak já se optám, jaké kritické projekty jsou napsané v Rust? Já totiž zatím spíš slyším o přepisech starých projektů. Je něco již dnes v Rust, bez čeho nelze žít? Jako třeba pro Go Docker a Kubernetes?

Tak já se optám, jaké kritické projekty jsou napsané v Rust?
Marně v citaci, na kterou navazujete, hledám slovo „kritické“. Takže netuším, jak se vaše otázka vztahuje k mému komentáři.

Připomínám, že se bavíme o tom, jestli použít existující jazyk, nebo jestli si vyrobit jakési „Linux-C“ – C upravené na míru pro psaní linuxového jádra. Přičemž argumenty pro existující jazyk jsou ty, že se 1. použijí již hotové nástroje, které se používají i v jiných projektech, takže těch nástrojů bude daleko víc, s daleko více možnostmi a daleko kvalitnější, než kdyby se pár vývojářů udržovalo speciální jaderný kompilátor (a těch vývojářů by opravdu byly jednotky – byli by to jen vývojáři jádra, a z nich ještě jen ti, kteří by se chtěli věnovat tomu kompilátoru). A za 2. budou v tom moci začít psát i vývojáři, kteří ten jazyk znají z jiných projektů.

Nic z toho nevyžaduje, aby jiné projekty v Rustu byly „kritické“, ať už to znamená cokoli. Ostatně i tooling kolem C, který se používá v jádru, se před tím nemusel používat na kritických projektech; a vývojáři, kteří začali přispívat do jádra, také před tím nemuseli psát kritické projekty v C.

Podle komentářů tady v diskusi si někteří myslí, že když chce někdo nový přispívat do jádra, musí mít schopnosti minimálně Linuse Torvaldse, spíš lepší. A jazyk, který se použije, musí být schopný minimálně nahradit plně C (a assembler se nezmiňuje jenom proto, že by pak požadavky nesplnilo ani C). Ale tak to není. To, co vstupuje do jádra nově (ať už nástroje, kód nebo vývojáři), nemusí být na začátku lepší, než to nejlepší, co tam je. Stačí, když to nové bude lepší, než to nejhorší, co už v jádru je.

Proboha, já jsem chtěl jenom vědět, jestli existuje nějaký projekt napsaný v Rust, který se opravdu používá a využívá ho hodně lidí (příklad s Go jsem uvedl). A vy mi odpovíte takovým slohem v kterém navíc chybí odpověď. To neměla být žádná kritika Rustu, jenom mě to zajimalo. Marně totiž něco hledám. Napadá mě ruff, ale to je taky primárně přepis Python tools.

Saljack: Příště, až se budete chtít zeptat na „nějaký projekt“, ptejte se na „nějaký projekt“ a ne na „kritický projekt“. Projektů napsaných v Rustu je spousta, třeba Servo, Deno, Firecracker, Pignora, SurrealDB, některé backendové části AWS nebo OpenDNS, malé části Windows.

Subjektivně když porovnám, v čem jsou napsané programy, se kterými se setkávám, tak dříve toho bylo víc v Go (také vzniklo dřív), ale Rust už to dotáhl a nové větší věci jsou spíš v Rustu, Go se upozaďuje a zůstává pro věci, jejichž podstata spočívá v síťové komunikaci s jinými aplikacemi, ale jiná vlastní práce tam tolik není.

Může být.

Každopádně věc se má tak, že Rust "vypadá" dobře. Splnil požadavky, které žádný jiný jazyk ne. Je po něm poptávka (ona by byla i po jiných jazycích, jako třeba po C++, nebo Go, ale ty neprošli vstupní bariérou). A taky si můžete všimnout, že se na tu adopci jde docela "opatrně". Pokud se ukáže, že to byl špatný nápad, tak to nebude tolik bolet jej vykuchat.

Já jsem sice fanda do Rustu, ale jeho použití v jádře Linuxu mě nechává celkem chladným. Používám ho na aplikační úrovni. Jen těm rust-haterům poněkud nerozumím.

> A nedovedu si představit, že by někdo po promyšlení důsledků zvolil možnost druhou.

Nj. ale spousta subjektů s tím problém nemá. Historicky třeba Apple, který Objective-C přejal a propagoval.

A při pomyšlení na hromady nevýhod Rustu hodně lidí odejde po jeho odzkoušení k jiným jazykům. Proto mi přijde, že podpora Rustu spíš vychází z toho, že ten jazyk moc lidí kolem jádra nezkoušelo (i když to zní divně, ale nevím, jak jinak si to vysvětlit).

A při pomyšlení na hromady nevýhod Rustu

Ale no tak.
Ta hromada nevýhod Rustu jsou cca dvě:
- Je to nový jazyk
- Musí se u něj trochu přemýšlet

Jestli on ten apel na Rust-fans není spíše problém Rust-haters.

Už jsem to zmiňoval hodněkrát. Je to třeba komplikovanost unsafe kódu, která je větší než u C. Což by bylo v pohodě, pokud by v jádře nebyl třeba, ale tak tomu není. Jiná věc je složitost jazyka. Neoptimalizující kompilátor C napíše i jednotlivec, ale u Rustu je těžké napsat jen samotný typechecker a borrow checker. Kolik dalších implementací má Rust? Má nějakou specifikaci?

Co se týče unsafe kódu, tam jsem sice rád, že jsi to rozvedl, ale ve výsledku jsi mě nepřesvědčil, že by to byl problém. Nabyl jsem dojmu, že tě prostě vytáčí, že Rust není dokonalejší než je.

Složitost jazyka není problém, ale volba.

Ad specifikace - netuším. Osobně sázím na to, že než se Rust v jádře etabluje, tak i Rust bude mnohem klidnější. Implementace má momentálně dvě rustc, mrustc, plus nějaké backendy.

Takže omlouvám se, ta hromada problémů není o dvou, ale o třech věcech - ještě tedy absence specifikace.

> Je to třeba komplikovanost unsafe kódu, která je větší než u C.

Ale zase je o to jednodušší psát ty safe části. Otázka potom je, co převáží.

Nicméně uznávám, že mohou existovat části kernelu, které se budou psát lépe v C, aspoň zatím. Což ale není problém, dokud ty jazyky jsou k dispozici oba…

> složitost jazyka

Složitost jazyka nemusí být na škodu. Jedním z nejjednodušších jazyků je Brainfuck.

Jestli on ten apel na Rust-fans není spíše problém Rust-haters.

Rust-haters neexistujú. Ide skôr o výhrady k tomu ako je Rust prezentovaný.

A čo sa nás ostatných týka, tak keby sa ukázalo, že sa bez Rustu nepohneme, tak budeme v pohode písať v Ruste. Akurát vám, čo v ňom píšete teraz, pribudne celkom konkurencia. A silná.

Lze to pojmout různě. Například lze přidat komentáře a spouštět na tom borrow checker, což by zároveň neomezovalo, jaký kompilátor použiju. Pokud by existoval nějaký takový dostatečně dobrý hotový* nástroj (nevím o něm), mohla by to být schůdná cesta. Znamenalo by to část přínosu Rustu a část jeho nákladů. Navíc by takový kód mohl být připraven na lepší interoperabilitu s Rustem.

*) Jenže takový nástroj by nejspíš chtěl ideálně i další ekosystém, jako je podpora v IDE.

Nejsem si jistý, jestli mělo jít o nějaké konzervativní vylepšení C, nebo nový jazyk, který v rámci možností umí dostatečně dobře s C interagovat.