Ideálny programovací jazyk

[Zabanovaný Anonymní Troll]

To by se u normalniho stavoveho stroje s await async nemelo stat, protoze tam bezi jenom jeden thread.

Jistě, použít jediné vlákno je na dnešních mnohojádrových procesorech výborný nápad.

Pokud pisete  komponentu, kde vam chodi paralelne requesty, tak mate zparalelizovane uz ty requesty. Nepotrebujete paralelizovat i ukoly v ramci jednotlivych requestu, to je nesmysl.

Dalsi vec i kdybyste mel nejakou singleuser komponentu, tak pokud pokud jsou hlavnim problemem blokujici operace, tak na to zase nechcete pouzivat vlakna, akorat si budete komplikovat zivot. Takze v Jave nahrada za await async neni. Resp. je, ve Springu "@Async" a nakonfigurovat to at se berou vlakna z Quasar, ale to je zase tak pres koleno...

[Reklama]

[Filip Jirsák]

Pokud pisete  komponentu, kde vam chodi paralelne requesty, tak mate zparalelizovane uz ty requesty. Nepotrebujete paralelizovat i ukoly v ramci jednotlivych requestu, to je nesmysl.

Není to nesmysl, běžně se dělá to, že pro zpracování síťové komunikace (přijetí požadavku) se používá jeden pool vláken, a pro vlastní zpracování požadavku (výpočet, dotaz do databáze, odeslání jiného požadavku) jiný pool vláken.

Dalsi vec i kdybyste mel nejakou singleuser komponentu, tak pokud pokud jsou hlavnim problemem blokujici operace, tak na to zase nechcete pouzivat vlakna, akorat si budete komplikovat zivot. Takze v Jave nahrada za await async neni. Resp. je, ve Springu "@Async" a nakonfigurovat to at se berou vlakna z Quasar, ale to je zase tak pres koleno...

To je těžké, když jediné, co znáte, je Spring. Ve standardní knihovně máte concurrent framework, máte RxJava nebo Reactor, Netty (a tím pádem Micronaut) používá zmíněný pool IO vláken a pool workerů, Jetty má Continuations a tím byly inspirovány Asynchronous servlets. Přičemž Continuations jsou právě koncept await/async. Springovské @Async je něco jiného, je to klasické asynchronní zpracování, není tam to await.

[Zabanovaný Anonymní Troll]

Pokud pisete  komponentu, kde vam chodi paralelne requesty, tak mate zparalelizovane uz ty requesty. Nepotrebujete paralelizovat i ukoly v ramci jednotlivych requestu, to je nesmysl.

Není to nesmysl, běžně se dělá to, že pro zpracování síťové komunikace (přijetí požadavku) se používá jeden pool vláken, a pro vlastní zpracování požadavku (výpočet, dotaz do databáze, odeslání jiného požadavku) jiný pool vláken.

Dalsi vec i kdybyste mel nejakou singleuser komponentu, tak pokud pokud jsou hlavnim problemem blokujici operace, tak na to zase nechcete pouzivat vlakna, akorat si budete komplikovat zivot. Takze v Jave nahrada za await async neni. Resp. je, ve Springu "@Async" a nakonfigurovat to at se berou vlakna z Quasar, ale to je zase tak pres koleno...

To je těžké, když jediné, co znáte, je Spring. Ve standardní knihovně máte concurrent framework, máte RxJava nebo Reactor, Netty (a tím pádem Micronaut) používá zmíněný pool IO vláken a pool workerů, Jetty má Continuations a tím byly inspirovány Asynchronous servlets. Přičemž Continuations jsou právě koncept await/async. Springovské @Async je něco jiného, je to klasické asynchronní zpracování, není tam to await.

To by me zajimalo jak chcete s thready napsat aynchronni kod. Protoze k tomu abyste z toho opravdu dokazal tezit, tak potrebujete mit drtivou vetsinu metod await async - a proto nemuzete vyrabet novy thread pokade kdyz se vola nejaka metoda. Jenom tak se vam bude spoustet kaskada operaci zatimco normalne pisete relativne standardni kod a nesnazite se komplikovat si design paralelnim zpracovanim.

Springovske Async neni neco jineho, kdyz se to spravne pouzije (kdyz se budou vyrabet Fibery z Quasaru), tak je to prave TO  Await Async, podobne jako je v C#. Akorat je to zatizene prasackou reflexi Springu, protoze Java await async neumi. A pri blokujicich operaci to bude stejne vyrabet thread, protoze v Jave ejste neni moc standardni mit neblokujici operace, neblokujici JDBC se zacalo vyrabet snad teprve pred 1 rokem. (!!!!!!)

