Vyšel Rust 1.57

Ano, aby porovnání dávalo smysl, je potřeba překládat kód, který dělá to samé. Ale to není nepřekonatelný problém. Pokud budu porovnávat více jazyků, stejně v nich budu muset napsat kód, který dělá to samé – a pak budu porovnávat dobu překladu, paměťovou náročnost překladu, efektivitu přeloženého programu (jak z hlediska výpočetního výkonu tak z hlediska paměti), velikost přeloženého programu, snadnost programování, předcházení chybám… Změřit dobu překladu je z toho skoro to nejjednodušší.

Počítat můžete oba buildy, důležitější je pochopitelně devel build. Porovnávat to budu s jakýmkoli jazykem, který zvažuju jako alternativu – s C, C++, C#, Javou, Go, Kotlinem… Můžu to porovnávat i s interpretovanými jazyky, když na to přijde.

A hlavně - kdy už je "pomalejší překladač" pomalý a kdy je ještě v pohodě?
Myslím, že ve zprávičce to má ten význam, že je viditelně pomalejší, než jiné obdobné jazyky. Rust bych srovnával asi hlavně s C a C++, protože to jsou jeho nejbližší konkurenti.

> Ano, aby porovnání dávalo smysl, je potřeba překládat kód, který dělá to samé.

Pokud se nesoustředíš na nějaké triviální algoritmy, je to skoro nemožné. Když vyvíjíš nějaký produkt, můžeš dojít ke stejné funkčnosti mnoha různými způsoby.

> Změřit dobu překladu je z toho skoro to nejjednodušší.

Ano, je to úplně jednoduché, když to uděláš blbě a je to skoro úplně k ničemu, když se budeš snažit hodnotit "snadnost programování" a "předcházení chybám", protože tam ta měřitelnost je iluzorní. Můžeš se spolehnout na komplexní zkušenost nějakého týmu, který úspěšně změnil jazyk/technologii, ale tam už o nějaké objektivní měřitelnosti nemůže být řeč vůbec.

> Rust bych srovnával asi hlavně s C a C++, protože to jsou jeho nejbližší konkurenti.

Srovnávat ho můžeš s čím chceš, klidně s Haskellem nebo Pythonem, ale největší smysl má srovnání s C++, protože Rust se jím inspiroval hodně a má podobné cíle (zero cost abstractions apod.). Rust nemá moc smysl srovnávat s C, to bych spíš sáhnul po něčem jako Zig.

Myslím, že je dost nepravděpodobné, že by překladač překládal pomalu implementace triviálních algoritmů a větší projekty pak překládal (relativně) výrazně rychleji. Nebo naopak. Takže to srovnání na implementaci triviálních algoritmů se dá extrapolovat.

Nevím, proč bych měl rychlost překladu měřit blbě. Jak se má správně měřit rychlost vykonání nějakého programu je známo. Většinou stačí pustit program se stejným vstupem opakovaně, aby se porovnávala doba běhu, když se vše čte z cache a nebyla tam penalizace čtení dat z disku.

> Myslím, že je dost nepravděpodobné, že by překladač překládal pomalu implementace triviálních algoritmů a větší projekty pak překládal (relativně) výrazně rychleji. Nebo naopak. Takže to srovnání na implementaci triviálních algoritmů se dá extrapolovat.

Nejde ani tak o "větší projekty", nýbrž o složitější abstrakce (generické typy, makra...) apod. Znovu se vracím k nesmyslnosti srovnání kompilace jazyků typu C a třeba Rustu.

> Nevím, proč bych měl rychlost překladu měřit blbě.

Blbě znamená neužitečně (byť klidně přesně a můžeš se poplácat po zádech, jak jsi na to vyzrál). To znamená v kontextu reálného projektu změřit, že pokaždé znovu čekám na build více než (třeba) 5 sekund a je to pro mě z těchto konkrétních důvodů neakceptovatelně.

To srovnání dává smysl. Doba překladu zdržuje vývojáře, takže rychlejší překlad je lepší. Nebo-li opačně, pomalejší překlad musí být vyvážen jinými benefity.

