Josh Triplett (Intel): Rust pro systémové programování

Josh Triplett, inženýr z firmy Intel, v přednášce na Open Source Technology Summit 2019 srovnával využití programovacích jazyků C a Rust pro systémové programování. Shrnutí je k přečtení na webu Packt Hub. Diskuze proběhla např. na Linux Weekly News.

2.9.2019 20:22 | ʚĭɞ 🍉 | Zajímavý článek

Komentáře

[jdsulin2]

Minule tu byl flame o tom proc jeste Rust nenahradil C a v tom clanku/prezentaci to borec vysvetli :)

[Miloslav Ponkrác]

Nevysvětlil.

Drtivá většina věcí se neprosazuje kvalitou či vlastnostmi, ale:

1) Protože se objeví ve správném čase na správném místě.

2) Protože tu věc/jazyk někdo táhne dopředu a prosazuje.

Jak by řekli matematici, kvalita programovacího jazyka je věc nutná, ale nikoli postačující - k tomu, aby se jazyk prosadil (třeba v tom systémovém programování).

***

Když přišlo C, jednalo se o řádově blbější jazyk, než celá řada již existujících jazyků. C se opravdu neprosadilo kvalitou ani vlastnostmi.

[Petr Tomášek]

Minimalističtější neznamená blbější. Taky to může znamenat „v důsledku elegantnější“, což je i příklad C-čka.

[kralyk z abclinuxu]

Pane Ponkrác, když už tady tak ochotně komentujete, mohl byste prosím raději místo psaní stále těch samých řečí na adresu Rustu konečně odpovědět na tento dotaz, kde se ptám po té platformě, která nemá uint16_t, o které jste tvrdil že existuje, nebo dokonce že jich existuje mnoho?

To by bylo myslím o dost přínosnější - byla by tam alespoň pro mě nějaká nová informace. To, že Rust nemá standard, všichni dávno víme.

[Xerces]

S body 1] a 2} souhlasím, ale nesouhlasím s tou matematickou definicí. Někdy se vlivem 1) a 2) prosadí i totální ... zde dosaďte svůj neoblíbený jazyk.

[Miloslav Ponkrác]

Myslím, že článek nepochopil základní problém Rustu pro systémové programování. A to je problém, že je druhý. První bylo C/C++ a tak se etablovalo.

C začalo na neorané půdě, zavedlo si své standardy a své způsoby, jak to vyhovuje jemu.

Rust musí být nejdříve sakra dobrý ve strojáku, a zároveň musí být 100% kompatibilní s tím, co zavedlo C/C++. A navíc musí být aspoň desetkrát lepší než C/C++, aby to ekonomicky stálo za masovou změnu. Až půlka Céčkařů se podívá na Rust, a překvapením jim spadne brada a řeknou bezděčně wow, pak teprve může Rust alespoň trochu uspět v systémovém programování vedle C/C++.

Co článek nezmiňuje je absence záruk Rustu. Není tam záruka standardu a kompatibility jazyky, ten jazyk nemá ani nezávislý psaný standard. Není ta, záruka budoucího rozvoje - momentálně Rust existuje jako finanční parazit na penězích Mozilly.

[Karel]

Hele, nedělej nám z toho zase flame, jo. Tvé názory již každý podobně zná... Dík.

[Miloslav Ponkrác]

Možná ti to maminka nevysvětlila, tak já to udělám za ní:

1) Nikdo tě nenutí číst příspěvky, které nechceš číst.

2) Máš svobodnou vůli nereagovat na příspěvky.

3) Máš svobodnou vůli neúčastnit se diskuse.

Je to vůbec smutné, že musím vysvětlovat lidem základní věci, které často zná i předškolní dítě. Ale Karel je zřejmě poněkud zaostalý.

[ʚĭɞ 🍉]

Možná ti to maminka nevysvětlila, tak já to udělám za ní

Takové perverzní prasárny…

[Sid]

to je ako zamrznut navzdy v puberte. Ponkrac ked uvidi hocikde rust tak sa spusti trigger ktory obide mozog a prsty uz pisu tie jeho C/C++ copy&paste ody. Este u C suhlasim ale ze niekto dokaze onanovat na C++ mi pride uletene. Jazyk tvoreny podobne ako dort psicka a macicky a jeho vysledna kvalita je na tom tiez podobne.