[Mirek Prýmek]

To by se u normalniho stavoveho stroje s await async nemelo stat, protoze tam bezi jenom jeden thread.

Pokud pisete  komponentu, kde vam chodi paralelne requesty, tak mate zparalelizovane uz ty requesty. Nepotrebujete paralelizovat i ukoly v ramci jednotlivych requestu, to je nesmysl.

Protoze k tomu abyste z toho opravdu dokazal tezit, tak potrebujete mit drtivou vetsinu metod await async - a proto nemuzete vyrabet novy thread pokade kdyz se vola nejaka metoda.

Neber si to osobně, ale tohle je dost odstrašující příklad přístupu k asynchronnímu programování.

1. chci používat jazyk s mutabilními strukturami (navíc OOP!)
2. async/paralelizaci si představuju tak, že všude možně prsknu async a await
3. očekávám, že to po mně nebude nic chtít, protože to bude "jakože běžet v jednom vlákně"
4. díky tomu, že mám sem tam ten async a await, to bude automagicky škálovat

Prvně by asi nebylo od věci si uvědomit, že

1. async/await není nic jiného než syntaktický cukr, který z programátora jenom snímá nutnost používat napřímo promisy (nebo jiný podobný mechanismus) a překladač je tam doplňuje sám. Takže všechno, co platí pro promisy (popř. ten jiný podobný mechanismus), platí i pro async/await kód.

2. neexistuje žádný zázračný "neblokující kód", který automagicky vede k vyššímu výkonu. Celý je to zcela prostý: pokud mám operace A, B, C, kde A a B jsou vzájemně nezávislé a C je závislé na A i B, tak se hodí A a B spustit zaráz a C až potom, co A i B doběhnou. Zázračný "neblokující kód" je samozřejmě při čekání na A+B blokovaný To je celý princip a je úplně jedno, jaká syntaktická wifikundace se použije k jeho zápisu.

3. díky async/await zápisu sice kód vypadá jako seriový (synchronní), ale to jenom vypadá a pořád je potřeba myslet na to, že smyslem té celé srandy je to, aby A a B mohly běžet potenciálně paralelně, protože to jediné je zdrojem toho potenciálního nárůstu výkonu, žádnej jinej magickej zrychlovací mechanismus tam není a být nemůže.

[Filip Jirsák]

To by me zajimalo jak chcete s thready napsat aynchronni kod.

No, ehm, úplně normálně? Asynchronní kód s vlákny dělá třeba to vaše @Async ze Springu, ostatně i primitivní new Thread().start() je asynchronní kód s vlákny.

Protoze k tomu abyste z toho opravdu dokazal tezit, tak potrebujete mit drtivou vetsinu metod await async

Asi bychom si nejprve měli ujasnit, co je await/async – je to syntaktický cukr, aby kód, který se provádí asynchronně, byl zapsaný jako klasický synchronní kód. Normálně u asynchronního volání určíte, co se má dít po do dokončení příslušného kódu. Await/async znamená, že to asynchronní volání nějak označíte (pokud má podporu přímo jazyk, obvykle klíčovým slovem await), a kód, který se má provést po dokončení asynchronního volání pak píšete pod to asynchronní volání. Ohledně možností toho, co můžete napsat, se nic nemění.

Jenom tak se vam bude spoustet kaskada operaci zatimco normalne pisete relativne standardni kod a nesnazite se komplikovat si design paralelnim zpracovanim.

Nemůžu si pomoci, ale podle mne je await špatný koncept. Ten nápad „asynchronní kód je pro programátora složitější, uděláme to, aby to vypadalo, že o žádný asynchronní kód nejde“ staví na tom, že ta komplikovanost vzniká jenom strukturováním kódu. Jenže podle mne by si programátor měl být vědom toho, že pracuje s asynchronním kódem, protože jednak to stejně může mít vedlejší efekty, jednak kód psaný neasynchronně nebude při provádění tak efektivní, jako když programátor záměrně píše asynchronní kód.

Springovske Async neni neco jineho, kdyz se to spravne pouzije (kdyz se budou vyrabet Fibery z Quasaru), tak je to prave TO  Await Async, podobne jako je v C#.

