Naučení se asynchronnímu programování

[smonty]

Ahoj,
(na úvod: před cca třemi lety jsem z oblasti synchronního programování vstoupil do vod čistého managementu. Snažím se ve volných chvílích učit nové věci ale co mi chybí a chtěl bych doplnit je asynchronní styl myšlení.)

Chtěl bych se naučit asynchronímu stylu programování. PRIMÁRNĚ mi jde o naučení se stylu, konceptu myšlení asynchronního programování. Hledám proto libovolnou, co možná nejvhodnější technologii, kde bych se tomuto naučil. Nejde tedy o technologii ale o získání daného myšlení. Záměrně zde neuvádím programovací jazyky ke kterým mám nejblíže, zajímá mne hlas lidu. Budu rád, když danou technologii rozjedu na Linuxu.

díky moc za rady

[Reklama]

[Zabanovaný Anonymní Troll]

Asynschronni programovani je totalni srajda, je to dobre tak na klikatka na webu a podobne usecase. Na backend to budto nepatri vubec, nebo si musi dotycny citlive zvolit na co se mu to tam hodi, ale by default pouzivat synchronni programovani. Na backendu neprinasi asynchronni design zadne vyhody a je akorat problematicky. Vyjimkou snad muzou byt komponenty ktere musi zvladat tisice requestu za vterinu pochazejicich z Internetu a zaroven nesmi zrat moc zdroju, a takove komponenty jsou v enterprise velice vyjimecne.

Jak nekoho vidim, ze bastli backend a ze srandy to dela asynchronni, tak se mi otevira kudla v kapse.

Takze jestli se chces naucit asynchronni programovani, tak bez delat weby v node.js, tam presne to totiz patri. A abyses v tom bordelu co ti vznikne vyznal, tak tam samozrejme musis dat Redux. A neopovazuj se strkat asynchronni veci na backend, bo si te najdu a zbiju te.

[Idris]

“Technologie,” která pomůže k pochopení principů, je kqueue. Na BSD (včetně macOS) to je přímo syscall, ale pro Linux existuje libkqueue se stejným API. Na vyšší úrovni pak GCD (libdispatch).

[Jakub Štech]

Já můžu za sebe doporučit (jako takovou ilustrující technologii) message brokery, například zeromq, konkrétně komunikační schéma push-pull, které se právě hodí k rozdělení úloh mezi velké množství asynchronně pracujících jednotek. Byl tu o tom na rootu docela pěkný seriál: https://www.root.cz/clanky/dalsi-moznosti-poskytovane-knihovnou-mq/#k12

Další náměty jsou zde: https://stackoverflow.com/questions/31248615/distributed-task-processing-using-zeromq

[Filip Jirsák]

Když to vezmete podle používanosti jazyků, je JavaScript asi nejrozšířenější jazyk, kde je asynchronní programování od začátku integrální součástí jazyka. Spousta programátorů ho i kvůli tomu nenávidí… Dnes už se dá JavaScript používat i pro backend, osobně bych ho tam ale nepoužil na nic víc, než nějaké prototypy. Ale na webovém frontendu JavaScript kraluje a asynchronně se tam programuje odjakživa.

Pokud by vás zajímal spíš backend, tam se vyznám nejvíc v Javě. Pokud byste chtěl něco low-level, existuje projekt Netty pro asynchronní síťovou komunikaci, staví se nad tím webové servery i klienti, streamovací servery a spousta dalších protokolů. Pokud něco na vyšší úrovni, osobně bych doporučil Micronaut Framework – myslím, že je to Spring budoucnosti. Interně používá také Netty, interně má obsluhu požadavků asynchronní, ale umí to skrýt a pracovat v synchronním režimu.

Ale záleží, který směr vás zajímá – já jsem uvedl konkrétní implementace, ostatní uvedli koncepty jako message broker nebo fronta událostí. „Asynchronního“ toho na programování může být dost, ten pojem pokud vím neoznačuje nic konkrétního.

[Reklama]

[listoper]

V clojure je core.async. Myslim, ze je inspirovano go rutines. Jestli se nebojis lispu tak doporucuju.

[Mirek Prýmek]

Chtěl bych se naučit asynchronímu stylu programování.

Imho bys musel říct trochu konkrétněji, o co ti vlastně jde, co by ses chtěl naučit a proč.

Protože "asynchronní styl" může znamenat různý věci v různých kontextech. Většina z nich spolu nějak souvisí, ale není to totéž a pokud chceš radu, musíš to trochu líp specifikovat.

Jenom tak pro ilustraci, kolik různých věcí může "asynchronní styl" znamenat:

1. chci se v Pythonu naučit používat "async" a "await"
2. chci se naučit programovat multi-taskové aplikace ve FreeRTOSu a komunikaci mezi tasky
3. chci pochopit goroutiny a komunikaci mezi nimi
4. chci umět napsat multi-agentní (-servisovou, -komponentovou, distribuovanou...) aplikaci, kde jednotlivé komponenty jsou sice "synchronní", ale business logika celkového systému je z principu věci "asynchronní"
5. chci systému z předchozího bodu rozumět včetně nějaké té teorie kolem toho (všichni ti byzantští generálové apod.)
6. zajímá mě, jak se ty runtimy, na kterých ty "asynchronní jazyky" běží, píšou
7. zaujal mě actor model (nebo CSP, ...) a chtěl bych ho pochopit teoreticky i naučit se ho používat
atd. atp. ... možností je bambilion.

Záměrně zde neuvádím programovací jazyky ke kterým mám nejblíže, zajímá mne hlas lidu.

To mi moc nedává smysl. Ať už "asynchronní styl" znamená cokoli, dá se zrealizovat v každém rozumném jazyce, ale v každém trochu jinak. Základní principy jsou přenosné, ale nemá smysl se to učit v jazyce, který ti není blízký a nebudeš ho nikdy používat.

