Навчання Ерлангу проти навчання node.js [закрито]

Я бачу багато лайно в Інтернеті про те, як Ерланг б'є попку node.js майже в кожній можливій категорії. Тож я хотів би дізнатися Ерланг і дати йому постріл, але ось проблема. Я знаходжу, що мені набагато важче підбирати Ерланг, ніж я збираю node.js. З node.js я міг вибрати відносно складний проект, і за день я щось працював. З Ерлангом я стикаюся з бар'єрами, і йду не так швидко.

Тож .. для тих, хто має більший досвід, чи Ерланг складний у навчанні, чи мені просто щось не вистачає? Node.js може бути не ідеальним, але, здається, я міг би це зробити.

Перш за все, я погоджуюсь з ПРОСТО МОЄМО правильною відповіддю на думку ЕРланг. Це здебільшого функціональна мова (хоча паралельність відіграє велику роль), і всі її особливості були додані для досягнення відмовостійкості та стійкості, що в першу чергу не є такими ж цілями дизайну, як Javascript.

По-друге, залишати Node.js потрапити в Ерланг дещо не так. Node.js - це єдиний сервер / фреймворк, який робить свій шлях робити все керованим подіями за допомогою зворотних викликів. У Erlang є своя структура (OTP), але вона зовсім не на одному рівні.

Якщо ви плануєте вивчати Ерланг, я пропоную свій запис у блозі Відкритий лист для початківця Ерланга (або Onlooker) як вступне читання перед тим, як зануритися в навчальні посібники.

Єдине, у чому можна порівняти Erlang та Node.js, з точки зору моделей та використання, - це те, як вони керуються подіями. Однак тут є дві великі різниці. Модель Node.js заснована на зворотних викликах, пов'язаних з подіями. Erlang заснований на черзі повідомлень та вибірковому отриманні. Які наслідки є там?

Перш за все, якщо ви робите речі на основі зворотного виклику, єдиний спосіб, коли ви переносите стан, - це або мати його глобальним, або перейти до програмування стилю продовження. По-друге, ви повинні піклуватися про повну матрицю подій самостійно. Одним із прикладів цього є те, що якщо ми уявляємо собі дуже просту машину з кінцевим станом: мутексний семафор, керований подіями.

Мутаксичний семафор має два стани: заблокований та вільний. Кожен раз, коли певна одиниця обчислення (працівник, процес, функція або потік) хоче отримати доступ до файлу mutex, вона повинна запустити подію, яка каже йому, що я зацікавлений. Тепер вам належить подбати про такі типи подій:

• Мутекс безкоштовний, і ви попросите отримати замок
• Мутекс заблокований кимось іншим, і ви хочете отримати замок
• Мютекс заблокований вами, і ви хочете звільнити його

Тоді вам слід врахувати додаткові події, такі як тайм-аут, щоб уникнути тупиків:

• Мутекс був заблокований, і ви занадто довго чекали, таймер відмовився від пожеж
• Мутекс був заблокований, і ви чекали занадто довго, дістали замок, після чого тайм-аут вимкнувся

Тоді ви також маєте позав'язані події:

• Ви просто заблокували мютекс, тоді як якийсь робітник очікував, що це буде безкоштовно. Тепер цей запит працівника повинен бути поставлений у чергу, щоб після його безкоштовного оброблення
• Потрібно зробити всю роботу асинхронною

Матриця подій дуже складна. Наш FSM тут має лише 2 штати. У випадку з Erlang (або будь-якою мовою з селективними прийманнями та асинхронізацією з потенційно синхронними подіями) вам потрібно подбати про кілька випадків:

• Мутекс безкоштовний, і ви попросите отримати замок
• Мутекс заблокований кимось іншим, і ви хочете отримати замок
• Мютекс заблокований вами, і ви хочете звільнити його

І це все. Таймери обробляються в тих же випадках, що і прийоми, і для всього, що має відношення до "зачекайте, поки воно буде безкоштовним", повідомлення автоматично ставлять у чергу: працівник повинен лише чекати відповіді. Модель у цих випадках набагато, набагато простіша.

Це означає, що в загальних випадках CPS і моделі на основі зворотного виклику, такі як одна в node.js, або просять вас бути дуже розумними в обробці подій, або просять вас подбати про всю складну матрицю подій в повному обсязі, оскільки вам потрібно передзвонити за кожним невпливним випадком, який виникає із-за дивних проблем із тимчасовим терміном та змін у стані.

Вибірковий прийом, як правило, дозволяє вам зосередитись лише на підгрупі всіх потенційних подій, і дозволяє міркувати з набагато більшою легкістю про події в цьому випадку. Зауважте, що Ерланг має поведінку (модель дизайну / реалізація рамки) чогось, що називається gen_event. Реалізація gen_event дозволяє вам мати механізм, дуже подібний до того, що використовується у node.js, якщо це те, що ви хочете.

Будуть і інші моменти, що їх розмежовують; У Erlang передбачено попереднє планування, в той час як node.js робить його кооперативним, Ерланг - більш придатний до деяких дуже масштабних додатків (дистрибуції та всіх), але Node.js та його спільнота зазвичай більш придатні для веб-пошуку та знають про останні тенденції веб-сторінок. Це питання вибору найкращого інструменту, і це залежатиме від вашого фону, типу проблеми та ваших уподобань. У моєму випадку модель Ерланга дуже добре відповідає моєму мисленню. Це не обов'язково так для всіх.

Сподіваюсь, це допомагає.

