Těžké OOP problémy

[Idris]

Koukám právě narvali async/await do Rustu. To je fakt mor.

To je smutný. Zrovna od Rustu bych čekal, že se omezí na CSP. Třeba vtáhne Actix do standardní knihovny nebo tak něco.

Rust pořádně neznám, takže neumím posoudit implementaci, ale pokud by to ve finále vedlo ke stejnýmu zmatku jako kdysi v Pythonu - pro každou knihovnu bude x verzí, jedna sync, jedna nad Actix, jedna nad Tokio a pak ještě jedna s async/await, přičemž každá jinak zabugovaná, tak by to byl teda fakt smutný příběh jinak moc pěkného jazyka...

Shit happens. Taky bych býval čekal, že to nezasviní blbostma.

[Reklama]

[Ink]

Koukám právě narvali async/await do Rustu. To je fakt mor.

To je smutný. Zrovna od Rustu bych čekal, že se omezí na CSP. Třeba vtáhne Actix do standardní knihovny nebo tak něco.

Rust pořádně neznám, takže neumím posoudit implementaci, ale pokud by to ve finále vedlo ke stejnýmu zmatku jako kdysi v Pythonu - pro každou knihovnu bude x verzí, jedna sync, jedna nad Actix, jedna nad Tokio a pak ještě jedna s async/await, přičemž každá jinak zabugovaná, tak by to byl teda fakt smutný příběh jinak moc pěkného jazyka...

Shit happens. Taky bych býval čekal, že to nezasviní blbostma.

To si fakt, projednou, nedokážete připustit, že třeba někdo ví víc než Vy a má dobrý důvod do Rustu ten async/await přidat?

Opravdu jste studovali, co všechno s tím vyřeší, co se tím zjednoduší, jestli se opravdu budou muset dělat (v Rustu, neřeším jiné jazyky) všechny knihovny dvakrát, jestli to opravdu musí přidávat bugy, nebo jenom tak bručíte, protože jste něco holt nečekali a nejde Vám to pod fousy?

[Mirek Prýmek]

V tom je ten vtip - Rust není magický jazyk, nedělá žádné legrácky typu GC a automatickou paralelizaci.

To je právě docela škoda, protože ta asynchronicita je pak tak trochu jenom šidítko... V praxi to má oproti sekvenčnímu kódu přínos velký, ale menší než by na dnešních multiprocesorových strojích mít mohlo. Model založený na CSP, který má Erlang (a do menší míry i Go) škáluje na multiprocesoru sám o sobě, bez potřeby jakékoliv magie a často fakt lineárně [1].

No a s tím sleepem a joinem je zrovna pár hodin starý dotaz a vysvětlení na Redditu: https://www.reddit.com/r/rust/comments/dtp6z7/what_can_i_actually_do_with_the_new_async_fn/

A je to tady! Tohle je bohužel úplně geniální ilustrace přesně toho, o čem jsem mluvil. Přesně tohle se mi stalo, když jsem poprvé zkoušel async v Pythonu: byv odchován systémy s oddělenými stacky, naběhl jsem si přesně stejně, protože mi vůbec nepřišlo na mysl, že v async/await světě tenhle červenomodrý[2] problém existuje - ze svého světa jsem ho vůbec neznal.

To si fakt, projednou, nedokážete připustit, že třeba někdo ví víc než Vy a má dobrý důvod do Rustu ten async/await přidat?

No, ehm, nalistuj si o dvě [EDIT: tři - [3]] stránky zpátky, kde jsem to explicitně připustil, takže to je dost bezpředmětné lamentování.

Dobrý důvod mít můžou. A já zas můžu mít subjektivní pocit, že to dělat neměli. Můžu se mýlit, to je samozřejmý. Ale ten dotaz výš mě utvrzuje v tom, že nejsem úplně mimo.

---

[1] http://www.dcs.gla.ac.uk/~trinder/papers/release-summary-arxiv-1.pdf - např. Figure 5
[2] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/
[3] https://forum.root.cz/index.php?topic=22043.msg320027#msg320027

[Idris]

Koukám právě narvali async/await do Rustu. To je fakt mor.

To je smutný. Zrovna od Rustu bych čekal, že se omezí na CSP. Třeba vtáhne Actix do standardní knihovny nebo tak něco.

Rust pořádně neznám, takže neumím posoudit implementaci, ale pokud by to ve finále vedlo ke stejnýmu zmatku jako kdysi v Pythonu - pro každou knihovnu bude x verzí, jedna sync, jedna nad Actix, jedna nad Tokio a pak ještě jedna s async/await, přičemž každá jinak zabugovaná, tak by to byl teda fakt smutný příběh jinak moc pěkného jazyka...

Shit happens. Taky bych býval čekal, že to nezasviní blbostma.

