Uczenie się Erlang a uczenie się node.js [zamknięte]

41

Widzę dużo badziewia w Internecie o tym, jak Erlang kopie dupę node.js w niemal każdej możliwej kategorii. Chciałbym więc nauczyć się Erlanga i dać mu szansę, ale oto problem. Zauważyłem, że znacznie trudniej jest mi wybrać Erlanga, niż węzła.js. Za pomocą node.js mogłem wybrać stosunkowo skomplikowany projekt, a pewnego dnia miałem coś do roboty. Z Erlangiem wpadam na bariery i nie idę tak szybko.

Więc .. dla osób z większym doświadczeniem, czy Erlang jest trudny do nauczenia się, czy po prostu czegoś brakuje? Node.js może nie być idealny, ale wydaje mi się, że mogę to załatwić.

Noli
źródło
9
Może czegoś mi brakuje, ale czy node.js nie jest biblioteką JavaScript, a Erlang to zupełnie inny język? Jak są nawet porównywalne?
FrustratedWithFormsDesigner
3
@FrustratedWithFormsDesigner, node.js jest częścią najnowszej mody / hype uzyskiwania javascript po stronie serwera, z podejściem wielowątkowym, więc są porównywalne
lurscher
5
@lurscher: Nie można porównywać Erlang (język) z Node.js (JavaScript po stronie serwera). To byłoby jak porównanie Java (język) z Django (python serwera). Nie wspominając już, że Erlang i JS są również bardzo różne.
Josh K
10
Jako ktoś, kto używa zarówno Erlang i węzła, są one na pewno porównywalne z problemów, które oni rozwiązać
Dale Harvey
3
@Noli istnieje różnica między node.js i erlang. Miałeś na myśli porównanie między serwerami node.js i serwerami WWW opartymi na erlang. Erlang ma wielu użytkowników poza serwerami WWW.
Raynos

Odpowiedzi:

46

Przede wszystkim zgadzam się z TYLKO poprawną odpowiedzią OPINII na temat nauki Erlanga. Jest to głównie język funkcjonalny (choć współbieżność odgrywa dużą rolę), a wszystkie jego funkcje zostały dodane, aby zapewnić odporność na awarie i niezawodność, co nie jest dokładnie tymi samymi celami projektowymi, co JavaScript.

Po drugie, pozostawienie Node.js, aby dostać się do Erlang, jest nieco niewłaściwe. Node.js jest pojedynczym serwerem / strukturą, która robi wszystko, aby sterować zdarzeniami za pomocą wywołań zwrotnych. Erlang ma swój własny framework (OTP), ale wcale nie jest na tym samym poziomie.

Jeśli planujesz uczyć się Erlanga, proponuję, aby mój wpis na blogu „List otwarty do początkującego Erlanga” (lub „Obserwatora”) był wstępem przed zanurzeniem się w tutoriale.


Jedyną rzeczą, w której można porównać Erlang i Node.js, pod względem wzorców i użycia, jest sposób, w jaki są one sterowane zdarzeniami. Istnieją jednak dwie duże różnice. Model Node.js opiera się na wywołaniach zwrotnych powiązanych ze zdarzeniami. Erlang opiera się na kolejkach wiadomości i selektywnych odbiorze. Jakie są tam implikacje?

Przede wszystkim, jeśli robisz rzeczy w sposób oparty na wywołaniu zwrotnym, jedynym sposobem przenoszenia stanu jest albo globalne, albo przejście do programowania stylu kontynuacji. Po drugie, musisz sam zadbać o pełną matrycę zdarzeń. Jednym z przykładów jest to, że jeśli wyobrażamy sobie bardzo prostą maszynę skończoną: semafor mutex, sterowany zdarzeniami.

Semafor mutex ma dwa stany: zablokowany i wolny. Ilekroć dana jednostka obliczeniowa (proces roboczy, proces, funkcja lub wątek) chce uzyskać dostęp do muteksu, musi uruchomić zdarzenie, które mówi „jestem zainteresowany”. Teraz musisz zadbać o następujące typy wydarzeń:

  • Muteks jest darmowy i poprosisz o uzyskanie blokady
  • Muteks jest zablokowany przez kogoś innego i chcesz uzyskać blokadę
  • Muteks jest zablokowany przez ciebie i chcesz go uwolnić