Springovské @Async předá provedení kódu standardnímu javovskému Executoru. V kódu, který volá @Async metodu, dostanete jako návratovou hodnotu Future a kód normálně pokračuje v provádění, nečeká na dokončení té asynchronní metody. Pokud chcete udělat await, musíte na tom Future vzápětí zavolat get(). To už ale nijak nesouvisí se Springovským @Async, to je normální chování Future.

[Reklama]

[Mirek Prýmek]

Nemůžu si pomoci, ale podle mne je await špatný koncept. Ten nápad „asynchronní kód je pro programátora složitější, uděláme to, aby to vypadalo, že o žádný asynchronní kód nejde“ staví na tom, že ta komplikovanost vzniká jenom strukturováním kódu. Jenže podle mne by si programátor měl být vědom toho, že pracuje s asynchronním kódem,

Vidím to přesně stejně. Imho pokud se má asynchronní programování nějak zjednodušovat, tak cestou explicitních greenthreadů/coroutin, kde:
1. je naprosto explicitní a zjevné, co může (potenciálně) běžet zaráz a co ne
2. programátor v klidu může použít blokování, pokud ho potřebuje ( sleep(3000) ), a je mu bezprostředně jasný jeho význam, protože se dá nad programem jako celkem relativně snadno uvažovat (to reason about)

[Zabanovaný Anonymní Troll]

To by se u normalniho stavoveho stroje s await async nemelo stat, protoze tam bezi jenom jeden thread.

Pokud pisete  komponentu, kde vam chodi paralelne requesty, tak mate zparalelizovane uz ty requesty. Nepotrebujete paralelizovat i ukoly v ramci jednotlivych requestu, to je nesmysl.

Protoze k tomu abyste z toho opravdu dokazal tezit, tak potrebujete mit drtivou vetsinu metod await async - a proto nemuzete vyrabet novy thread pokade kdyz se vola nejaka metoda.

Neber si to osobně, ale tohle je dost odstrašující příklad přístupu k asynchronnímu programování.

1. chci používat jazyk s mutabilními strukturami (navíc OOP!)
2. async/paralelizaci si představuju tak, že všude možně prsknu async a await
3. očekávám, že to po mně nebude nic chtít, protože to bude "jakože běžet v jednom vlákně"
4. díky tomu, že mám sem tam ten async a await, to bude automagicky škálovat

Prvně by asi nebylo od věci si uvědomit, že

1. async/await není nic jiného než syntaktický cukr, který z programátora jenom snímá nutnost používat napřímo promisy (nebo jiný podobný mechanismus) a překladač je tam doplňuje sám. Takže všechno, co platí pro promisy (popř. ten jiný podobný mechanismus), platí i pro async/await kód.

2. neexistuje žádný zázračný "neblokující kód", který automagicky vede k vyššímu výkonu. Celý je to zcela prostý: pokud mám operace A, B, C, kde A a B jsou vzájemně nezávislé a C je závislé na A i B, tak se hodí A a B spustit zaráz a C až potom, co A i B doběhnou. Zázračný "neblokující kód" je samozřejmě při čekání na A+B blokovaný To je celý princip a je úplně jedno, jaká syntaktická wifikundace se použije k jeho zápisu.

3. díky async/await zápisu sice kód vypadá jako seriový (synchronní), ale to jenom vypadá a pořád je potřeba myslet na to, že smyslem té celé srandy je to, aby A a B mohly běžet potenciálně paralelně, protože to jediné je zdrojem toho potenciálního nárůstu výkonu, žádnej jinej magickej zrychlovací mechanismus tam není a být nemůže.

https://stackoverflow.com/questions/14455293/how-and-when-to-use-async-and-await

Await/async neni v C# v zadne pripade "jen" syntakticky cukr. Kdyby byl, tak jak to udelas v Jave? Nijak. Pod Await/Async je totiz v C# stavovy stroj, Java to neumi.

https://stackoverflow.com/questions/2846664/implementing-coroutines-in-java

Thread-based coroutines
This "solution" is pathological. The whole point of coroutines is to avoid the overhead of threading, locking, kernel scheduling, etc. Coroutines are supposed to be light and fast and to execute only in user space. Implementing them in terms of full-tilt threads with tight restrictions gets rid of all the advantages.

Za dalsi, neznam nic jako "jen syntakticky cukr" - vyprosuju si vypustit to "jen". Protoze to uz potom muzeme rict, ze monitor je jen syntakticky cukr pro jen programatora, protoze frajeri pouzivaji multimetr a osciloskop pro zjisteni stavu jednotlivych bitu.