To si fakt, projednou, nedokážete připustit, že třeba někdo ví víc než Vy a má dobrý důvod do Rustu ten async/await přidat?

Opravdu jste studovali, co všechno s tím vyřeší, co se tím zjednoduší, jestli se opravdu budou muset dělat (v Rustu, neřeším jiné jazyky) všechny knihovny dvakrát, jestli to opravdu musí přidávat bugy, nebo jenom tak bručíte, protože jste něco holt nečekali a nejde Vám to pod fousy?

Viz Prýmek a CSP.

[Ink]

V tom je ten vtip - Rust není magický jazyk, nedělá žádné legrácky typu GC a automatickou paralelizaci.

To je právě docela škoda, protože ta asynchronicita je pak tak trochu jenom šidítko... V praxi to má oproti sekvenčnímu kódu přínos velký, ale menší než by na dnešních multiprocesorových strojích mít mohlo. Model založený na CSP, který má Erlang (a do menší míry i Go) škáluje na multiprocesoru sám o sobě, bez potřeby jakékoliv magie a často fakt lineárně [1].

No a s tím sleepem a joinem je zrovna pár hodin starý dotaz a vysvětlení na Redditu: https://www.reddit.com/r/rust/comments/dtp6z7/what_can_i_actually_do_with_the_new_async_fn/

A je to tady! Tohle je bohužel úplně geniální ilustrace přesně toho, o čem jsem mluvil. Přesně tohle se mi stalo, když jsem poprvé zkoušel async v Pythonu: byv odchován systémy s oddělenými stacky, naběhl jsem si přesně stejně, protože mi vůbec nepřišlo na mysl, že v async/await světě tenhle červenomodrý[2] problém existuje - ze svého světa jsem ho vůbec neznal.

No jenže Rust není Erlang ani Go, je to snaha přepsat C++ (nízkoúrovňový jazyk a jeho zero cost abstractions). Já jsem poměrně skálopevně přesvědčený, že autoři Rustu ty věci dělají tak dobře, jak je v jejich silách a vůbec si nemyslím, že by byli hloupí a nějaké zjevné lepší cesty k implementaci nějaké vlastnosti jim unikaly. Skoro mi přijde, že Ti je líto, že Rust je Rust a ne něco jiného a u Idrise, na kterého jsem reagoval hlavně, nevím na čem jsem, protože nic konkrétního nenapsal.

Rust není jazyk pro úplně každého a úplně na všechno, pokud se mi zrovna hodí něco, co on dobře umí, použiju ho a kde to dře, tam ho nepoužiju. A jelikož futures a async/await ve stabilním toolchainu odemykají cestu k použití aplikací a knihoven, které řeší zcela konkrétní problémy a to (podle všeho) docela slušně a dosud fungovaly jenom v unstable, budu šťastný jako blecha, protože mi to dává šanci se něco nového naučit a případně něco vytvořit. Good luck w/ Go/Erlang/whatever. A hezkou sobotu.

[Reklama]

[Mirek Prýmek]

No jenže Rust není Erlang ani Go, je to snaha přepsat C++ (nízkoúrovňový jazyk a jeho zero cost abstractions). Já jsem poměrně skálopevně přesvědčený, že autoři Rustu ty věci dělají tak dobře, jak je v jejich silách a vůbec si nemyslím, že by byli hloupí a nějaké zjevné lepší cesty k implementaci nějaké vlastnosti jim unikaly. Skoro mi přijde, že Ti je líto, že Rust je Rust a ne něco jiného

Vůbec ne, Rust se mi (nakolik ho teda neznám moc dobře) jeví jako ze všech jakž takž mainstream jazyků nejlepší. Vůbec neříkám, že jsou jeho autoři blbci, ani náhodou. Ale konkrétně u téhle věci prostě nechápu, proč šli touhle cestou. Že je Rust "přepis C++"? No a? To je Go taky a autoři zvolili ("rozvolněné") CSP.

Ty důvody, proč zvolili await, můžou být různé, klidně i netechnické - třeba to, že async/await prostě zná a chápe (ať už to znamená cokoli) víc lidí.

Nebo by důvod mohl být třeba ten, že async/await se asi dá implementovat tak, aby byl zaručeně korektní - protože má menší míru volnosti a tím i větší kontrolu nad tím, co se spustí kdy. U CSP (i toho "rozvolněného" ve stylu Go) si člověk musí víc lámat hlavu třeba s tím, v jakém okamžiku má kontexty přepínat. Rust moc neznám, tím míň nějaký jeho internals, takže třeba autoři došli k názoru, že se jim tohle prostě nechce řešit (nebo to dost dobře ani nejde). To nevím. Ale je mi to líto, že se vydali touhle cestou. Doteď totiž vybírali imho fakt nejlepší featury, často state of the art a tady imho vybrali featuru, která (imho) není ani nejlepší, má známé problémy, ani není state of the art.