To je lepší, ale pořád to ještě není ono. Papírové parametry jsou fajn, ale existuje něco jako mezní užitek. Je otázka, kde ta "pomalost" ještě vadí a jak moc. Nepotřebuješ dělat hřebíky z nástrojové oceli a nepotřebuješ drahý závodní vůz, abys dojel pohodlně z Prahy do Brna.

4. 12. 2021, 11:04 editováno autorem komentáře

Za prvé, pokud je něco pomalé, je to objektivně pomalé i tehdy, i když mi to subjektivně nevadí. Za druhé, abych mohl zodpovědně říct, zda mi pomalost vadí nebo nevadí nebo jak moc mi vadí, musím ji nejdřív umět změřit.

> Za prvé, pokud je něco pomalé, je to objektivně pomalé i tehdy, i když mi to subjektivně nevadí.

To je zatím nejvtipnější, co jsi napsal. "Pomalý" je subjektivní pojem a ne objektivní.

> Za druhé, abych mohl zodpovědně říct, zda mi pomalost vadí nebo nevadí nebo jak moc mi vadí, musím ji nejdřív umět změřit.

Zde se shodneme. Změř to, ale v reálné praxi. Pak se můžeme bavit o tom, proč to vadí a co se s tím dá dělat. Rust má dost nevýhod, ale bavme se o nich inženýrsky, prakticky.

Pokud bude překlad C++ kódu trvat 20 sekund a stejný kód v Rustu se bude překládat 50 sekund, je ten překlad Rustu objektivně pomalejší než překlad C++. Subjektivní je to, zda mi to vadí nebo nevadí.

Bude pomalejší, to je zcela objektivní. Slovo pomalý obsahuje hodnocení, tedy je subjektivní, respektive podléhá nutnosti domluvit se, kde je ta hranice. Tomuhle rozumíš, ne?

Myslím, že jsem to v předchozích komentářích napsal dostatečně srozumitelně. Nemám, co bych k nim dodal.

Jasně, že nemáš.

No ale teď konkrétně - máme nějaký ne úplně malý a ne úplně velký program v Rustu (třeba ripgrep). Jak dlouhá kompilace je OK a kdy začíná být pomalá?

O to vůbec nejde, jen tu byl konstatován fakt, že překlad Rustu je pomalejší než překlad C++ (a jiných srovnatelných jazyků). Pokud je pomalý překlad pro někoho překážkou, nejspíš nesáhne po Rustu ani C++. Jinak se rozhodne podle jiných kritérií. Jasné jak facka. Jiní výše to objasnili dostatečně.

No tak jinak. Představ si, že jsi člověk, který se porozhlíží po světě, umí trochu (nebo víc) programovat v nějakém jazyce, třeba v Javě nebo Pascalu nebo Ruby apod. Chodí na Root, přečte si Tvoji zprávičku a čte tam, že překladač Rustu je pomalý. Slabší povahy to může až vyděsit, protože "pomalý" může znamenat cokoli od "pomalejší než Turbo Pascal" po "prakticky nepoužitelný". A já si vzpomínám, že třeba překlad Scaly byl někdy pomalý tak, že se člověk na to chtěl vykašlat. Takové zážitky jsem s Rustem nikdy neměl.

Já úplně chápu, že s Jirsákem považujete "pomalý" a "pomalejší" skoro za synonyma a dokážu si mezi řádky tyhle vaše myšlenkové pochody zhruba představit, to mi nikdo nemusí "objasňovat". Ale holt si myslím, že podobné snahy o přidanou hodnotu můžou úplně zbytečně čtenáře odradit a to by přece byla škoda.

Škoda by to byla, jako i u jiných jazyků. Každý má výhody a nevýhody, je dobré je alespoň stručně zmiňovat. Koho nějaký jazyk vážně zajímá, beztak si najde podrobnější informace.

Ink: Pokud někoho vyděsí, že se dočte, že Rust je pomalý, pak ho asi musí děsit kdejaká hloupost. Zprávička nebyla primárně o rychlosti Rustu, aby tam byla nějaká měření.

