Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: ScriptKid 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, 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
-
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.
-
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.
-
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.
-
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 [].
-
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).
-
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í.
-
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.
-
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é.
-
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
-
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ší.
-
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.
-
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.
-
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?
-
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.
-
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).
-
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.
-
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.
-
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.
-
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)
-
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 ::)
-
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ů.
-
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
-
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.
-
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...
-
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...
-
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á.