Ерланг не складний у навчанні, це просто чуже мисленню, що Постійні камери (99,44%) кодерів засвоїли, як працює програмування. Проблема, з якою ви стикаєтесь, швидше за все, є лише концептуальною дезорієнтацією, а не реальною складністю.

Ось деякі чужі особливості Ерланга, які збираються вкусити типового програміста:

• Erlang - це (переважно) функціональна мова програмування. Найбільш поширені мови програмування майже войовничо необхідні.
• Модель одночасності Ерланга - модель Актора. У більшості поширених мов програмування використовується різьблення на основі блокування, або якась форма "реакторного" підходу до паралельності. (Я думаю, що Node.js - це останній, але не дзвоніть мені на це - я не зацікавлений у JavaScript з будь-якої сторони відносин клієнт / сервер.)
• Ерланг має "нехай це збій" підхід до кодування з потужними функціями виконання, доступними для вловлювання цих збоїв, діагностики та гарячого виправлення під час роботи системи. Найбільш поширені мови програмування підтримують жорсткий стиль програмування.
• Ерланг майже, але не зовсім, нерозривно поєднаний з великою і м'яко скручуваною мозку бібліотекою часто використовуваних архітектур для надійних і стабільних серверів (OTP). (Є причина, чому Erlang зазвичай називають Erlang / OTP.) Далі ця бібліотека побудована на чужих функціях, згаданих раніше, і, таким чином, непрозора для новачків. Більшість мов програмування мають менше всеохоплюючих бібліотек (незважаючи на Java EE) для роботи з цими бібліотеками, природно, побудовані на концепціях, більш звичних більшості програмістів.

Отже, вивчення Erlang стане більшою проблемою для більшості програмістів, ніж вивчення Node.js - особливо якщо програміст вже знайомий з JavaScript. Зрештою, одразу після того, як ви перейдете концептуальний бар'єр, я стверджую, що кодування Erlang буде менш складним, ніж еквівалентне кодування Node.js. Це з кількох причин:

• Ерлангська модель паралельної валюти робить логічний потік набагато чіткішим, ніж типовий параметр «реактора», і робить паралельність набагато стійкішою та правильнішою, ніж типова паралельна параметри. Для програміста Erlang майже не існує жодної проблеми, щоб випустити буквально тисячі процесів у типову програму, в той час як упустити тисячі потоків, скажімо, на Java буде кошмаром суперечки (не кажучи вже про залучені накладні витрати на пам'ять і процесор) і еквівалент підтримання тисяч окремих станів у "реакторній" установці було б кошмаром для читання.
• Будучи функціональною мовою (в основному -), Ерланг - це налаштування "те, що ви бачите, те, що ви отримуєте". Після змінення змінні не змінюються. Колись. Немає жодної "моторошної дії на відстані" OOP, яка б вас бентежила: все, з чим ви працюєте, явно викладається перед вами. Немає успадкованих змінних від X і немає змінних класів від Y, а також глобальних змінних від Z не стосується себе. (Цей останній пункт не є на 100% правдою, але це правда в такій переважній кількості випадків, що це досить добре для вашого етапу навчання.)
• Потужні засоби, які має Erlang для обробки помилок, означають, що ви захаращуєте свій код менш захисним програмуванням, тим самим зберігаючи логіку чіткішою і зберігаючи код малим.
• Після того, як ви це зробите, бібліотека OTP - це шалено потужний стек загального коду, який регулярно підтримує весь ваш додаток і охоплює багато питань та випадків використання серверів довгоживу, про які ви, швидше за все, не подумаєте, поки не пізно. Сама бібліотека OTP є достатньо вагомим приводом для вивчення Ерланга.

Якщо ви можете, продовжуйте лозунги на Erlang, і якщо ви цього ще не зробили, завітайте до сайту Learn You Some Erlang for Great Good для ніжного і (в основному -) смішного ознайомлення з концепціями Ерланга.

Є кілька істотних відмінностей між Ерланом і Вузлом

Перший полягає в тому, що вузол - це Javascript, що означає, що це дуже поширена мова, яка має багато рис з мовами, якими знайома більшість людей, тому вставати та працювати, як правило, набагато простіше. Ерланг має для більшості часто дивний і незнайомий синтаксис, і хоча мова набагато простіша за javascript, до її унікальності потрібно трохи більше звикнути.

Друга полягає в тому, що в Ерланг є дуже конкретна модель, що не має нічого спільного, це вимагає, щоб ви вирішили проблеми по-іншому, що є хорошою справою (TM)

Останнє важливе - це те, що Erlang була розроблена комерційною компанією та була відкрита після того, як це було лише 2 роки тому, або люди могли насправді бачити окремі комісії в контролі джерел, і навіть зараз я не думаю, що всі розробники erlang переїхали до публічного github repo для їх розвитку. node.js був побудований всередині спільноти з самого початку, це означає, що його підтримка громади набагато краща, вже існує набагато більше бібліотек для вузла, більше документації для спільноти, більше живих прикладів, всюдисущий менеджер пакунків тощо. Ерланг наздоганяє в цьому плані, але його все ще набагато більша рампа, щоб встати.

Вузол дозволить вам програмувати забавні речі досить швидко і відносно безболісно, ​​він все ще відчуває біль у зв'язку з великими програмами, які Erlang вирішив давно. Ерланг змінить те, як ви програмуєте, і (imo) зробить вас кращим програмістом, однак це не буде полегшувати вам життя на початку. Обидва розважаються по-різному.