Používáte to někdo? By mě zajímalo, proč okopírovali ten mizerný návrh korutin z C#.
Ano, pouzivam to casto
Hodne to vidim u kodu, kdy se tahaj dalsi HTTP requesty vicemene jako syntactic sugar k Promise (je to citelnejsi nez then)
Handlovani rejectnuti promisy se pak resi pres try/catch
Citace od: ScriptKid kdy 19. 08. 2018, 00:43:32
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? Díky
Když jste u JS+async+await, tak bych se rád zeptal.
Taham data z DB, ale když se mi vrátí 0 řádků, měl bych jako neúspěch volat reject? Např. tady podle článku https://blog.tonysneed.com/2016/10/27/scalable-web-api-express-async-await/ jo, ale pak těžko rozeznam z chybový hlášky jestli je 0 výsledků nebo selhalo připojení k DB.
Podle mě by bylo lepší v případě 0 řádků volat resolve(null), jen v případě chyby DB reject(err) a vůbec nepoužívat try catch, protože v případě chyby připojení k DB chci shodit celou aplikaci. Stejně jako to dělam např. v PHP+Dibi.
Citace od: LadislavBohm kdy 19. 08. 2018, 03:49:39
Citace od: ScriptKid kdy 19. 08. 2018, 00:43:32
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.
Citace od: Neinformovaný kdy 19. 08. 2018, 13:48:07
Když jste u JS+async+await, tak bych se rád zeptal.
Taham data z DB, ale když se mi vrátí 0 řádků, měl bych jako neúspěch volat reject? Např. tady podle článku https://blog.tonysneed.com/2016/10/27/scalable-web-api-express-async-await/ jo, ale pak těžko rozeznam z chybový hlášky jestli je 0 výsledků nebo selhalo připojení k DB.
Podle mě by bylo lepší v případě 0 řádků volat resolve(null), jen v případě chyby DB reject(err) a vůbec nepoužívat try catch, protože v případě chyby připojení k DB chci shodit celou aplikaci. Stejně jako to dělam např. v PHP+Dibi.
Ten článek je nesmysl. Borec používá Promisy zcela zbytečně v aplikaci bez asynchronního IO. Přečtěte si dokumentaci od Mozilly.
Když používáte async/await, resolve a reject nepotřebujete, pokud nepoužíváte nějaké historické knihovny nepodporující promisy.
Citace od: Neinformovaný kdy 19. 08. 2018, 13:48:07
Když jste u JS+async+await, tak bych se rád zeptal.
Taham data z DB, ale když se mi vrátí 0 řádků, měl bych jako neúspěch volat reject? Např. tady podle článku https://blog.tonysneed.com/2016/10/27/scalable-web-api-express-async-await/ jo, ale pak těžko rozeznam z chybový hlášky jestli je 0 výsledků nebo selhalo připojení k DB.
Podle mě by bylo lepší v případě 0 řádků volat resolve(null), jen v případě chyby DB reject(err) a vůbec nepoužívat try catch, protože v případě chyby připojení k DB chci shodit celou aplikaci. Stejně jako to dělam např. v PHP+Dibi.
Lepší je resolve s null nebo [].
Citace od: Neinformovaný kdy 19. 08. 2018, 13:48:07
Když jste u JS+async+await, tak bych se rád zeptal.
Taham data z DB, ale když se mi vrátí 0 řádků, měl bych jako neúspěch volat reject? Např. tady podle článku https://blog.tonysneed.com/2016/10/27/scalable-web-api-express-async-await/ jo, ale pak těžko rozeznam z chybový hlášky jestli je 0 výsledků nebo selhalo připojení k DB.
Podle mě by bylo lepší v případě 0 řádků volat resolve(null), jen v případě chyby DB reject(err) a vůbec nepoužívat try catch, protože v případě chyby připojení k DB chci shodit celou aplikaci. Stejně jako to dělam např. v PHP+Dibi.
Když se ptáte na seznam, měl byste normálně vrátit prázdný seznam. Pokud se ptáte na jeden konkrétní záznam (dle primárního klíče), obecně byste měl vrátit null – ale pokud by ten záznam měl existovat (např. uživatel jde ze seznamu produktů, kde je produkt vypsaný, na detail produktu), dává smysl i vrátit chybu (reject nebo výjimku).
Citace od: Bacsa kdy 19. 08. 2018, 14:14:11
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í.
Citace od: mmm kdy 19. 08. 2018, 14:31:17
Citace od: Bacsa kdy 19. 08. 2018, 14:14:11
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í.
Je oboje, se podívej na scheduler v Go.
Citace od: Bacsa kdy 19. 08. 2018, 14:36:21
Je oboje, se podívej na scheduler v Go.
Nepodívám. Explicitní znamená, že je v programu explicitně řečeno, kdy dojde k přepnutí kontextu. Kooperativní to stejné.
Citace od: mmm kdy 19. 08. 2018, 14:42:36
Citace od: Bacsa kdy 19. 08. 2018, 14:36:21
Je oboje, se podívej na scheduler v Go.
Nepodívám. Explicitní znamená, že je v programu explicitně řečeno, kdy dojde k přepnutí kontextu. Kooperativní to stejné.
Škoda, zůstaneš v bludu ;)
Icecofeescript >3
Citace od: Bacsa kdy 19. 08. 2018, 14:14:11
Citace od: LadislavBohm kdy 19. 08. 2018, 03:49:39
Citace od: ScriptKid kdy 19. 08. 2018, 00:43:32
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.
Neznám Go, ale když mluvíme o asynchronním zpracování, tak nechápu proč zmiňujete vícevláknovost. Promise ani async await v JS ani C# nesouvisí ani nijak nepředpokládají jakékoli zapojení více vláken do běhu programu. Při async await v C# například funkce může běžet zcela synchronně, vše závisí na její interní implementaci.
Osobně si myslím, že to je ten problém. Bavíme se tu o asynchronních funkcích v JS, kdy potřebujete vědět, zda funkce doběhla a vznikla přitom výjimka, nebo ne. Při async await syntaxi toho docílíte tak, že nemusíte větvit funkce a řešit přepínání
this a kód syntakticky připomíná synchronní kód.
Async await navíc nepřejímá pouze JS, ale například i Python, Typescript a další.
Citace od: LadislavBohm kdy 20. 08. 2018, 13:13:49
Citace od: Bacsa kdy 19. 08. 2018, 14:14:11
Citace od: LadislavBohm kdy 19. 08. 2018, 03:49:39
Citace od: ScriptKid kdy 19. 08. 2018, 00:43:32
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.
Při async await syntaxi toho docílíte tak, že nemusíte větvit funkce a řešit přepínání this a kód syntakticky připomíná synchronní kód.
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.
Citace od: BascaAno, 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.
Citace od: LadislavBohm kdy 22. 08. 2018, 12:59:37
Citace od: BascaAno, 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?
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.
Citace od: oss kdy 22. 08. 2018, 14:07:21
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).
Citace od: mmm kdy 19. 08. 2018, 14:31:17
Citace od: Bacsa kdy 19. 08. 2018, 14:14:11
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.
Citace od: ScriptKid kdy 19. 08. 2018, 00:43:32
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.
Citace od: Bacsa kdy 19. 08. 2018, 14:14:11
Citace od: LadislavBohm kdy 19. 08. 2018, 03:49:39
Citace od: ScriptKid kdy 19. 08. 2018, 00:43:32
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ě.
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.
Citace od: JS guru kdy 23. 08. 2018, 06:48:46
Citace od: Bacsa kdy 19. 08. 2018, 14:14:11
Citace od: LadislavBohm kdy 19. 08. 2018, 03:49:39
Citace od: ScriptKid kdy 19. 08. 2018, 00:43:32
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.
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.
(https://pbs.twimg.com/media/CLWv31DWgAAvvsj.jpg)
Citace od: Vlado kdy 24. 08. 2018, 20:19:15
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 ::)
Citace od: Vlado kdy 24. 08. 2018, 20:19:15
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ů.
Citace od: Vlado kdy 24. 08. 2018, 20:19:15
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
Citace od: mmm kdy 24. 08. 2018, 21:00:17
Citace od: Vlado kdy 24. 08. 2018, 20:19:15
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.
Citace od: mmm kdy 24. 08. 2018, 21:12:25
Citace od: Vlado kdy 24. 08. 2018, 20:19:15
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
Bude v JS, preto už je v Babel. A áno, je to super a môžem prestať používať flow či compose z Lodash. Zasa, syntax čo má opodstatnenie, logiku, masovo sa používa, no tak sa pridá. Čo neznamená, že sa odniekiaľ okopíruje. Rovnako null coalesce operátor. Lenže ovce vždy budú bliakať, že to určite okopírovali z ich milovaného jazyka...
Citace od: Bacsa kdy 24. 08. 2018, 20:54:06
Citace od: Vlado kdy 24. 08. 2018, 20:19:15
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 ::)
Ja som zo salaša truľko? No hlavne že ty nie, asi preto sa voláš Bača...
Citace od: Vlado kdy 24. 08. 2018, 21:20:07
Lenže ovce vždy budú bliakať, že to určite okopírovali z ich milovaného jazyka...
Oni to neumí použít ani v tom milovaném jazyce. Jsou to LARPeři hrající si na programátory. Pro aktivně pracující programátory je každá feature usnadňující práci dobrá.