[Miloslav Ponkrác]

Já s vaším názorem na C++ absolutně souhlasím.

Mně osobně se nelíbí ani koncepce jazyka C ani C++.

Pouze je tu jedno ale. V určité oblasti programů, jako je třeba systémové programování, programování mikrokontrollerů, nebo když je potřeba vyždímat maximum z hw - není alternativa.

Svět si pořád hraje s různými "náhradami C/C++". Jenomže to jsou náhrady ryze teoretické, ale nikoli praktické.

Byl bych první, kdo by tleskal, kdyby se někomu podařilo udělat programovací jazyk zaměřený prakticky, že by poslal C/C++ do horoucích pekel. Ale bohužel zatím nic takového není.

Každý nový jazyk, Rust nevyjímaje, si kasá nohavice, jak převálcuje C/C++. Jenomže pouze z hlediska teoretického použití, nikoli praktického. Pak padají nesmyslné otázky "proč jazyk X nepřeválcoval C/C++?", aniž by tazatel vzal v úvahu, že jazyku teče mléko po bradě, nemá standard, neustále se předělává, atd. atd. atd.

[Sid]

ja sa tu nebudem pustat do flamu myslim, ze podobne nazory kopirujute do kazdej diskuzie a x ludi vam rozumne argumentovalo. Navyse casto tu podsuvate cosi co nikto netvrdi a na tom zalozite svoje uvahy.

[Miloslav Ponkrác]

Mám vás brát vážně? To nejde.

"Kopírujete do každé diskuse" = to znamená, že jsem si dovolit napsat do druhé diskuse o Rustu. Vy nejste normální.

Možná by bylo dobré, pokud nemáte nic k tématu, kdybyste prostě nic nepsal.

[Petr]

Už nejméně do páté.

[Miloslav Ponkrác]

Takže zase nic k tématu. Další, už třetí trol v řadě. To se nám to vylíhlo...

[ʚĭɞ 🍉]

Děkujeme za názor a tady máte klíčenku.

[vlk]

Prave ze naopak C je uz priliz zastaraly a C++ z neho robi nieco ako by to malo vyzerat, je pravda ze k svojemu idealu este c++ ma daleko (a mnohe veci asi nikdy nebudu idealne), ale je to ovela lepsie nez samotne C.

ad Rust: neprogramoval som v tom a nepoznam jeho syntax, ale z toho co som videl (ano len zbezne videl) nepride mi to uplne intiutivny jazyk, su tam veci ktore bez nejakeho manualu ani nemozem tusit co znamenaju a to je podla mna istykamen urazu rustu. osobne by som prijal rad nejaku alternativu c-cka v ktorej mozem tvorit kod pre mikrokontrolery. zatial ako najlepsia alternativa mi pride C++.

[jdsulin2]

Vyhodu Rustu ti ilustruji na nasledujicim prikladu:

Mam knihovnu, ktera se stara o vytvareni Geometrii, a jedna ze trid je Point. Tu vytvoris v C++ v nejake Factory nebo v C napriklad Funkce CreatePoint(), oboji to vrati pointer (v C++ idealne shared pointer, ten by to resil, ale to pak zase musis mit shared pointery vsude a beda jak to nekdo pouzije jinak). Na konci celeho programu budes mit funkci FreePoint. Zatim vsechno v pohode, ale pak muzes mit tridu GeometryCollection, ktera ma stejne CreateGeometryCollection a FreeGeometryCollection funkce jako Point, navic ma dalsi metodu AddPoint(Point* point), ktera prida bod. Jenze pri uvolnovani pomoci FreeGeometryCollection ted vubec nevis, kdo vlastne ten Point uvnitr vlastni, mam ho uvolnit ja pomoci FreePoint nebo uz to za me udela funkce FreeGeometryCollection? A tim to nekonci - ten Point uvnitr je ten samy nebo jeho kopie ? Co kdyz zavolam funkci Point::setX() az za pridanim bodu ? Zmeni se mi i bod v GeometryCollection nebo ne ? Tyto veci musi samozrejme ten, kdo knihovnu vytvori zdokumentovat. Rust ma ale tu vyhodu, ze toto nemusis resit - uvolnovani pameti neresis a to, kdo objekt vlastni je explicitne dane. A to vsechno narozdil od spousty jazyku resi Rust staticky pri kompilaci, takze netrpi rychlost.

