🚀 go-pugleaf

W dniu 2016-08-27 o 21:19, Mikołaj 'Virion' Milewski pisze:
> W dniu sobota, 27 sierpnia 2016 20:17:27 UTC+2 użytkownik arivald napisał:
>
>> Utrzymanie spójności danych globalnych to też problem - po każdej
>> zmianie trzeba by wysyłać message do każdego workera który tej danej używa.
>>
>>
>> W większości języków z wielowątkowością wątki mają wspólną pamięć, to
>> program dba o synchronizację. Zmienne globalne, serwisy, cache, etc bez
>> duplikatów.
>> Przesyłać pomiędzy wątkami można wydajnie, po prostu wskaźnikami czy
>> referencjami.
>
> No i spójrzmy, do czego to prowadzi:
> 1. Globalne zmienne / globalny stan aplikacji - antywzorzec, który nader
> ciężko wybić z głowy sobie / pracownikom

Antywzorzec, ale niezbędny. I nie mówię tu o zmiennych w globalnej 
przestrzeni nazw, globalnym scope, bo np. statyczne pola i metody w 
klasach takze są globalami.

Nadużywanie zmiennych globalnych to jest dopiero problem.


> 2. Konieczność jawnej synchronizacji każdego współdzielenia danych między
> wątkami - deadlocki, bottlenecki i wszystkie tej maści ścierwa, które
> każdemu z nas niejedną godzinę z życia zeżarły, bo debugowanie tego to koszmar

E, jaki tam koszmar. Wystarczy parę zasad (dane są albo stałe, każdy 
wątek może czytać, albo dane należą do danego wątku i tylko on może je 
czytać i zmieniać, używać odpowiednich mechanizmów do przesyłania danych 
z wątku do wątku), i problemy znikają.


> 3. Organiczny wzrost couplingu (zna ktoś jakiś zgrabny polski odpowiednik?),
> bo przecież łatwo i się da, to czemu nie

IMO sprzęganie.

Naprawdę nie widzę czemu akurat wielowątkowość ma na to jakiś wpływ.
To raczej zależy od zadań i architektury aplikacji. Wystarczy zastosować 
pośrednika, np kontener IOC, do komunikacji jakiś szyna komunikatów albo 
slot-signal, etc., żeby osiągnąć luźne sprzeganie komponentów.


> Myślę, że asynchroniczne podejście JSa promuje budowę software'u bardziej
> na zasadzie mikroserwisów, niż złożonych struktur.

Owo "asynchroniczne podejście JSa" jest wymuszone przez jego 
jednowątkowość. I nie jest to tyle podejście JS co podejście API których 
z JS się używa, żeby zapewnić w płynne działanie aplikacji.

Dokładnie tak samo da się sterować aplikacją w każdym języku.
Np kolejka komunikatów w Windows (i w wielu innych) jest bardzo podobnym 
rozwiązaniem, zamiast eventów JS są komunikaty.


> Separując developera od
> problemów, które 'starzy natywni wyjadacze' zwykli bohatersko rozwiązywać,
> w gruncie rzeczy ułatwia pracę. Sam w to kiedyś nie do końca wierzyłem,
> ale czy gdyby tak nie było, to czy ten ekosystem uzyskał by takie momentum?

IMO to jest związane raczej z rosnącym znaczeniem, ilością i 
skomplikowaniem aplikacji przeglądarkowych.
JS ma swoje nisze i zastosowania, ale nie jest to język na którym 
bazował bym aplikację.

-- 
Arivald