Następnie musisz wziąć pod uwagę dodatkowe zdarzenia, takie jak przekroczenie limitu czasu w celu uniknięcia impasu:

  • Muteks został zablokowany, a ty czekałeś zbyt długo, odliczając czas do oddania ognia
  • Muteks został zablokowany, a ty czekałeś zbyt długo, uzyskałeś blokadę, a następnie upłynął limit czasu

Następnie masz również zdarzenia niezwiązane:

  • właśnie zablokowałeś muteks, podczas gdy jakiś pracownik oczekiwał, że będzie wolny. Teraz zapytanie pracownika musi zostać umieszczone w kolejce, aby kiedy było wolne, było obsługiwane
  • Musisz uczynić całą pracę asynchroniczną

Macierz zdarzeń bardzo szybko się komplikuje. Nasz FSM ma tutaj tylko 2 stany. W przypadku Erlang (lub dowolnego języka z selektywnym odbieraniem i asynchronizacji z potencjalnie synchronicznymi zdarzeniami) musisz zadbać o kilka przypadków:

  • Muteks jest darmowy i poprosisz o uzyskanie blokady
  • Muteks jest zablokowany przez kogoś innego i chcesz uzyskać blokadę
  • Muteks jest zablokowany przez ciebie i chcesz go uwolnić

I to wszystko. Liczniki czasu są obsługiwane w tych samych przypadkach, w których wykonywane są odbieranie, a dla wszystkiego, co ma związek z „czekaniem, aż będzie za darmo”, wiadomości są automatycznie kolejkowane: pracownik musi tylko czekać na odpowiedź. Model jest znacznie prostszy w tych przypadkach.

Oznacza to, że w ogólnych przypadkach CPS i modele oparte na wywołaniach zwrotnych, takie jak ten w node.js, albo proszą cię o bardzo sprytne obchodzenie się ze zdarzeniami, albo proszą o zajęcie się całą złożoną macierzą zdarzeń, ponieważ musisz być oddzwaniany w każdej nieistotnej sprawie, która wynika z dziwnych problemów z czasem i zmian stanu.

Odbiory selektywne zwykle pozwalają skupić się tylko na podgrupie wszystkich potencjalnych zdarzeń i pozwalają znacznie łatwiej uzasadniać zdarzenia w tym przypadku. Zauważ, że Erlang ma zachowanie (wzorzec projektu / implementacja struktury) czegoś o nazwie gen_event. Implementacja gen_event pozwala mieć mechanizm bardzo podobny do tego, który jest używany w node.js, jeśli tego chcesz.


Będą inne punkty, które je różnicują; Erlang ma zapobiegawcze planowanie, podczas gdy node.js sprawia, że ​​współpracuje, Erlang jest bardziej odpowiedni do niektórych bardzo dużych aplikacji (dystrybucji i wszystkich), ale Node.js i jego społeczność są zwykle bardziej zdolni do Internetu i mają wiedzę na temat najnowszych trendów internetowych. To kwestia wyboru najlepszego narzędzia, a to zależeć będzie od twojego pochodzenia, rodzaju problemu i twoich preferencji. W moim przypadku model Erlanga bardzo dobrze pasuje do mojego sposobu myślenia. Niekoniecznie dotyczy to wszystkich.

Mam nadzieję że to pomoże.

UDZIELAM STRASZNEJ PORADY
źródło
Więcej informacji na temat programowania reaktywnego i robienia tego w JS: blog.flowdock.com/2013/01/22/…
Bart
„ponieważ trzeba oddzwonić w każdej nieistotnej sprawie wynikającej z dziwnych problemów z czasem i zmian stanu”. - w Erlang nadal musisz obsługiwać liczniki, a fakt, że robisz to „w tych samych przypadkach, w których odbieranie jest zakończone”, wcale nie zmienia złożoności. Z mojego punktu widzenia (jako architekt systemów przetwarzających miliardy żądań dziennie) jedynymi realistycznymi różnicami między selektywnym odbieraniem a stylem node.js jest (a) pytanie „co domyślnie chcemy robić” (z node.js domyślnie przetwarzają zdarzenia, a Erlang odkłada wydarzenia, chyba że dojdzie do dopasowania) ...
No-Bugs Hare
... i (b) czytelność, w tym ilość płyty kotła (co jest dość złe w klasycznym pliku node.js, ale stała się znacznie lepsza - i IMNSHO lepsza niż Erlanga - z nowo wprowadzonym operatorem oczekującym) ... I w każdym razie , różnice te są w dużej mierze kosmetyczne (pomimo gorliwości po obu stronach głoszących inaczej).
No-Bugs Hare
38

