Názory k článku
Christoph Hellwig odstupuje jako správce DMA-mapping v jádře
-
Ne že bych s Christophem Hellwigem ve všem souhlasil, někdy mi ten jeho fundamentalismus dost vadí, ale je škoda, když kvůli tomu, aby se vyhovělo rustařům, končí maintainer s takovou erudicí jako je on. A obávám se, že to nebude jediný případ, pokud Linus včas nezkoriguje své nadšení pro experiment s rustem.
-
Mám na to odlišný názor. Linus si naopak uvědomuje, zjevně stále jako jeden z mála, že myšlenkový beton musí ustoupit realitě.
Nejde vůbec o technickou stránku věci, jak by se mohlo zdát i třeba ze zdejších diskusí. A nemá smysl dohadovat se, jaké má či nemá Rust výhody oproti C (do určité míry, ale nebavíme se tady o javascriptu v jádře...).
Je to problém organizační. Průměrný věk maintainerů i kernel vývojářů je vysoký a roste. A mladí chtějí psát v Rustu. Inu, to je ta realita. A hloupé řeči o tom, že si mají mladí psát vlastní kernel, naštěstí považuje Linus za garbage.
Linus má ohledně celé té Rust věci naopak exemplárně pragmatický postoj. Což je patrné, pokud si pročtete celé stromy z mailing listu, které se toho týkají. A že ten spor občas dopadne tak, že nějaký starý generál není schopný svůj beton rozbít a tedy skončí, holt i to je realita. A za mě jedině správná. Linux je větší než jakýkoli jeho jeden maintainer. A neuvádějme se v omyl tím, že by snad někdo byl skutečně nenahraditelný. -
Filip JirsákStříbrný podporovatelLinus je velmi pragmatický obecně, ne jen v tomto případě. A je to pragmatismus v dobrém významu toho slova. Což má podle mne velký podíl na tom, že se z „tady jsem nahrál experiment na FTP“ stalo nejvšestrannější jádro OS.
Že „kvůli tomu“ končí zkušený správce je problém toho správce. Není to „kvůli rustařům“ a neřekl bych ani, že „mladí chtějí psát v Rustu“ – to je jen vedlejší efekt. Jádro může těžit z toho, že se použije jazyk, který je dostatečně blízký C, ale zároveň dokáže některé věci lépe pohlídat. Rust je jazyk, který ty požadavky splňuje, a zároveň je dnes jediný, který je dostatečně rozšířený na to, aby mělo smysl se jím v jádře zabývat. Takže je správné, že v jádře dostává prostor. Linus si uvědomuje, že něco-jako-Rust je nutnost, a že je lepší s tím začít teď postupně, než si nechat ujet vlak a za pár let se nažit to zpoždění nějakými překotnými změnami dohnat.
-
Nechapem tieto roztrzky preco tam niektori nechcu Rust. Osobne nechapem preco tam napr Linus nechce ani C++, chapem ze tam nechce javu alebo C# alebo ine manazovane jazyky, ale o tom mozno inokedy.
Nechapem preco zrazu odchadza tolko ludi ako prejav nesuhlasu s Rustom v jadre/nejakom module. To kazdy z nich v praci vzdy robia/robili na projekte ktory je cely v jednom jazyku?Dnes je uplne bezne ze mate jeden jazyk na backende, jeden na frontende, do toho este databazu. Pripadne je tych jazykov aj viac, na ktoromkolvek konci. Preto vznikol aj pojem fullstack vyvojar - pretoze nepotrebujete zhanat cloveka ktory vie iba jeden jediny jazyk a nic ine. A je to dnes uplne bezne, pozrite si kolko pracovnych ponuk vyzaduje minimalne dva jazyky, a kolko z nich je fakt striktnych a vyzaduje iba jeden jazyk.
Ale ked pride na uplatnenie rovnakych principov v linuxovom svete, tak sa niektori dvihaju na zadne. To su fakt taki lenivi naucit sa dalsi jazyk? Alebo kde je ten neprekonatelny problem?
28. 2. 2025, 15:56 editováno autorem komentáře
-
radekmStříbrný podporovatel
Dnes je uplne bezne ze mate jeden jazyk na backende, jeden na frontende, do toho este databazu. Pripadne je tych jazykov aj viac, na ktoromkolvek konci.
To je pravda a podle toho to taky vypadá. Občas je těžké pochopit i kus kódu v jednom jazyce, protože ten jazyk má spousty komplikovaných vlastností, které spolu interagují. A tím, že se tam dá více jazyků, tak se situace ještě zhorší.
-
To je totální nepochopení o co tady šlo. Jasně, že se můžou kombinovat jazyky a správně jsi uvedl FE a BE. Jenže ty mezi sebou mají nějaké rozhraní, které by mělo být univerzální a nemělo by se měnit kvůli jazyků, to mě přijde prostě špatně.
Co se týká fullstack vývojářů, tak to je chiméra. Většinou umí jednu část mnohem lépe a druhou prasí. Právě proto se to v dnešní době odděluje tím rozhraním, aby na každé straně mohli dělat lidi co tomu opravdu rozumí a specializují se na to. Tím, že to dělá jeden člověk většinou ta jedna část trpí a nakonec se tím ani neušetří.
Co je ve většině pracovních pozic je irelevantní, protože to většinou zadává někdo, kdo tomu vůbec nerozumí a často to je výčet všeho co se na projektu používá. Často jsou tam úplné nesmysly typicky dnes AI, jenom aby se natáhnul zájem a pak člověk zjistí, že o tom uvažují a že to mají v plánu "blízké" budoucnosti (takže nikdy). -
nechapem preco tam napr Linus nechce ani C++, chapem ze tam nechce javu alebo C# alebo ine manazovane jazyky, ale o tom mozno inokedy.
Protože Linux kernel není něco, co by jste psal jako one time projekt, na který už pak nikdy nešáhnete. Předpokládá se, že kód, který tam bude, tam klidně může vydržet dalších 20 let. A u takového kódu chcete, aby byl zkompilovatelný i za těch 20 let. Proto není rozumné přidat podporu pro jazyk, který má potenciál se radikálně změnit, nebo jehož knihovnu spravuje jeden člověk nad důchodem, nebo jazyk, který vyvíjí firma, která taky za tu dekádu už nemusí existovat, nebo mít jiné zájmy. -
DannyStříbrný podporovatelA on nekdo napsal nejaky kernelovy modul v Jave? :-) Ze tuhle moznost vubec nadhazujete...
-
-
DannyStříbrný podporovatel
Kolik ze tu beha programatoru v Cobolu nebo Fortranu? :-) Ptam se pro kamarada.
-
DannyStříbrný podporovatel
A tak ono i jen v pripade GCC mate urcenou nejakou minimalni verzi... co se v case posouva a pokus zkompilovat to starsi verzi skonci... tak trochu vybuchem :-) To same se tyka dalsiho toolingu okolo. Ono i samotne C se vyviji, zeano. Pokud vyvojarum dava smysl nektere veci psat v Rustu, ja s tim problem fakt nemam.
PS: zkuste si nekdy zkompilovat treba Firefox... :-) -
DannyStříbrný podporovatel
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.
-
To je klasický argumentační faul. Přeci z toho že byl povolen (velmi pragmaticky smýšlejícím Linusem) jeden další jazyk nijak nevyplývá že bude za pár let povolen jiný. A pokud ano, tak to.nebude k dobru věci. Pro své tvrzení máte stejnou oporujako k tvrzení že následujícím krok bude rituální obětování vývojářů Baalovi.
28. 2. 2025, 19:15 editováno autorem komentáře
-
radekmStříbrný podporovatel
Urcite hrala velice podstatnou roli. Proto jazyky jako ATS (Applied Type System), ktere tu byly pred Rustem, nemely zadnou sanci, i kdyz nektere byly a stale jsou lepsi nez nejnovejsi Rust. Zejmena z pohledu bezpecnosti by ATS bylo urcite lepsi volba, protoze v jeho typovem systemu popisete mnohem vice invariantu (napr. ze index je uvnitr pole).
-
radekmStříbrný podporovatel
Co podle vas byl ten duvod? Proc to nevyhral jiny jazyk, ktery mel podobne kvality?
-
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:
- 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.
- 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ů).
- Musí být stejně rychlý nebo rychlejší než C.
- 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.
-
radekmStříbrný podporovatel
Ad (1): Takze jde hlavne o popularitu? Protoze tohle eliminuje vetsinu jazyku, nikoliv (2).
-
A klidne muzeme zacit i diskusi o tom co nastane az Linuse klepne pepka…
To je v tomto kontextu velmi relevantní otázka, mimo jiné i proto, že Christoph Hellwig by v takovém případě byl pravděpodobně nejlepší volbou coby ten, kdo by ho mohl nahradit. Tím spíš je mi smutno z těch nadšených výkřiků
Když se nechce přizpůsobit, tak ať si jde.
od (nejen) zdejších rust fans. -
To je v tomto kontextu velmi relevantní otázka, mimo jiné i proto, že Christoph Hellwig by v takovém případě byl pravděpodobně nejlepší volbou coby ten, kdo by ho mohl nahradit.
Pokud by měl někdo Linuse nahradit, tak by to měl být spíš Greg Kroah-Hartman, který se vyslovil velmi silně pro Rust v kernelu.
Pozice leadera tak velkého projektu, jako je Linux kernel, je totiž mnohem více manažerská (a politická) než technická. Jistě, leader musí mít technický background a musí být relativně dobrý i technicky (už jen proto, aby ho ostatní respektovali), ale musí být současně i dobrý manager a řešit politiku (tomu se u tak velkého projektu nevyhne). Ve vší úctě ke Christuphu Hellwigovi, jako manažera ho nevidím. On je určitě skvělý technicky, jenže to je málo na leadera. Naopak u Grega ty manažerské kvality vidím (a popravdě si myslím, že jako manager by byl lepší než Linus).
-
Pokud by měl někdo Linuse nahradit, tak by to měl být spíš Greg Kroah-Hartman
To by z mnoha důvodů nebyl vůbec dobrý nápad. Greg Kroah-Hartmann je především příliš "hodný" a je známý tím, že nemá moc ve zvyku odmítat patche nebo pull requesty, které se mu pošlou. Stav stable a jeho porovnání s oficiálními pravidly pro to, co tam patří, je dostatečně odstrašujícím příkladem.
A role hlavního maintainera Linuxu je především v tom, aby udržoval úroveň kvality a tvrdě odmítal věci, které nemají potřebnou kvalitu nebo neprošly potřebným procesem - a třeba kvůli tomu jít i do konfliktu, pokud to maintainer subsystému odmítá akceptovat. Nepochybuji, že kdyby to místo Linuse dělal Greg KH, bylo by takových konfliktů méně a "bulvár by neměl o čem psát" - ale nemyslím si, že by to kvalitě jádra prospělo. Christoph Hellwig, jakkoli mám k němu řadu výhrad, by pro takovou práci - a především pro Linux jako takový - byl daleko vhodnější volbou.
-
Filip JirsákStříbrný podporovatel
No, jak se ukázalo, tak by nejlepší volbou nebyl. Protože z dlouhodobého hlediska je velmi důležitý Linusův přístup, že je potřeba jádro postupně modernizovat, i když to občas bolí. Přičemž je Linus při té modernizaci velmi konzervativní, nezabývá se kdejakou novou blbinou – ale nezabetonovává současný stav na věky.
Když se nechce přizpůsobit, tak ať si jde.
nejsou žádné nadšené výkřiky, ale konstatování smutného faktu. A neříkají to zdaleka jen Rust fans, ale většina lidí, která to říká, je vůči Rustu neutrální. C není nejdokonalejší jazyk na světě ani pro psaní jádra – dalo se očekávat, že se jednou objeví jazyk, který bude splňovat požadavky na psaní jádra (nebo jeho částí) a v něčem bude lepší než C. A zatím to vypadá, že by Rust tím jazykem mohl být. -
A zatím to vypadá, že by Rust tím jazykem mohl být.
Možná - ale to by bylo lépe vidět na jádře OS, které by bylo celé od začátku napsané v rustu. Experiment s rustem v linuxovém jádře zatím ukazuje přesně to, co skeptici tvrdili už když se ta myšlenka objevila poprvé: (1) skutečně dvojjazyčné jádro je neštěstí formátu Babylonské věže, což se teprve začíná pomalu ukazovat, kdykoli se někdo pokusí rust použít na něco víc než izolované a postradatelné leaf drivery, a (2) lidé kolem rustu v jádře mají minimální představu, co obnáší synchronizace ve výkonově náročnějších částech jádra, co je to memory model a co je a co není reálné požadovat a očekávat, na což od začátku upozorňoval např. Paul McKenney, ale jeho hlas v tom všeobecném nebyl moc slyšet.
-
> skutečně dvojjazyčné jádro je neštěstí formátu Babylonské věže
Pokud nikdo nemá ambice jádro kompletně přepsat (s ohledem na velikost good luck) ani kompletně nahradit, zbývá asi jediný způsob, jak se vyhnout dvojjazyčnosti: Donekonečna trvat na jazyce zvoleném na začátku projektu. Což si nemyslím, že by bylo dlouhodobě udržitelné.
-
radekmStříbrný podporovatel
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.
-
Filip JirsákStříbrný podporovatel
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...
-
Filip JirsákStříbrný podporovatel
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.
-
Filip JirsákStříbrný podporovatel
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í.
-
Filip JirsákStříbrný podporovatel
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.
-
Filip JirsákStříbrný podporovatel
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.
-
radekmStříbrný podporovatel
> 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).
-
radekmStříbrný podporovatel
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.