Pochopil bych, kdybyste přišels nějakými čísly ukazujícími, že překladač Rustu je srovnatelně rychlý, jako třeba MSVC. Zatím mi to ale připadá, že si myslíte, že rychlost překladu Rustu má být tabu a všemi možnými i nemožnými prostředky se snažíte ostatní přesvědčit, že nemá smysl se o tom bavit.

Zase ty Tvoje demagogické šrouby, Jirsáku. Celou dobu jsem chtěl, aby někdo řekl, co je u někoho z vás pomalé a co rychlé. Až bude rustc rychlejší než MSVC, vydáš nějaký certifikát? Já jsem si, na rozdíl zcela jistě od Tebe, třeba ten ripgrep dnes zkoušel komplet zkompilovat a včetně závislostí to bylo IMO rychlé dost. Tvrzení, že je pomalý, by měl teda prokázat a zdůvodnit ten, kdo s ním přišel.

Já vydám klidně certifikát, až bude překladač Rustu rychlejší než překladač Go. Přinejmenším v kontejnerech :)

> Já vydám klidně certifikát, až bude překladač Rustu rychlejší než překladač Go. Přinejmenším v kontejnerech :)

Konečně ses vymáčknul, co jsi myslel - s čím jsi to implicitně srovnával. Jinými slovy, co je ten příslovečný slon v místnosti. ;)

Když srovnám Rust s Go, jsou tam z mého pohledu závažnější rozdíly, než je rychlost překladu. Na jednu stranu máš vývojáře, kteří se Rust nikdy nenaučí nebo ani nechtějí a na druhé lidi, kteří se Go nedotknou ani klackem nebo jen s krajním odporem.

Zajímavé je i srovnání dostupných knihoven. Živelný vývoj Rustu tady někdo zmiňoval, překážkou může být i dost velká závislost na Internetu.

Co se mi na Rustu líbí je, že všechny tyto věci někoho trápí a aktivně se řeší. Třeba vedle toho gcc backendu existovala snaha udělat výrazně rychlejší devel build do Craneliftu, ale dělal to myslím jeden člověk a to, že se to zatím nedostalo k širšímu využití, může znamenat, že s tou rychlostí překladu vesměs rusťáci dokážou bez větších problémů žít.

Pokud někdo o nějakém jazyce nebo konceptu řekne, že by se ho nedotknul ani klackem, že v něm vzbuzuje odpor, že je to odpad apod., je akorát tak vypatlaný idiot. A je úplně jedno, jestli jde o Javu, Cobol, Lisp, PHP, APL, OOP, s-výrazy, ORM...

> Pokud někdo o nějakém jazyce nebo konceptu řekne, že by se ho nedotknul ani klackem, že v něm vzbuzuje odpor, že je to odpad apod., je akorát tak vypatlaný idiot. A je úplně jedno, jestli jde o Javu, Cobol, Lisp, PHP, APL, OOP, s-výrazy, ORM...

No tak to neřekne (aby o něm Calculon neřekl, že je ...) a prostě to nepoužije, protože mu to nestojí za to úsilí a nervy. Koneckonců, proto vznikají nové jazyky, že asi všichni sice chtějí psát v Cobolu a PHP, ale jen tak z plezíru a přebytku volného času si přidají něco dalšího.

5. 12. 2021, 11:57 editováno autorem komentáře

U překladače je rychlé a pomalé subjektivní pocit. Pomalé je to tehdy, když má vývojář pocit, že na každé spuštění programu musí čekat a že ho to brzdí v práci. Ve srovnání s Go je překladač Rustu v tomto smyslu bezesporu pomalý; je to i názor samotných tvůrců a vývojářů rustu, protože se snaží to vylepšit. Tak okamžitý a bezbolestný, jako Go, Rust nejspíš nikdy nebude, ale být znatelně rychlejší, než clang komplikující C++ je dosažitelný cíl.

On se hlavně překladač Go s příchodem typových parametrů a množin zpomalí, takže ten rozdíl brzy nebude tak ostudný. S tím C++ uvidíme, to nijak odhadnout nejde.