Pozn: samozrejme v C++ to muzes resit tak, ze vsechno bude vracet shared pointery a ty se budou uvolnovat samy, ale muze se najit misto, kde nekdo pouzije metodu shared_ptr::get() - napriklad v casti programu, ktery jeste nebyl portovany a vetsinou to fungovat bude, ale jistotu nemas.

A to nejsem moc velky fanousek Rustu :)

[xkucf03]

Jak už jsem psal jinde, s tím standardem souhlasím. Když ale odhlédneme od této vady – jaky bys Rust jinak hodnotil?

[Sid1]

Podla mna standard ako taky nebude problem ale popisat presne ako sa vykonat kontrola platnosti bude asi celkom problem. Specialne pri tom co volaju non lexical lifetime. Co pokial sledujem je stale riesene a cakaju na zaclenenie potencionalne lepsej varianty solvera.

[kralyk z abclinuxu]

Podla mna standard ako taky nebude problem ale popisat presne ako sa vykonat kontrola platnosti bude asi celkom problem. Specialne pri tom co volaju non lexical lifetime. Co pokial sledujem je stale riesene a cakaju na zaclenenie potencionalne lepsej varianty solvera.

NLL je začleněn ve stabilním Rustu už nějakou dobu. Co se týče formálního popisu, pro "starý" Rust (před NLL) existuje např. toto. Pro post-NLL borrow checker AFAIK formalizace není, ale nějaký lidi na tom AFAIK pracujou...

[Sid]

Ono tych implementacii je viac. To co sa dostalo zatial bude podla mna nahradene casom inou implementaciou ked ju dostatocne odladia. vid blog http://smallcultfollowing.com/babysteps/

[Miloslav Ponkrác]

Abych řekl pravdu, mně se velká řada myšlenek Rustu a směřování velice líbí.

Na druhé straně je na něm vidět, že není dovařený - a že drobné věci ještě šolíchá. Tak trochu čekám, jak některé vlastnosti zakončí.

Pokud to dobře zakončí, může to být velice dobrý jazyk. Dokáži si představit, že ho spousta lidí musí milovat.

Má příjemnou syntaxi, na rozdíl od C++ nezáludnou a nenutící člověka trikovat a hrát si na luštitele šifer. Líbí se mi ten koncept, kdy kompilátor ví trochu více a umí udržet určitou bezpečnost.

Nelíbí se mi způsob řešení chyb.

Nelíbí se mi stringy jako UTF-8.

Líbí se mi snaha jazyk udržet se lehkotonážní, nepotřebující rozsáhlé runtime knihovny, a myslím, že je to skvělá idea.

Trochu mi tam chybí konzistence logiky jazyka. Někdy mi přijde, že každou featuru jazyka navrhoval někdo jiný s trochu jiným záměrem. Právě v tom by velice mohl pomoci psaný standard jazyka.

Zmatek a nedostatečná dokumentace kolem Rustu. Takže je možné, že jsem sem tam něco pochopit ne úplně správně. I na webu Rustu jsou protiřečící si informace, někdy i informace z nějakých starších verzí.

Můj závěr zatím je, že Rust může být, podle dalšího vývoje a ustálení, buď naprosto geniální programovací jazyk, a nebo ho mohou zazdít.

[jdsulin2]

U tech stringu bych byl opatrny, v C je to docela problem uz jenom proto, ze zadny string nema (coz muze byt i vyhoda). Takze takovy UTF-8 string muze byt ruzne dlouhy v pameti pri stejnem poctu znaku, jak pak mas alokovat pamet ? Idealni je samozrejme pouzit uz nejakou existujici knihovnu, ale kdyz mas vice knihoven dohromady, co maji spolupracovat a kazda ma jinou predstavu o tom, jaka je ta spravna trida / struktura String, tak se zblaznis. Nove standardy to uz resi, ale ne kazdy to pouziva a jede si tu svoji definici tridy String - coz chapu, ne kazdy pouziva nejnovejsi kompiler a standard.

