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

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ć.

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.

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.

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.