[gill]

Asi bych začal s Javascriptem a oficiální dokumentací od Mozilly. Můžete si pohrát třeba s fetch API, zkoušet čisté Promisy i async/await. Snažte se používat jen API postavená na Promisech, dnes by to neměl být problém.

V Pythonu je to zkomplikované neexistencí jednotné event loop. await v Pythonu je v podstatě jen alias pro yield from. Na druhou stranu v async knihovnách v Pythonu existují standardní synchronizační primitiva jako asyncio.Queue a další https://docs.python.org/3/library/asyncio-sync.html, v JS musíte používat balíky třetích stran a kombinovat víc knihoven.

[gill]

doporučuji starší videa Davida Beazleyho, kde implementuje vlastní event loop https://www.youtube.com/watch?v=MCs5OvhV9S4

https://www.youtube.com/watch?v=ZzfHjytDceU


následně implementoval i vlastní alternativu k asyncio, curio https://github.com/dabeaz/curio

která se sice neprosadila, ale inspirovala změny v standardním asyncio

[gill]

ale co mi chybí a chtěl bych doplnit je asynchronní styl myšlení.

to se naučíte jen praxí. Napište, jaký problém chcete asynchronně řešit, v jakém jazyce, a my vám poradíme konkrétněji.

[luvar]

Nie som istý o akú úroveň asynchronicity Vám ide. Ja to vnímam tak, že je úroveň projektu (jedna binárka) a úroveň celkovej architektúry (komunikácia medzi komponentami samostatne bežiacimi). Skúsim pridať môj názor pre obe.

Osobne by som odporučil (pre low level, programátorský pohľad) knižku https://learnyousomeerlang.com/ a teda jazyk erlang.

Je v každom prípade ale nutné si uvedomiť rozdiel medzi "non-blocking" a "async". Myslim, ze to bolo pekne vysvetlene vo videu tuna: https://youtu.be/E3s5f-JF8z4?t=526 Je to z prednasky o https://r2dbc.io/, čo je reaktívny, non-blocking drajver k databázam. V každom prípade takýto štýl programovania má zmysel pri spoločnostiach a produktoch o veľkosti "netflix". Inde sa to nezaplatí aktuálne.

Ďalšou kategóriou ale môže byť vzdelávanie v "asynchrónnych" mikroservisoch, kde sa dá nahliadať na komunikáciu medzi službami, ktorá býva zväčša asynchrónna. Tam je vhodné hodiť do googlu napríklad "CQRS", alebo "event sourcing", prípadne spomenuté zeromq, či architektúry používajúce kafku alebo pulsar, či rabbitmq.

Všeobecne vhodným zdrojom praktických príbehov býva https://www.infoq.com/ portál (a zvačša tam nie sú prešlapy, ako v bežných časopisoch, kde napíšu občas do očí kričiacu koninu).

[PanVP]

Jak nekoho vidim, ze bastli backend a ze srandy to dela asynchronni, tak se mi otevira kudla v kapse.

Přehnaně asynchronni aplikace se často plní omáčkou, zhoršuje se její čitelnost a bezpečnost.
IMHO je skutečně dobré uvážit, co dělat synchronně a co ne.
Sám jsem se dostal do krásné pasti, v zápalu "jééé to je super", jsem tak napsal jednu verzi aplikace.
Byla delší, vypadala hustě, kolega jí nerozuměl. Měl jen jednu vadu, občas sebou řízla a nedokázal jsem zjistit proč se to vlastně stalo. Nakonec bylo jednodušší hromady kódu vyházet a asynchronně dělat skutečně jen rozumné minimum.

[gill]

Byla delší, vypadala hustě, kolega jí nerozuměl.

s async/await se dá psát stejně stručně jako s vlákny. Většinou stručněji, nehrozí data races a jiné chyby.

[gill]

A neopovazuj se strkat asynchronni veci na backend, bo si te najdu a zbiju te.

neřešil jsi tu nedávno long polling v Javě? S asynchronní technologií to je trivialita, na kterou by ses nemusel ptát na foru. To stejné sockety.

[Mirek Prýmek]

Byla delší, vypadala hustě, kolega jí nerozuměl.

s async/await se dá psát stejně stručně jako s vlákny. Většinou stručněji

Stručnost je pravda. Zároveň ale potenciální nesrozumitelnost kolegovi je taky realita. Obávám se, že developerů, kteří opravdu chápou, co async/await dělá, bude relativně málo. Obávám se, že velká část těch, kdo async/await umí použít, se budou jenom řídit takovými těmi pravidly palce typu "když je uvnitř někde await, funkce musí být async" apod.

nehrozí data races a jiné chyby.

V jakém smyslu? V porovnání s čím? Jaký přesně mechanismus zaručuje, že k nim nemůže dojít?

---
Konkrétně třeba pro Python: zápis je pěkný, na první pohled čitelný. Reasoning o chování většího kódu je ale pořád složitější než u "jednovláknového" programu (čemuž se dost dobře nedá vyhnout, není to tak úplně chyba Pythonu). Dost katastrofa je to ale na úrovni infrastruktury: Pokud chci async/await použít, musím mít úplně jiné, "async" knihovny. A ty jsou oproti jejich starším "sync" variantám většinou daleko víc zabugované nebo nedodělané. Navíc neustále budu narážet na problém "červeného a modrého světa" [1], často se stane, že kvůli tomu nepůjde dobře zrealizovat návrh, který jsem měl namyšlený - že je tam problém si všimnu až při psaní, dopředu se to odhaduje fakt těžko. Problémy typu "aha, __init__ vlastně nemůže být async! Doprčic!"


[1] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/