Erlang nie jest trudny do nauczenia, jest obcy dla sposobu myślenia, którego nauczyła się Chambers Constant (99,44%) programistów. Problem, przed którym stoisz, to raczej dezorientacja konceptualna niż faktyczna złożoność.

Oto niektóre z obcych funkcji Erlanga, które ugryzą typowego programistę:

  • Erlang jest (głównie) funkcjonalnym językiem programowania. Najpopularniejsze języki programowania są niemal bezwzględnie konieczne.
  • Model współbieżności Erlanga to model aktora. Większość popularnych języków programowania używa wątków opartych na blokadach lub innej metody współbieżności opartej na „reaktorze”. (Myślę, że Node.js jest tym drugim, ale nie dzwoń do mnie - nie interesuję się JavaScript po żadnej stronie relacji klient / serwer).
  • Erlang ma podejście pozwalające na awarię kodowania dzięki dostępnym zaawansowanym funkcjom środowiska wykonawczego w celu wychwycenia tych awarii, zdiagnozowania ich i poprawienia podczas pracy systemu. Najpopularniejsze języki programowania popierają wysoce defensywny styl programowania.
  • Erlang jest prawie, ale nie do końca, nierozerwalnie związany z dużą i lekko zakręconą biblioteką powszechnie używanych architektur dla niezawodnych i stabilnych serwerów (OTP). (Jest powód, dla którego Erlang jest zwykle określany jako Erlang / OTP.) Ponadto ta biblioteka jest zbudowana na wspomnianych wcześniej obcych funkcjach i dlatego jest nieprzejrzysta dla nowych użytkowników. Większość języków programowania ma mniej wszechstronnych bibliotek (pomimo Java EE) do pracy, a wspomniane biblioteki są oczywiście oparte na koncepcjach, które są bardziej znane większości programistów.

Zatem nauka Erlanga będzie większym wyzwaniem dla większości programistów niż nauka Node.js - zwłaszcza jeśli programista jest już zaznajomiony z JavaScript. W końcu jednak, gdy pojawi się obok koncepcyjnego barierę, I twierdzą, że Erlang kodowanie będzie mniej skomplikowane niż równoważne node.js kodowania. Wynika to z kilku powodów:

  • Model współbieżności Erlanga sprawia, że ​​przepływ logiki jest znacznie wyraźniejszy niż typowa współbieżność w stylu „reaktora” i sprawia, że ​​współbieżność jest znacznie bardziej stabilna i poprawna niż typowa współbieżność oparta na blokadzie. Programiści Erlang nie mają prawie żadnego problemu, aby upuszczać dosłownie tysiące procesów w typowym programie, jednocześnie upuszczając tysiące wątków, powiedzmy, Java byłaby koszmarem niezgody (nie wspominając o zaangażowanej pamięci i obciążeniu procesora) oraz równoważne z utrzymaniem tysięcy osobnych stanów w układzie opartym na „reaktorze” byłoby koszmarem do przeczytania.
  • Będąc (głównie) językiem funkcjonalnym, Erlang jest w dużej mierze konfiguracją „to, co widzisz, dostajesz”. Zmienne, raz ustawione, nie zmieniają się. Zawsze. Nie ma „upiornej akcji na odległość”, która mogłaby cię zdezorientować: wszystko, z czym pracujesz, jest wyraźnie przedstawione przed tobą. Nie ma odziedziczonych zmiennych z X i żadnych zmiennych klas z Y, ani żadnych globalnych zmiennych z Z, którymi można się zająć. (Ten ostatni punkt nie jest w 100% prawdziwy, ale jest tak w tak przytłaczającej liczbie przypadków, że jest wystarczająco dobry dla twojej fazy nauki).
  • Potężne funkcje Erlanga w zakresie obsługi błędów oznaczają, że zaśmiecasz swój kod przy pomocy mniej defensywnego programowania, dzięki czemu logika jest bardziej przejrzysta, a kod mały.
  • Biblioteka OTP, po jej uruchomieniu, jest niesamowicie potężnym stosem wspólnego kodu, który utrzymuje całą aplikację w prawidłowy sposób i obejmuje wiele problemów oraz wykorzystuje przypadki długotrwałych serwerów, o których prawdopodobnie nie pomyślisz, dopóki nie będzie za późno. Sama biblioteka OTP jest, IM (ns) HO wystarczająco dobrym powodem do nauki Erlanga.

