Reactive programiranje (na pr. VerteX, WebFlux) donosi kompleksnost u pisanju koda. U nastojanju da se event loop ne zadržava, sve se praktično wrappuje (Mono,Flux,Futures), kako se thread ne bi blokirao.
Čak i samo ovo – da ne odemo dalje sa asinhronim porukama – je dovoljno da svakodnevni codebase bude prepun ne-funkcionalnog koda. Veća kompleksnost, jasno, umanjuje čitljivost, zahteva održavanje, razumevanje… Ponavljam, dobar deo resursa se troši samo na to _kako_ nešto radi, a ne na _šta_ treba da uradi. Lično, mislim da te stvari moraju da nestanu iz koda, zajedno sa volatile i sličnim ne-funkcionalnim igrarijama, te da se jezik/framework sam bavi time – na isti način kao što danas ne razmišljamo o dealokaciji, jer imamo GC.
Da se vratim na temu: da li benefiti reactivnog non-blocking pristupa zaista imaju smisla? Glavna okosnica prezentacija je uglavnom to da je kreiranje velikog broja threadova “loša stvar”, iako odavno i kućni procesori se lagano nose sa velikim brojem threadova. Da, siguran sam da su performanse bolje u prvom slučaju – ali koliko, i da li ta razlika zaista vredi danas, u vreme kada se svaki veći saobraćaj svakako horizontalno skalira?
Ovim pitanjem se bavilo jedno Gugl istraživanje od pre (čak) 10tak godina. Ne uspevam da ga pronađem i podelim, no premisa je bila upravo u tome da moderni procesori sasvim lepo podnose veći broj threadova. Tu su bila i merenja koja nisu mogla da potvrde da je jedan pristup zaista toliko bolji od drugog.
Čim kažeš da ti je nešto kompleksno, to je već signal da nije za tebe. Kompletno iskustvo od 25+ godina mi to kaže.
Ne bavim se webom odavno ali u Swiftu već duže vreme postoji ista ta priča i od nedavno i Apple ima 1st-party reactive framework. Kao i za sve druge patterne, ako ti brzo klikne u glavi onda prihvati i koristi. Ako ne klikne posle par jednostavnijih primera, odustani i ne gubi vreme.
Iako to zvuči kao linija manjeg otpora, upravo je suprotno. IDE, patterns, frameworks – to su alati koje koristiš za resavanje problema. Moraš da ih dišeš i da ih maltene mehanički koristiš za resavanje stvarnog problema ili izazova. Ako ti je sam alat izazov, promeni alat.
Hvala na odgovoru! Ne pitam za mene, već za druga:) Šalu na stranu, nije fokus da li meni lično leži. Kompleksnost uvedena ne-funkcionalnim osobinama okruženja postoji. Banalizujem: od 40 reči koji napišeš za funkciji, preko 20 odlazi na samo žongliranje i presipanje stvari radi alata. Veća kompleksnost daje više grešaka u timu; primećujem da čak i kada je ekipa uigrana dešava se da neko zaboravi da wrapuje exception već ga - prirodno - baca; sva sreća pa IntelliJ to prepoznaje i javlja; što je takođe znak da postoji kompleksnost.
Napravio bih paralelu za nekadašnjim malloc/delete iz C na primer, kada je bilo potrebno da se sam brine o memoriji. Samo po sebi to ne zvuči kompleksno, ali se pokazalo da itekako proizvodi probleme; te otuda dolazi do _promene_ alata i nastanka jezika višeg reda koji to rade za nas.
Sad, ono što preispitujem ovde je: da li je došlo vreme da se unaprede alati (dakle, jezik) - da li non-blocking vredi toliko da se to i dogodi? Lično mislim da je odgovor "Da", i da ne treba da se rešava frameworkom već jezikom.
Zanimljivo je to oko alata. Reactive ili imperative pristup je fundamentalna osnova za app, tako da ako alati sa kojima radiš nisu napisani da se s tim “nose”, razvoj postaje pravo mučenje. Umesto da ti IDE pomaže, tipa klik na data type ti da njegov help ili listu implementacija protokola, svede se na to da radiš search i tražiš sam da bi video listu implementacija.
To je u Xcodeu recimo super očigledno ako otvoriš RxSwift app u odnosu na običnu app. IDE mora znati da iskopa šta ti treba a to obično znaci da implementacija koncepta bude ili deo Swift jezika ili deo Apple frameworka.
Primer koji navodiš za manual memory management je baš indikativan – neki jezici su to rešili uvođenjem GC pa runtime vodi računa a ObjC kroz sam compiler. I jedno i drugo rešenje ima svoje dobre i lose strane a teško je sve sagledati na duže staze. Teško je proceniti da li je sad za recimo Xcode bolje da se dodaje podesi za reactive frameworks ili da se vreme troši na razvoj drugog seta mogućnosti. A da ima šta da se dorađuje u Xcodeu, ih…
Neregistrovani korisnici mogu videti samo jedan komentar — registracija je besplatna i može da traje i samo 10s putem Linkedina. Na ovom postu su još učestvovali: