async/await v JS

[LadislavBohm]

Ano, jistě. Já jen píšu, že je zbytečné anotovat kód pomocí async/await (a používat Promise), protože překladač může generovat zcela stejný kód i bez nich.

Jenže ten generovaný kód při použití není identický výkonostně ani chováním jako ten, kdy používáte čistě Promise (JS) nebo Task (C#). V C# je tam několik důvodů navíc, proč to automaticky nejde a ani o to lidé nestojí. Navíc v netypovém JS docílit automatické anotace u funkcí by bylo dost problematické, to bych si dokázal představit ještě tak u Typescriptu.

[Reklama]

[Bacsa]

Ano, jistě. Já jen píšu, že je zbytečné anotovat kód pomocí async/await (a používat Promise), protože překladač může generovat zcela stejný kód i bez nich.

Jenže ten generovaný kód při použití není identický výkonostně ani chováním jako ten, kdy používáte čistě Promise (JS) nebo Task (C#). V C# je tam několik důvodů navíc, proč to automaticky nejde a ani o to lidé nestojí. Navíc v netypovém JS docílit automatické anotace u funkcí by bylo dost problematické, to bych si dokázal představit ještě tak u Typescriptu.

V Go je identický. Spíš mě napadá, používá se to v praxi k něčemu jinému než NIO a předávání zpráv?

[oss]

Pride mi dost vtipne porovnavat async/await z JS/C#/TS,... a gorutiny, kedze robia ine veci. To riesnie nie je ani pkne ani nijako specialne.

Hlavne pri automatickom generovani takeho kodu, nemozes explicitne pracovat s pepinanim kontextu.

A hlavne argumentovat Go - jazykom, ktory je na urovni Pascalu mi pride este viac smiesne.

[Bacsa]

Pride mi dost vtipne porovnavat async/await z JS/C#/TS,... a gorutiny

Tady nejde o gorutiny, ale o kooperativní multitasking a potažmo scheduler v runtime. Ty jsou stejné. Příště si nastuduj promisy, Go a NIO, než budeš mudrovat (resp. trollit).

[oss]

Kooperativní vícevláknovost je mnohem lépe vyřešena v Go, je plně transparentní a nemusí se zavádět async funkce. Vyžadovat psát async/await je zcela zbytečné, stejně jako používání Promise pro návratovou hodnotu. Jde o overengineering. Na druhou stranu to je o trochu lepší než callback hell.

asynchronnost bez explicitního await není kooperativní ani transparentní.

Po tomto vyroku by si si to mal  dostudovat ty.

[Reklama]

[JS guru]

Používáte to někdo? By mě zajímalo, proč okopírovali ten mizerný návrh korutin z C#.

Ano používám.

Protože v JavaScript běží pouze 1 vlákno najednou a tím pádem je nutné explicitně programátorovi a enginu sdělit, že teď může dojít ke spuštění jiného kódu.

Vzhledem k designu jazyka (jedno vlákno), nejsou potřeba žádné synchronizační primitivy. Ale protože jazyk obsahuje asynchronní funkce, je nutné jednoznačně určit, kde dojde k přerušení jedné funkce jinou asynchronní funkcí. A k tomu je dobrý await případně yield.

[JS guru]

Používáte to někdo? By mě zajímalo, proč okopírovali ten mizerný návrh korutin z C#.

Můžeš uvést příklad jazyka, kde je podle tebe lépe vyřešeno volání asynchronního kódu?

Kooperativní vícevláknovost je mnohem lépe vyřešena v Go, je plně transparentní a nemusí se zavádět async funkce. Vyžadovat psát async/await je zcela zbytečné, stejně jako používání Promise pro návratovou hodnotu. Jde o overengineering. Na druhou stranu to je o trochu lepší než callback hell.

Nevím co myslíte pojmem kooperativní vícevláknovosti. Znám jenom kooperativní multitasking (Windows 3.11)

Javascript nemá synchronizační primitiva - nepotřebuje je protože vše běží v jednom vlákně. Await (a yield) jsou jediné způsoby jak dát vědět, teď bude aktuální kód přerušen a jiný spuštěn - někdo mohl změnit globální proměnné.
Proto tyto klíčová slova jsou nezastupitelné a mnohdy mnohem lepší než používání callbacků. Například proto, že u callbacků není formálně zajištěno kolikrát bude zavolán. Tyto garance přicházejí až s Promise/A+ (a tam se to nenazývá callback)

Pro javascript to není overengineering. Je to způsob, jak dostat do kódu který nebyl designován pro vlákna "synchronní" zápis volání dlouho běžících operací a deklarace, že mezitím je možné dělat něco jiného. V go to není potřeba, protože je možné spustit mnoho vláken ale následně je potřeba používat zámky, channely a podobně.

[oss]

Takto promisa je "len" krajsi callback, ktory ostruje nejake stavy naviac a umoznuje rezatenie.
asnc await v JS je len syntakticky cukor a preklada sa to do stavoveho automatu, ktory zas vyuziva promisy, takze ziadna magia.

Ako priklad si skuste nejaky async /await kod prelozit Typescriptom do ES5.

[Bacsa]

Používáte to někdo? By mě zajímalo, proč okopírovali ten mizerný návrh korutin z C#.

Můžeš uvést příklad jazyka, kde je podle tebe lépe vyřešeno volání asynchronního kódu?

Kooperativní vícevláknovost je mnohem lépe vyřešena v Go, je plně transparentní a nemusí se zavádět async funkce. Vyžadovat psát async/await je zcela zbytečné, stejně jako používání Promise pro návratovou hodnotu. Jde o overengineering. Na druhou stranu to je o trochu lepší než callback hell.

Nevím co myslíte pojmem kooperativní vícevláknovosti.

Kooperativní přepínání kontextu. Prostě scheduler, ale na úrovni aplikace.

[Vlado]

Kurva to je zas téma plná odborných názorov... Jeden sa opýta nezmysel, ako keby to vedel urobiť lepšie, ďalší sa toho zasa chytia v snahe vyzerať múdro... Nikto nič neokopíroval. Pred async / await tu bol pekný, veľmi obľúbený pattern, a keďže dobre fungoval, aj mal logiku, no tak ho zahrnuli do štandardu. Že sú to na pozadí len promisy a generátor, to s tým nič nemá a nikto nič neokopíroval - už sa niečo obdobné dávno používalo... To budete rovnako mudrovať aj po zaradení pipe operátora ( |> )? Že prečo ho okopírovali zrovna z Haskellu? Vám to tu pekne jebe.

[Lol Phirae]

[Bacsa]

Kurva to je zas téma plná odborných názorov... Jeden sa opýta nezmysel, ako keby to vedel urobiť lepšie, ďalší sa toho zasa chytia v snahe vyzerať múdro... Nikto nič neokopíroval. Pred async / await tu bol pekný, veľmi obľúbený pattern, a keďže dobre fungoval, aj mal logiku, no tak ho zahrnuli do štandardu. Že sú to na pozadí len promisy a generátor, to s tým nič nemá a nikto nič neokopíroval - už sa niečo obdobné dávno používalo... To budete rovnako mudrovať aj po zaradení pipe operátora ( |> )? Že prečo ho okopírovali zrovna z Haskellu? Vám to tu pekne jebe.

Brouk Pytlík ze salaše opět promluvil 

[mmm]

Kurva to je zas téma plná odborných názorov... Jeden sa opýta nezmysel, ako keby to vedel urobiť lepšie, ďalší sa toho zasa chytia v snahe vyzerať múdro... Nikto nič neokopíroval. Pred async / await tu bol pekný, veľmi obľúbený pattern, a keďže dobre fungoval, aj mal logiku, no tak ho zahrnuli do štandardu. Že sú to na pozadí len promisy a generátor, to s tým nič nemá a nikto nič neokopíroval - už sa niečo obdobné dávno používalo... To budete rovnako mudrovať aj po zaradení pipe operátora ( |> )? Že prečo ho okopírovali zrovna z Haskellu? Vám to tu pekne jebe.

AFAIK generator based coroutines moc oblíbený pattern nebyl. Já jsem se snažil propagovat https://www.npmjs.com/package/co , ale většina kolegů dávala přednost obyčejnému řetězení promisů.

[mmm]

To budete rovnako mudrovať aj po zaradení pipe operátora ( |> )? Že prečo ho okopírovali zrovna z Haskellu? Vám to tu pekne jebe.

myslím, že v Haskellu nic takového není, každopádně v JS by to bylo super. Existuje babel plugin

https://github.com/SuperPaintman/babel-plugin-transform-pipeline

[Vlado]

Kurva to je zas téma plná odborných názorov... Jeden sa opýta nezmysel, ako keby to vedel urobiť lepšie, ďalší sa toho zasa chytia v snahe vyzerať múdro... Nikto nič neokopíroval. Pred async / await tu bol pekný, veľmi obľúbený pattern, a keďže dobre fungoval, aj mal logiku, no tak ho zahrnuli do štandardu. Že sú to na pozadí len promisy a generátor, to s tým nič nemá a nikto nič neokopíroval - už sa niečo obdobné dávno používalo... To budete rovnako mudrovať aj po zaradení pipe operátora ( |> )? Že prečo ho okopírovali zrovna z Haskellu? Vám to tu pekne jebe.

AFAIK generator based coroutines moc oblíbený pattern nebyl. Já jsem se snažil propagovat https://www.npmjs.com/package/co , ale většina kolegů dávala přednost obyčejnému řetězení promisů.

A dodnes dáva, málokto používa async / await s try / catch. Iní to však chceli, logiku to malo, pridali to. Hlavne nikto nič nekopíroval.