Vlákno názorů k článku
Swift dostane async/await od Ladis - Apple doteď hodně tlačil na programátory, aby jel...

Apple doteď hodně tlačil na programátory, aby jel kód asynchronně a UI aplikací na jeho systémech tak bylo svižnější než na konkurenci. Nicméně byla jen otázka času, než umožní programovat synchronně, což je nutné pro nával business programátorů, co dřív dělali např. ve Visual Basic. Pro ty je asynchronní a vícevláknové programování prostě příliš složité (minimálně pro debugování). (Já sám proti Basicu nic nemám, každý jazyk má své místo - bavilo mě např. psát komplexní VBA makra v Excelu.)

v C# je async/await poměrně pěkně použitelný a člověk si na to zvykne, pro UI to bylo vysvobození, overhead je poměrně malý a dobře se i debuguje, ale např. v JS to je poměrně solidní peklo, začátek vypadá zajímavě, ale pak to začne, debugování skoro nemožné, stacktrace trpí i nadužíváním Promise.then, celé to vytváří větší chaos než prosté callbacky, paradoxně.

Ve Swiftu jsem zvědavý na implementaci, ještě jsem na to nekoukal.

Použitelné to je. V C# vyvíjím už deset let. Také ale vím, že to má spoustu problémů. Prakticky všechny IO knihovny jsou schizofrenní (varianta sync + async). Lepší cestou by byla implementace vláken na aplikační úrovni, jako jsou gorutiny.
Pěkné povídání kolem tohoto problému je zde
https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

Přesně to tam je, GCD má “vlákna” na aplikační úrovni a mapuje je na dostupná jádra. Stejně jako Go nebo async/await v C++.

Pak tedy performance výhoda async/await oproti klasickému použití vláken je nulová. Jde jen o pro někoho pohodlnější zápis. Nevýhodou tohoto je nutnost vzniku dvojí API (sync a async verze). Z async kódu je totiž možné volat sync kód, ale opačně to čistým způsobem nejde.

Tato drobná nevýhoda (že se async funkce chovají speciálně a je třeba je volat speciálně) je kompenzovaná obrovskou výhodou: konkurence je opt-in, ne opt-out. Můžete mít jistotu (pokud zároveň nepoužíváte vlákna), že vám nikdo jiný nemůže měnit data pod rukama, kromě míst, kde čekáte na něco asynchronního. Místo toho, aby člověk musel zámky označovat všechna místa, kde je konkurence nebezpečná (a určitě na nějaké zapomněl), označí pomocí awaitů všechna místa, kde je bezpečná. A ta místa jsou na první pohled vidět, protože await má specifickou syntaxi, to je taky velmi důležité.
Nejlépe tohle funguje v Pythonu, kde je asyncio program standardně striktně jednovláknový. Ano, připravíte se tím o trochu výkonu, ale (1) často to nevadí, (2) dá se to řešit, např. tím, že si člověk pustí jeden separátní proces pro každé jádro. Tohle je jedna z hlavních výhod async/await programování. To, že to může být občas rychlejší / méně náročné než plná vlákna, je až druhotné. Rychlost se dá vždycky dohnat lepším hardwarem. Ale aby se o programování jednodušeji přemýšlelo a bylo těžší dělat chyby, to je nenahraditelné. Lightweight vlákna typu greenlets/gorou­tines vám tohle nedají.

Jak nedají? Goroutiny fungují úplně stejně jako async/await v C#, C++ a Swiftu, rozdíl je jen syntaktický. Všechny tyto implementace jsou postavené nad runtimem à la GCD, který je jen trochu abstraktnější vrstvou API nad kqueue/epoll/IOCP. Jediná výhoda té syntaxe je vyhnutí se callbackovému peklu (profláklý terminus technicus), které Apple přidal do svého překladače céčka a teď se ho snaží eliminovat z kódu vyšší úrovně.

"stacktrace trpí i nadužíváním Promise.then"

await v JS je prave nahrada promise/then. Podle me hlavni problem promise based coroutin v JS je, ze nejdou prerusit. Jde to resit ruznym owrapovanim nebo generatory. https://medium.com/@masnun/creating-cancellable-promises-33bf4b9da39c

Nesporná výhoda async/await je, že umožňuje psát asynchronní kód prakticky stejným stylem jako by byl synchronní.

Jo, a dokonce to jde i bez toho syntaktického cukru.