Kontynuuj trzepanie w Erlangu, jeśli możesz, a jeśli jeszcze tego nie zrobiłeś, odwiedź stronę Learn You Some Erlang for Great Good, aby uzyskać delikatne i (przeważnie) zabawne wprowadzenie do koncepcji Erlanga.

WŁAŚNIE MOJA poprawna OPINIA
źródło
Dziękuję za ten post. Czytam teraz Naucz się trochę Erlanga i jestem w połowie książki, ale mam wrażenie, że muszę to wszystko wiedzieć, zanim będę mógł naprawdę zacząć robić coś umiarkowanie znaczące, a nie tylko kawałek po kawałku
Noli,
1
W rzeczywistości, kiedy przejdziesz do części książki o współbieżności, zaczniesz dość łatwo robić umiarkowanie znaczące rzeczy.
PO PROSTU MOJA poprawna OPINIA
„Model współbieżności Erlanga sprawia, że ​​przepływ logiki jest znacznie wyraźniejszy niż typowa współbieżność w stylu„ reaktora ”- argumentowałbym, że chociaż przetwarzanie asynchroniczne reaktora było rzeczywiście bałaganem przez dziesięciolecia, wraz z pojawieniem się przyszłości, a zwłaszcza oczekiwania operatora, nie jest sprawa już. Oczekiwanie może sprawić, że Twoje ultralekkie coroutine będą działały „jak gdyby”, są trochę jakby wątkami (i nie jestem pewien co do JS, ale w C ++ co_await jest zaprojektowany tak, aby skalować go nie tylko do tysięcy, ale do miliardów wybitnych coroutines).
No-Bugs Hare
„jest to obce myślenie, że Chambers Constant (99,44%)” - i w przypadku każdego projektu branżowego kwalifikuje się to jako problem z dużym tłuszczem. Ten wielki problem tłuszczu przetrwałby nawet, gdyby nie istniał obiektywny powód niepopularności języków funkcjonalnych (z czym się nie zgadzam, ale jest to zupełnie inna i długa historia).
No-Bugs Hare
10

Istnieje kilka istotnych różnic między Erlang a Węzłem

Po pierwsze, węzeł to Javascript, co oznacza, że ​​jest to bardzo popularny język, który ma wiele cech wspólnych z językami znanymi przez większą liczbę osób, więc zwykle łatwiej jest uruchomić. Erlang ma często dziwną i nieznaną składnię, a ponieważ język jest znacznie prostszy niż javascript, przyzwyczajenie się wymaga nieco więcej ze względu na jego wyjątkowość

Po drugie, Erlang ma bardzo szczególny model współbieżności współdzielenia niczego, wymaga to myślenia w inny sposób, aby rozwiązać problemy, co jest dobrą rzeczą (TM)

Ostatnią ważną kwestią jest to, że Erlang został opracowany przez firmę komercyjną i został otwarty po tym, że zaledwie dwa lata temu ludzie mogli zobaczyć indywidualne zatwierdzenia w kontroli źródła i nawet teraz nie sądzę, aby wszyscy programiści Erlang przeprowadzili się do publicznego repozytorium github za ich rozwój. node.js został wbudowany w społeczność od samego początku, co oznacza, że ​​jego obsługa społeczności jest znacznie lepsza, jest już o wiele więcej bibliotek dla węzła, więcej dokumentacji społeczności, więcej przykładów na żywo, wszechobecny menedżer pakietów itp. Erlang nadrabia zaległości pod tym względem, ale wciąż jest o wiele większa rampa do wstawania.

Węzeł pozwoli ci programować zabawne rzeczy dość szybko i stosunkowo bezboleśnie, wciąż rośnie ból w odniesieniu do dużych aplikacji, które Erlang rozwiązał od dłuższego czasu. Erlang zmieni sposób, w jaki programujesz i (imo) uczyni cię lepszym programistą, jednak na początku nie ułatwi ci życia. Oba są zabawne na różne sposoby.

Dale Harvey
źródło
2
Warto wspomnieć, że wątki Node również „nic nie udostępniają”.
Tamlyn