[Zabanovaný Anonymní Troll]

A je jedno, ze si nekdo mysli, jak se da neco zbastlit s await async a coroutinami. Zbastlit se da totiz uplne vsechno.

Java NEUMI Coroutiny a rovnocenna nahrada za ne neexistuje. Tecka.

A neumi coroutiny proto, ze by byly uplna na hovno, kdyz Java dodneska nema neblokujici API prinejmensim k JDBC. Protoze vyzirkove z Oracle teprve minuly rok zacali vyvije standard pro asynchronni JDBC, ikdyz .NET uz to davno vsechno ma zmaknute.

[Zabanovaný Anonymní Troll]

Asi bychom si nejprve měli ujasnit, co je await/async – je to syntaktický cukr, aby kód, který se provádí asynchronně, byl zapsaný jako klasický synchronní kód. Normálně u asynchronního volání určíte, co se má dít po do dokončení příslušného kódu. Await/async znamená, že to asynchronní volání nějak označíte (pokud má podporu přímo jazyk, obvykle klíčovým slovem await), a kód, který se má provést po dokončení asynchronního volání pak píšete pod to asynchronní volání. Ohledně možností toho, co můžete napsat, se nic nemění.

Pane Jirsak, ja jsem to rekl nepresne, ale to vy taky.

V C#, Await by se dal povazovat za syntakticky cukr pro neco jako "CompletableFuture.get()" ale Async cukr uz neni. O keyword Async uz nemuzete rict, ze je to cukr pro ktery kompilator provede neco jako "CompletableFuture.supplyAsync(()->.)" Na zklade klicoveho slova Async se musi nejak vygenerovat stavovy stroj, predstavu jak funguje mam jen pribliznou.

A to je to, co Java neumi. Kotlin to umi ale je to experimentalni feature.

V Javascriptu si nejsem jisty, zda Promise predstavuje stejny mechanismus jako Coroutiny v C#.

[Idris]

To by se u normalniho stavoveho stroje s await async nemelo stat, protoze tam bezi jenom jeden thread.

Pokud pisete  komponentu, kde vam chodi paralelne requesty, tak mate zparalelizovane uz ty requesty. Nepotrebujete paralelizovat i ukoly v ramci jednotlivych requestu, to je nesmysl.

Protoze k tomu abyste z toho opravdu dokazal tezit, tak potrebujete mit drtivou vetsinu metod await async - a proto nemuzete vyrabet novy thread pokade kdyz se vola nejaka metoda.

Neber si to osobně, ale tohle je dost odstrašující příklad přístupu k asynchronnímu programování.

1. chci používat jazyk s mutabilními strukturami (navíc OOP!)
2. async/paralelizaci si představuju tak, že všude možně prsknu async a await
3. očekávám, že to po mně nebude nic chtít, protože to bude "jakože běžet v jednom vlákně"
4. díky tomu, že mám sem tam ten async a await, to bude automagicky škálovat

Prvně by asi nebylo od věci si uvědomit, že

1. async/await není nic jiného než syntaktický cukr, který z programátora jenom snímá nutnost používat napřímo promisy (nebo jiný podobný mechanismus) a překladač je tam doplňuje sám. Takže všechno, co platí pro promisy (popř. ten jiný podobný mechanismus), platí i pro async/await kód.

2. neexistuje žádný zázračný "neblokující kód", který automagicky vede k vyššímu výkonu. Celý je to zcela prostý: pokud mám operace A, B, C, kde A a B jsou vzájemně nezávislé a C je závislé na A i B, tak se hodí A a B spustit zaráz a C až potom, co A i B doběhnou. Zázračný "neblokující kód" je samozřejmě při čekání na A+B blokovaný To je celý princip a je úplně jedno, jaká syntaktická wifikundace se použije k jeho zápisu.

3. díky async/await zápisu sice kód vypadá jako seriový (synchronní), ale to jenom vypadá a pořád je potřeba myslet na to, že smyslem té celé srandy je to, aby A a B mohly běžet potenciálně paralelně, protože to jediné je zdrojem toho potenciálního nárůstu výkonu, žádnej jinej magickej zrychlovací mechanismus tam není a být nemůže.

Tady jsi to nepochopil ty, u async/await nejde o promisy, ale korutiny. V případě NIO nebo třeba semaforů je to skutečně “magický mechanismus”. Výhoda oproti callbackům jsou kromě přehlednosti rozumně ošetřitelné chyby.

