Яка відповідь Haskell на Node.js?

Я вважаю, що спільнота Erlang не заздрить Node.js, оскільки вона не блокує введення-виведення вихідних даних і має способи легко масштабувати розгортання на більш ніж один процесор (щось навіть не вбудовано в Node.js). Детальніше на http://journal.dedasys.com/2010/04/29/erlang-vs-node-js та Node.js або Erlang

Що з Haskell? Чи може Haskell надати деякі переваги Node.js, а саме чисте рішення, щоб уникнути блокування вводу / виводу без використання багатопотокового програмування?

З Node.js є багато привабливих речей

1. Події: Ні маніпулювання потоком, програміст надає лише зворотні дзвінки (як у Snap Framework)
2. Гарячі зворотні дзвінки гарантовано будуть виконані в один потік: не можливі умови перегонів.
3. Приємний і простий API UNIX. Бонус: Відмінна підтримка HTTP. Також доступний DNS.
4. Кожен I / O за замовчуванням асинхронний. Це полегшує уникнення замків. Однак занадто велика обробка процесора в зворотному дзвінку вплине на інші з'єднання (у цьому випадку завдання має розділитися на менші підзадачі та переплановано).
5. Однакова мова для клієнтської та серверної. (Я не бачу надто великого значення в цій, але jQuery і Node.js поділяють модель програмування подій, але решта дуже відрізняється. Я просто не бачу, як міг ділитися кодом між стороною сервера та клієнтом. бути корисним на практиці.)
6. Все це упаковано в один продукт.

Добре, тому переглянувши трохи презентації node.js, на яку @gawi вказував мені, я можу сказати трохи більше про те, як Haskell порівнюється з node.js. У презентації Райан описує деякі переваги "Зелених ниток", але далі говорить, що не вважає відсутність абстракції нитки недоліком. Я не погоджуюся з його позицією, особливо в контексті Haskell: Я вважаю, що абстракції, які надаються потоками, мають важливе значення для полегшення отримання коду сервера і більш надійного. Зокрема:

• використання одного потоку за з'єднання дозволяє писати код, що виражає зв'язок з одним клієнтом, а не код запису, який одночасно стосується всіх клієнтів. Подумайте про це так: сервер, який обробляє декілька клієнтів з потоками, виглядає майже так само, як той, який обробляє одного клієнта; головна відмінність - forkдесь у колишньому. Якщо протокол, який ви реалізуєте, зовсім складний, управління державною машиною для декількох клієнтів одночасно стає досить складним, тоді як потоки дозволяють просто сценарій спілкування з одним клієнтом. Код простіше правильно підібрати, і простіше зрозуміти та підтримувати.

• Зворотні виклики на одному потоці ОС - це спільна багатозадачність, на відміну від попередньої багатозадачності, що саме ви отримуєте з потоками. Основним недоліком кооперативного багатозадачності є те, що програміст відповідає за те, щоб не було голоду. Він втрачає модульність: помиляється в одному місці, і це може викрутити всю систему. Це дійсно те, про що ви не хочете турбуватися, а виплата - це просте рішення. Більше того, зв’язок між зворотними дзвінками неможливий (це буде тупиком).

• паралельність не є складною в Haskell, тому що більшість кодів є чистими, а тому конструкція безпечна для потоків. Є прості комунікативні примітиви. Набагато складніше застрелити себе в ногу з одночасністю в Haskell, ніж мовою з необмеженими побічними ефектами.

Чи може Haskell надати деякі переваги Node.js, а саме чисте рішення, щоб уникнути блокування вводу / виводу без використання багатопотокового програмування?

Так, насправді події та теми об'єднані в Haskell.

• Ви можете програмувати в явних легких потоках (наприклад, мільйони ниток на одному ноутбуці).
• Або; Ви можете запрограмувати в стилі асинхронного події на основі сповіщення про масштабовані події.

Нитки фактично реалізовані з погляду подій та проходять через декілька ядер, безперебійну міграцію потоків, із задокументованою продуктивністю та програмами.

Напр

• масово паралельна організація роботи
• одночасний збір масштабування на 32 або 48 ядер
• підтримка інструментів для профілювання та налагодження багатопотокових / багатопотокових програм .
• висока продуктивність керованої подіями веб - серверів .
• цікаві користувачі: такі як високочастотна торгівля .

Одночасні колекції нікого на 32 ядра

У Haskell у вас є і події, і теми, і як і всі події під кришкою.

Прочитайте документ, що описує реалізацію.

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

Події: Ні маніпулювання потоком, програміст надає лише зворотні дзвінки (як у Snap Framework)

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

Гарячі зворотні дзвінки гарантовано будуть виконані в один потік: не можливі умови перегонів.