Trošku to Go zpomalí, ale ne zas tak moc. Samotná monomorfizace generických funkcí tolik času nezabírá, většinou je instanciací stejně velmi málo a často je v daném projektu jenom jedna. U Rustu většinu času zabírají makra, složitý typový systém a samozřejmě borrow checker.

To není tak úplně správně. Je to metodická otázka. Musel byste ještě měřit ku stejně kvalitativnímu výsledku.
A nebo uplatnit to tvrzení o rychlosti pouze na vybranné, porovnatelné úseky.
Je to správně. Když chci měřit rychlost překladače, měřím rychlost překladače. Když chci měřit efektivitu výsledného kódu, měřím efektivitu výsledného kódu. Když chci porovnávat snadnost vývoje nebo sklon k chybování, zjišťuju snadnost výboje nebo sklon k chybování. Při výběru jazyka pak pravděpodobně budu brát v úvahu víc kritérií, ale to neznamená, že při měření jednoho kritéria do toho mám motat jiné kritérium.

Samozřejmě, když chcete měřit rychlost atleta na 100 metrů, co na tom jestli jeden běží sprint a druhý přes překážky nebo štafetu, dráha je 100 metrů ... sice jste roztomile nebral v úvahu žádné další kritérium, jenže pak je výrok "pomalejší" naprosto k ničemu.
Odpověď jsem pro vás napsal dopředu, najdete ji zde: https://www.root.cz/zpravicky/vysel-rust-1-57/1082326/

Jestli to tvoje “bavme se inženýrsky, prakticky” znamená říkat o jiných jazycích, které Rustu v některých oblastech úspěšně konkurují, že jsou odporné a odpad, tak to asi nemá cenu.

> Jestli to tvoje “bavme se inženýrsky, prakticky” znamená říkat o jiných jazycích, které Rustu v některých oblastech úspěšně konkurují, že jsou odporné a odpad, tak to asi nemá cenu.

Jenže já jsem to nenapsal ani tady a ani nikdy. Mně se třeba Go kdovíjak nelíbí a psát v něm nechci (ale klidně budu, když nebude jiná možnost, zas tak moc mi nevadí), nicméně respektuju, že někomu přijde fajn a používá ho. Ty si to bereš osobně, jako kdybych Ti pomluvil bráchu. ;) Zrovna tak jakýkoli jiný jazyk - proč by mě mělo vzrušovat, že někdo chce používat APL nebo LISP? Maximálně se zajímám, co by ten jazyk mohl dát navíc. A zrovna tak respektuju, že někdo za živý svět nechce dělat v Rustu nebo Go nebo PHP a nebudu o něm tvrdit, že je idiot.

martinpoljak: To, že na to existují subjektivní pohledy, neznamená, že se to nedá objektivně měřit. A když se to dá objektivně měřit, může být souhrn takových měření zmíněný v charakteristice překladače třeba v novinové zprávě.

Jirsáku, až bude ve zprávičce nějaký "souhrn objektivních měření", tak se ozvi. Já ho tam nevidím. Zase manipuluješ.

Ink: Je tam napsáno „pomalý překladač“. Kdyby to tam nebylo, nerozpoutal jste tu tuhle diskusi. Nejsou tam tedy vypsané hodnoty z konkrétních měření, je tam jen souhrn slovem „pomalý“. Pokud vám z měření vychází něco jiného, je jediná možnost – že sem ta čísla dáte. Protože bez čísel se tu můžete dohadovat donekonečna.

Jirsáku, už jsme si vysvětlili rozdíl mezi prvním a druhým stupněm přídavného jména "pomalý". Můžeme ale oslovit Ústav pro jazyk český, pokud to nestačilo.

Jirsáku, už jsme si vysvětlili rozdíl mezi prvním a druhým stupněm přídavného jména "pomalý".
Co vy jste si vysvětlil je mi jedno. První stupeň přídavných jmen se běžně používá pro označení, že má něco danou vlastnost víc, než jiné věci. Např. lidé běžně říkají, že tráva je zelená – jenom Ink vyskočí jak čertíček z krabičky, že zelenost je subjektivní pojem a že je možné objektivně říci jenom to, že tráva je zelenější než například dřevo.