[Idris]

V Javascriptu si nejsem jisty, zda Promise predstavuje stejny mechanismus jako Coroutiny v C#.

Je to stejné.

[Filip Jirsák]

Await/async neni v C# v zadne pripade "jen" syntakticky cukr. Kdyby byl, tak jak to udelas v Jave? Nijak. Pod Await/Async je totiz v C# stavovy stroj, Java to neumi.

Pro stavový stroj nepotřebuju žádnou speciální podporu kompilátoru. Await/async jste na implementaci v C# zúžil právě teď, předtím jste psal o obecném await/async.

Zvláštní je, že když to v Javě nijak naprogramovat nejde, Jetty to má naprogramované jako Continuations. Ale to už jsme vám přece psal…

Za dalsi, neznam nic jako "jen syntakticky cukr"

Tak se s tím pojmem seznamte. Třeba v JavaScriptu je async/await v podstatě jen syntaktický cukr pro Promise.then(), liší se jen ve zpracování chybových stavů.

V C#, Await by se dal povazovat za syntakticky cukr pro neco jako "CompletableFuture.get()" ale Async cukr uz neni. O keyword Async uz nemuzete rict, ze je to cukr pro ktery kompilator provede neco jako "CompletableFuture.supplyAsync(()->.)" Na zklade klicoveho slova Async se musi nejak vygenerovat stavovy stroj, predstavu jak funguje mam jen pribliznou.

No jo, jenže vy nepíšete o async/await, ale o korutinách.

[Filip Jirsák]

Java NEUMI Coroutiny a rovnocenna nahrada za ne neexistuje. Tecka.

Chápu. Takže vy píšete spoustu nesmyslů, a když konečně napíšete něco správně, napíšete to tučně, abyste to od těch nesmyslů odlišil. Takže si ty nesmysly řešte s někým jiným, já si počkám, až za dvě stránky zase dospějete k něčemu pravdivému a napíšete to tučně.

[Mirek Prýmek]

Tady jsi to nepochopil ty, u async/await nejde o promisy, ale korutiny.

Tohle nechápu, můžeš to nějak rozvést?

V případě NIO nebo třeba semaforů je to skutečně “magický mechanismus”. Výhoda oproti callbackům jsou kromě přehlednosti rozumně ošetřitelné chyby.

Ok, rozumně ošetřitelné chyby můžou být, to je spíš interní věc jazyka. Ale jinak na tom nic magického není, pořád je to starý dobrý kooperativní multitasking, navíc s jenom potenciální paralelizací. Můžeš si to klidně napsat ručně, pokud máš k dispozici nějaký mechanismus, na kterém se dá stavět (multithreading, green threads, coroutiny, ...)

Jediná výhoda async/await je v tom, že to ručně psát nemusíš a překladač to udělá za tebe.

[Idris]

Tady jsi to nepochopil ty, u async/await nejde o promisy, ale korutiny.

Tohle nechápu, můžeš to nějak rozvést?

V případě NIO nebo třeba semaforů je to skutečně “magický mechanismus”. Výhoda oproti callbackům jsou kromě přehlednosti rozumně ošetřitelné chyby.

Ok, rozumně ošetřitelné chyby můžou být, to je spíš interní věc jazyka. Ale jinak na tom nic magického není, pořád je to starý dobrý kooperativní multitasking, navíc s jenom potenciální paralelizací. Můžeš si to klidně napsat ručně, pokud máš k dispozici nějaký mechanismus, na kterém se dá stavět (multithreading, green threads, coroutiny, ...)

Jediná výhoda async/await je v tom, že to ručně psát nemusíš a překladač to udělá za tebe.

Tak, jaks to napsal, to vypadá, že async/await je pro tebe jen syntaktický cukr. Ono jde ale hlavně o runtime, třeba v tom JS je obzvlášť důležité, že “blokující” volání kooperativně přenechá jediné vlákno jiné části kódu. Je to jako goroutiny s explicitním uváděním async/await (z toho plyne, že to je vesměs zbytečné, implicitně to vypadá ještě lépe). Důležité jsou ty chyby, protože v případě několika do sebe vnořených callbacků nejde udělat návrat z funkce (return by byl jen z lambdy), kdežto v případě linearizace se chyba vrací úplně normálně (jako třeba v Go) nebo normální výjimkou. Mnozí si bohužel myslí, že to explicitní uvádění je rozumné, už to proniklo i do C++ (co_await).