[BoneFlute]

konkrétně u téhle věci prostě nechápu, proč šli touhle cestou.

Bylo by možné, mě by to moc zajímalo, nějak pěkně rozvést výhody a nevýhody await/async?

(Jako Haskellista nemám problém s Promise. Ale jako začínající C#pista, jsem se této syntax zatím úspěšně vyhejbal - ačkoliv věřím, že to nebude nic složitého.)

[Idris]

konkrétně u téhle věci prostě nechápu, proč šli touhle cestou.

Bylo by možné, mě by to moc zajímalo, nějak pěkně rozvést výhody a nevýhody await/async?

(Jako Haskellista nemám problém s Promise. Ale jako začínající C#pista, jsem se této syntax zatím úspěšně vyhejbal - ačkoliv věřím, že to nebude nic složitého.)

Nevýhoda: je to zbytečné, kooperativní scheduler se dá udělat i bez přidané nesmyslné syntaxe (nesmyslné, protože je virální, jeden await vyžaduje async až do kořene stromu volání).

[Mirek Prýmek]

protože je virální, jeden await vyžaduje async až do kořene stromu volání

Pro BoneFlute: K tomuhle fakt doporučuju ten článek https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/
- je trochu zbytečně dlouhej a jako haskellista poznáš, že vlastně jenom zbytečně zdlouhavě popisuje monády, ale problém vystihuje dobře. Await je prostě virální úplně stejně jako GPL nebo IO

Polopaticky řečeno, když se vrátím k tomu odkazu z redditu výš, pokud chceš použít async, potřebuješ nutně jakýsi "jiný" sleep, "před který se dá napsat await" - funkci, která pod kapotou vrací promise. U řešení s oddělenými stacky (tady o tom píšu jako o "CSP") tenhle problém neexistuje. Prostě ve vlastním "vlákně" (greenthreadu, procesu, ...) spustíš úplně normální "synchronní" sleep, jako bys to udělal u starýho dobrýho multithreadingu.

[Idris]

protože je virální, jeden await vyžaduje async až do kořene stromu volání

Pro BoneFlute: K tomuhle fakt doporučuju ten článek https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/
- je trochu zbytečně dlouhej a jako haskellista poznáš, že vlastně jenom zbytečně zdlouhavě popisuje monády, ale problém vystihuje dobře. Await je prostě virální úplně stejně jako GPL nebo IO

Polopaticky řečeno, když se vrátím k tomu odkazu z redditu výš, pokud chceš použít async, potřebuješ nutně jakýsi "jiný" sleep, "před který se dá napsat await" - funkci, která pod kapotou vrací promise. U řešení s oddělenými stacky (tady o tom píšu jako o "CSP") tenhle problém neexistuje. Prostě ve vlastním "vlákně" (greenthreadu, procesu, ...) spustíš úplně normální "synchronní" sleep, jako bys to udělal u starýho dobrýho multithreadingu.

Tak tomu ale neříkej "vlákno", tím to zmateš

[Mirek Prýmek]

Tak tomu ale neříkej "vlákno", tím to zmateš

Dobře, říkejme tomu "motouz"

[Idris]

Tak tomu ale neříkej "vlákno", tím to zmateš

Dobře, říkejme tomu "motouz"

Vážně, říkat korutinám vlákno (nebo špagát a jiná téměř synonyma) není dobrý nápad, kdo to nezná, představí si multithreading, přitom korutiny klidně můžou běžet v jednom vlákně (a taky často běží, na nějakém mini CPU pro IoT apod.). Odtud přesně plyne to zmatení okolo async/await, pak se div, že to BFL nechápe nebo chápe blbě.

[Mirek Prýmek]

Vážně, říkat korutinám vlákno (nebo špagát a jiná téměř synonyma) není dobrý nápad, kdo to nezná, představí si multithreading, přitom korutiny klidně můžou běžet v jednom vlákně (a taky často běží, na nějakém mini CPU pro IoT apod.). Odtud přesně plyne to zmatení okolo async/await, pak se div, že to BFL nechápe nebo chápe blbě.

Podle mě je tohle na tom právě to pěkný: programátorovi se to po všech stránkách jeví jako vlákno a měl by o tom i tak uvažovat, protože ta možnost, že to skutečně na různých vláknech poběží, tam je, resp. u dobrého systému je.

[Idris]

Vážně, říkat korutinám vlákno (nebo špagát a jiná téměř synonyma) není dobrý nápad, kdo to nezná, představí si multithreading, přitom korutiny klidně můžou běžet v jednom vlákně (a taky často běží, na nějakém mini CPU pro IoT apod.). Odtud přesně plyne to zmatení okolo async/await, pak se div, že to BFL nechápe nebo chápe blbě.

u dobrého systému je

JS

[Mirek Prýmek]

JS

Python, Ruby...