Ви все ще можете мати стан перегонів у node.js, але це складніше.

Кожен запит - це власна тема. Коли ви пишете код, який повинен зв’язуватися з іншими потоками, дуже просто зробити його безпечним для потоків завдяки примітивним примітивам Haskell.

Приємний і простий API UNIX. Бонус: Відмінна підтримка HTTP. Також доступний DNS.

Погляньте на злом і переконайтеся самі.

Кожен ввід / вивід за замовчуванням є асинхронним (хоча це часом може дратувати). Це полегшує уникнення замків. Однак занадто велика обробка процесора в зворотному дзвінку вплине на інші з'єднання (у цьому випадку завдання має розділитися на менші підзадачі та переплановано).

У вас немає таких проблем, ghc розподілить вашу роботу серед реальних потоків ОС.

Однакова мова для клієнтської та серверної. (Я не бачу занадто великої цінності в цій. Однак JQuery і Node.js поділяють модель програмування подій, але решта дуже відрізняється. Я просто не бачу, як міг ділитися код між стороною сервера та клієнтом. бути корисним на практиці.)

Haskell тут не може перемогти ... правда? Подумайте ще раз, http://www.haskell.org/haskellwiki/Haskell_in_web_browser .

Все це упаковано в один продукт.

Завантажте ghc, підпаліть кабал. Є пакет на кожну потребу.

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

Тим часом час роботи GHC сильно покращився: тепер він має "нового нового менеджера вводу- виводу" під назвою MIO, де "M" означає багатоядерний я вірю. Він будується на основі існуючого менеджера вводу-виводу і його головна мета - подолати причину погіршення продуктивності ядер 4+. Показники продуктивності, представлені в цій роботі, є досить вражаючими. Побачити себе:

Завдяки Mio реалістичні HTTP-сервери в масштабі Haskell до 20 процесорних ядер, що досягають пікової продуктивності до коефіцієнта 6,5x порівняно з тими ж серверами, що використовують попередні версії GHC. Також покращується затримка серверів Haskell: [...] при помірному навантаженні скорочує очікуваний час реакції на 5,7 разів порівняно з попередніми версіями GHC

І:

Ми також показуємо, що за допомогою Mio, McNettle (контролер SDN, написаний на Haskell) може ефективно масштабувати до 40 ядер, досягти досконалої потужності понад 20 мільйонів нових запитів в секунду на одній машині, а отже, стати найшвидшим з усіх існуючих контролерів SDN .

Mio ввійшов до випуску GHC 7.8.1. Я особисто бачу це як головний крок вперед у виконанні Haskell. Було б дуже цікаво порівняти продуктивність існуючих веб-додатків, складених попередньою версією GHC та 7.8.1.

ІМХО події хороші, але програмування за допомогою зворотних викликів - ні.

Більшість проблем, що викликають особливе кодування та налагодження веб-додатків, пов’язані з тим, що робить їх масштабованими та доступними. Найважливіший, бездержавний характер HTTP. Це підвищує керованість, але це накладає інверсію управління, де елемент IO (в цьому випадку веб-сервер) викликає різні обробники в коді програми. Ця модель події - або точніше сказана модель зворотного виклику - кошмар, оскільки зворотні виклики не поділяють змінні області застосування, і інтуїтивно зрозумілий режим навігації втрачається. Серед інших проблем дуже важко запобігти всі можливі зміни стану, коли користувач переміщається вперед і назад.

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

Існують послідовні основи, такі як ocsigen (ocaml) узбережжя (smalltalk) WASH (припинено, Haskell) та mflow (Haskell), які вирішують проблему управління державою при збереженні судноплавності та повноти REST. У цих рамках програміст може виражати навігацію як імперативну послідовність, коли програма надсилає сторінки та чекає відповідей в одному потоці, змінні знаходяться в області застосування, а кнопка "назад" працює автоматично. Це по суті створює коротший, більш безпечний і читабельний код, де навігація чітко видна програмісту. (справедливе попередження: я розробник mflow)

Питання є досить смішним, оскільки 1) Haskell вже вирішив це питання набагато кращим чином і 2) приблизно таким же чином, як і Ерланг. Ось орієнтир проти вузла: http://www.yesodweb.com/blog/2011/03/prepreme-warp-cross-language-benchmarks

Дайте Haskell 4 ядра, і він може робити 100 к (простих) запитів за секунду в одній програмі. Вузол не може виконати стільки і не може масштабувати одну програму по ядрах. І вам не доведеться нічого робити, щоб скористатися цим, оскільки час виконання Haskell не блокує. Єдиною іншою (відносно поширеною) мовою, яка має незаблокований IO, вбудований у час виконання, - Erlang.

Так само , як nodejs впав libev Прив'язати Haskell Web Framework впав libev теж.