Žádná čísla evidentně nemáte, takže tu jenom mlátíte prázdnou slámu.

Až po Tobě, Jirsáku. Kdybys uznal, že "pomalý" je subjektivní pojem, mohli jsme to uzavřít. Jenže Ty nikdy chybu neuznáš, do každé diskuse přijdeš vykřikovat svoje "moudra" a musíš mít vždycky poslední slovo. Tak teď už si piš, co chceš, na rozdíl od Calculona, který očividně ví, proč napsal, co napsal, je mi Tvoje prázdná sofistika ukradená.

6. 12. 2021, 10:29 editováno autorem komentáře

Myslím, že teď je ten správný moment přestat se hádat. Změna tématu — jde nějak přeskočit aktualizaci cratů při překladu (jinak než vendoringem)? V Dockeru to trvá věčnost.

> Myslím, že teď je ten správný moment přestat se hádat.

Souhlas.

> Jde nějak přeskočit aktualizaci cratů při překladu (jinak než vendoringem)? V Dockeru to trvá věčnost.

Mělo by fungovat

cargo +nightly build -Z no-index-update

Případně si můžeš udělat vlastní vlastní crate registry, ne?

Ještě tak ujasnit si rozdíl mezi prvním a druhým stupněm ZŠ ;) BTW na ÚJČ klidně zavolej, někdy v 90. letech tam byla sekretářkou Slovenka a vždy s gustem začínala hovor slovy “ÚJČ, čo si želáte?” :)

Leckterá Slovenka umí česky líp než spousta Čechů, tak proč ne...

“Leckterá Slovenka umí česky líp než spousta Čechů”

A co teprve slovensky :)

I když jak která, já mám příbuzné na východě Slovenska a těm jinde na Slovensku nerozumí ani slovo.

No tak ten úplný východ, to už jsou napůl Rusíni. Ale jazykové rozdíly mezi Záhoráky, lidmi v Bratislavě nebo v Senci oproti obyvatelům na středním Slovensku je taky dost velký. Nebo když si člověk přečte starší text třeba v muzeu v Banské Štiavnici, to je taky lahůdka.

Ty rozdíly jsou nicotné oproti jihu Slovenska :)

Nem tudom...

Každopádne Záhoráci boli u nás v korporáte jediní, ktorí tou svojou hatlaninou (podivne skomolená zmes češtiny a slovenčiny) rozprávali nielen medzi sebou...

"dojel sem na koli" = "prišiel som na bicykli"

> "dojel sem na koli" = "prišiel som na bicykli"

To je prakticky čistý východomoravský dialekt - akorát by tam bylo "na kole". Kdybys přejel hranici z Holíče do Hodonína, rozdílu si skoro ani nevšimneš.

Já jen, že nejsem velký příznivec maker, ale makra asi jak byla prezentována v C, tedy jako něco, co pracuje s textem bez znalosti kontextu daného jazyka.

A to je asi nejvíc evil na makrech v jazycích C a C++ (speciálně tam).

Nevím, jak je to s makry v Rustu, já jen že při slově makro se mi otevírá nůž v kapse :-)

Preprocesor v C a jeho "makra" jsou trochu jiná liga. Ale samozřejmě rozumím, taky jsem napsal dost řádků v C i C++.

Při psaní maker v Rustu se přímo manipuluje syntax tree jazyka. Není to jen tupý generátor textu. Navíc jsou makra psaná opět v Rustu, není pro to potřeba žádná speciální syntax jako v C.

Pro začínajícího programátora může být psaní maker (hlavně procedurálních maker) poměrně strašidelné, ale výhody v DRY které to někdy poskytuje jsou neskutečné. Osobně mám třeba napsanou knihovnu s makry, které z jednoduše abstrahované specifikace celkem složitého protokolu s desítkami objektů vygeneruje veškerý kód rozsáhlé api knihovny, všechny settery, testy, dokumentaci… Psát to ručně, zblázním se z toho :)

Dají se psát metamakra (makra měnící AST kódu derive maker)?