[Josef Kufner]

Zrovna UTF-8 je v paměti úplně v pohodě, protože to je pořád nulovým bytem ukončená posloupnost bytů. Potíže jsou jen při vykreslování na terminál, neboť není úplně jasné, kolik viditelných znaků v kolika bytech máš. A pak ještě při zadávání pevě daného počtu písmenek, kdy si nemůžeš být jistý, kolik bytů ty písmenka zaberou. Avšak reálně taková situace moc nenastává, neboť vstupy od uzivatele jsou v podstatě vždy řetězce proměnlivé délky, takže to není potřeba explicitně řešit. Případně uděláš vstupní buffer 4× větší než by byl pro ASCII vstup a bude to v pohodě (délku zadaného vstupu samozřejmě musíš řešit tak jako tak).

[jdsulin2]

Je pravda, ze s tou pameti to zase takovy problem neni - zvlast v C++, kde to trida string zvladne. Ale problem nastava jakmile nejaka knihovna pouziva UTF-8, jina zase local8bit, dalsi UTF-16 a system oboji (napr. ve WINAPI mas vsechny funkce zakoncene bud A nebo W a s tim, ze A neni ascii, ale kodovani systemu (napr. Windows-1250) - a ted se v tom vyznej). Nevyhodou je take to size != delka textu, funkce pro praci s textem nemusi fungovat (tolower) nebo jednoduchy priklad vraceni znaku na pozici n, atd... Prace s textem by samozrejme nemusela byt povinna - tak jako kazdy C++ prekladac nema implementovany napr. vyjimky, ale kdyby to bylo primo soucasti jazyku, tak bychom tady nemeli tolik ruznych implementaci.

[kralyk z abclinuxu]

+1

Obecně mi přijde dost podivná ta situace, že i vysokoúrovňové jazyky jako JavaScript nebo Python, příp. také Java, Go atd. mají stringové typy, které nezaručují korektnost a poskytují funkce, které snadno validní string rozbijou. Smysl stringového typu v těchto jazycích mi přijde trochu pochybný, když to ve výsledku stejně je jenom pole bajtů nebo 16-bitových čísel, které mohou a nemusí být validní unicode string...

[Josef Kufner]

Že Windows API je kopa hnoje není nic nového. A samozřejmě je na práci s UTF-8 textem potřeba používat funkce, které UTF-8 umí.

Vracení znaku na pozici je v UTF-8 obtížné a proto se občas používají ty "wide" kódování, které ale zas nejsou zpětně kompatibilní s ASCII. Na druhou stranu, je to operace, která není zas tak častá, většinou se buď jde po znacích tak jako tak a někde se to řízne, nebo tu pozici můžeš reprezentovat bytovým offsetem, neboť jsi si ji našel nějak jinak než jako N-té písmenko.

[kralyk z abclinuxu]

C začalo na neorané půdě, zavedlo si své standardy a své způsoby, jak to vyhovuje jemu.

lol. Algol, Fortran, BCPL, ...

[xkucf03]

V kterém z nich bys psal operační systém?

[kralyk z abclinuxu]

Ani jeden z nich neumim, takže nevim.

[Martin Mareš]

Já si v žádném, ale v BCPL byl napsaný kus AmigaOS (konkrétně části okolo filesystemu). Kdysi jsem dlouho zíral, proč má část OS všechny pointery vydělené čtyřmi :)

[Radovan]

V kterémkoliv. Ale protože zrovna ve FORTRANu je to neskutečný ojeb, vznikl C.

[Pev]

Zajímavé, Rust má dependency na Python 2.7 :)

https://github.com/rust-lang/rust#building-on-nix

Aniž bych sám byl vyhraněný proti Rustu, očividně nepodporuje starší architektury (což je dočasný problém, než tyto architektury definitivně umřou)

https://lwn.net/Articles/771355/

[Kate]

Toe současně výhoda i nevýhoda toho, že je kompiler postavený nad LLVM. Teď prý přibyl backend pro xtensa (esp8266 a esp32), už se těším až na nich zkusím bare metal Rust :)

[adolf kernel]

aj tak je najlepsi systemovy programovaci jazyk turbo pascal 7.0