Node.js или Erlang

86

Мне очень нравятся эти инструменты, когда дело касается уровня параллелизма, с которым они могут справиться.

Erlang / OTP выглядит гораздо более стабильным решением, но требует гораздо большего изучения и глубокого погружения в парадигму функционального языка. И похоже, что Erlang / OTP делает его намного лучше, когда речь идет о многоядерных процессорах (поправьте меня, если я ошибаюсь).

Но что мне выбрать? Какой из них лучше в краткосрочной и долгосрочной перспективе?

Моя цель - изучить инструмент, который упрощает масштабирование моих веб-проектов при высокой нагрузке по сравнению с традиционными языками.

user80805
источник
Вы можете использовать JavaScript в качестве функционального языка с underscorejs.org
Тодд Мозес
2
@ToddMoses, вы уверены, что прокомментировали правильный вопрос?
Флавьен Волкен
Яблоки и апельсины. Node.JS (по своей сути) является взаимодействием libevent (C) + Javascript. Erlang - это полностью настраиваемая реализация ввода-вывода. Node.JS предназначен для однопоточных приложений. Ваша проблема в том, хотите ли вы работать в Facebook / Google, или вы хотите создать отличное программное обеспечение.
Vans S

Ответы:

87

Я бы попробовал Erlang. Несмотря на то, что это будет более крутая кривая обучения, вы получите от нее больше, поскольку вы будете изучать функциональный язык программирования. Кроме того, поскольку Erlang специально разработан для создания надежных систем с высокой степенью параллелизма, вы узнаете много нового о создании одновременно высокомасштабируемых сервисов.

Джастин Этье
источник
10
Я не думаю, что Erlang немного сложнее Javascript. В Erlang нет наследования любого типа, поэтому вы всегда уверены, какую функцию вызываете. В Erlang нет неявного преобразования типов, поэтому вы всегда уверены, какие типы данных используете. Здесь нет деструктивного присваивания, поэтому вы всегда уверены, что какой-то старый фрагмент кода не сломается, потому что какой-то новый код в обратном вызове изменил ваше внутреннее состояние.
Дмитрий Беляев
51

Я не могу говорить от имени Erlang, но кое-что, что не упоминалось об узле:

  • Node использует движок Google V8 для компиляции javascript в машинный код. Итак, узел на самом деле довольно быстрый. Это в дополнение к преимуществам скорости, предлагаемым программированием, управляемым событиями, и неблокирующим io.
  • У Node довольно активное сообщество. Зайдите в их IRC-группу на freenode, и вы поймете, о чем я
  • Я заметил, что приведенные выше комментарии подталкивают Erlang на том основании, что будет полезно изучить функциональный язык программирования. Хотя я согласен с тем, что важно расширить свой набор навыков и получить один из них за плечами, вы не должны основывать проект на том факте, что хотите изучить новый стиль программирования.
  • С другой стороны, Javascript уже находится в парадигме, в которой вам комфортно писать! Кроме того, это javascript, поэтому, когда вы пишете код на стороне клиента, он будет выглядеть согласованно.
  • Сообщество node уже накачало тонны модулей ! Есть модули для redis, mongodb, couch и всего, что у вас есть. Еще один хороший модуль, на который стоит обратить внимание, - это Express (подумайте о Sinatra для узла).

Посмотрите видео в блоге yahoo от Райана Даля, парня, который на самом деле написал node. Я думаю, это поможет вам лучше понять, где находится узел и куда он движется.

Имейте в виду, что узел все еще находится на поздних стадиях разработки, поэтому претерпел довольно много изменений - изменений, которые нарушили предыдущий код. Однако, предположительно, это тот момент, когда вы можете ожидать, что API не изменится слишком сильно. Так что, если вы ищете что-то забавное, я бы сказал, что node - отличный выбор.

Ярсен
источник
26
Я думаю, что движок V8 компилирует JavaScript в машинный код, а не в сборку.
Jonas
10
Так много работы, проделанной с Javascript, не делает этот язык даже немного подходящим для решения сложных проблем. Сам язык ужасен со всеми этими частными случаями преобразования типов. И стиль обратного вызова, когда переменные меняются в сотнях разных мест, и черт возьми, ища место, где произошло какое-то присвоение.
Дмитрий Беляев
15

Я давний программист на Erlang, и этот вопрос побудил меня взглянуть на node.js. Выглядит чертовски хорошо.

Похоже, что вам нужно создать несколько процессов, чтобы использовать преимущества нескольких ядер. Однако я ничего не вижу о настройке сходства процессора. Вы можете использовать набор задач в Linux, но он, вероятно, должен быть параметризован и установлен в программе.

Я также заметил, что поддержка платформы может быть немного слабее. В частности, похоже, что вам нужно будет запустить Cygwin для поддержки Windows.

Хотя выглядит неплохо.


редактировать

Node.js теперь имеет встроенную поддержку Windows.

dsmith
источник
5
Этот ответ немного устарел. Прямо сейчас Node кроссплатформенный, нет необходимости в Cygwin для Windows. И Node имеет встроенную поддержку кластеризации на одной машине, разделяя сокеты TCP.
Фарид Нури Нешат
9

Я смотрю на те же две альтернативы, что и вы, для нескольких проектов.

Пока что лучшая бритва, которую я придумал, чтобы выбрать между ними для конкретного проекта, - это то, нужно ли мне использовать Javascript. Одна существующая система, которую я хочу перенести, уже написана на Javascript, поэтому ее следующая версия, вероятно, будет создана в node.js. Другие проекты будут реализованы в некоторой веб-платформе Erlang, потому что нет существующей базы кода для миграции.

Другое соображение заключается в том, что Erlang масштабируется не только на несколько ядер, он может масштабироваться до всего центра обработки данных. Я не вижу встроенного механизма в node.js, который позволяет мне отправлять другому JS-процессу сообщение, не заботясь о том, на какой машине он находится, но он встроен прямо в Erlang на самых низких уровнях. Если ваша проблема недостаточно велика, чтобы требовать нескольких машин, или если она не требует нескольких взаимодействующих процессов, это преимущество вряд ли будет иметь значение, поэтому вам следует игнорировать его.

Erlang - действительно глубокий бассейн, в который стоит погрузиться. Я бы предложил сначала написать автономную функциональную программу, прежде чем вы начнете создавать веб-приложения. Еще более простой первый шаг, поскольку вам кажется, что вам комфортно работать с Javascript, - это попробовать программировать JS в более функциональном стиле. Если вы используете jQuery или Prototype, вы уже пошли по этому пути. Попробуйте переключаться между чисто функциональным программированием на Erlang или одном из его аналогов (Haskell, F #, Scala ...) и функциональным JS.

Когда вы освоитесь с функциональным программированием, поищите одну из многих веб-фреймворков Erlang; вам, вероятно, не следует писать свое приложение напрямую для чего-то низкого уровня, например, inetsна этой поздней стадии. Взгляните, например, на что-нибудь вроде азота .

Уоррен Янг
источник
Часто не упоминается, что точка «Эрланг масштабируется до всего центра обработки данных» имеет несколько очень важных моментов, которые следует учитывать (безопасность - это большая проблема). Прочтите
jocull
9

Хотя я лично выбрал бы Erlang, я признаю, что немного предвзято отношусь к JavaScript. Я советую вам оценить несколько пунктов:

  1. Вы повторно используете существующий код на любом из этих языков (как с точки зрения исходного кода, так и с точки зрения опыта программиста!)
  2. Вам нужны / вы хотите обновления на лету без остановки приложения (именно здесь Erlang побеждает по умолчанию - его среда выполнения была разработана для этого случая, а OTP содержит все необходимые инструменты)
  3. Насколько велик ожидаемый трафик с точки зрения отдельных одновременных операций, а не полосы пропускания?
  4. Насколько «параллельны» операции, которые вы выполняете для каждого запроса?

Erlang имеет действительно отлаженную параллельную работу и прозрачную для сети параллельную распределенную систему. В зависимости от того, что именно представляет собой проект, наличие зрелой реализации такой системы может перевесить любые проблемы, связанные с изучением нового языка. Есть также два других языка, которые работают с Erlang VM, которые вы можете использовать, Ruby / Python-like Reia и Lisp-Flavored Erlang .

Еще один вариант - использовать оба, особенно когда Erlang используется как своего рода «хаб». Я не уверен, есть ли в Node.js система интерфейса внешних функций, но если она есть, в Erlang есть библиотека C для внешних процессов, которые взаимодействуют с системой, как и любой другой процесс Erlang.

p_l
источник
Согласно документации, Node.js может использовать C и C ++ для внешних надстроек. nodejs.org/docs/v0.3.1/api/addons.html
Эван Плэйс,
Похоже, Рея умерла, но на ее месте эликсир ... он напоминает мне Groovy и Java; вот это были бы Эликсир и Эрланг.
Stommepoes
@EvanPlaice - Меня это не особо впечатляет. Дело в том, что вы в основном кодируете проблемную вещь на C ++ и добавляете их как встроенные. На самом деле FFI не так уж и сильно расширяет эмулятор. (Хорошо, личные предпочтения;)) Упомянутая внешняя библиотека в случае erlang предназначена для создания асинхронных процессов на других языках, которые отображаются как узлы ИЛИ, которые общаются через открытый порт (подумайте о двунаправленном канале со структурированными данными). Все это прекрасно вписывается в асинхронный режим работы. Существуют также NIF, которые, по сути, есть в Node.js, но не рекомендуется.
p_l
1
@p_l Насколько я понимаю, узловой подход немного отличается. Хотя узел очень хорошо справляется с обработкой асинхронных вызовов ввода-вывода (т.е. веб-запросов), он работает в однопоточной среде. Так что он отлично справляется с диспетчеризацией, но не так хорош для обработки, требующей интенсивного использования ЦП. Чтобы решить эту проблему, вы можете выделить другой процесс / поток, который выполняет собственный код C / C ++. Если все, что вы делаете, это вызовы асинхронного ввода-вывода (например, IPC | двунаправленные каналы), то node.js должен справиться с нагрузкой. Пока это не закодировано, чтобы тратить много времени на ожидание синхронных вызовов.
Evan Plaice
5

Похоже, что Erlang лучше подходит для развертывания на сервере относительно низкого уровня (512 МБ 4-ядерной виртуальной машины AMD 2,4 ГГц). Это из опыта SyncPad по сравнению реализаций Erlang и Node.js их серверного приложения виртуальной доски.

адиб
источник
2
Да, у node.js, похоже, есть неприятная проблема с утечкой памяти. Node довольно новый и экспериментальный, и ни JavaScript, ни движок V8 не были разработаны для таких серверных сценариев. С другой стороны, Erlang был разработан именно для этого снизу вверх, и ему потребовалось много лет, чтобы усовершенствовать себя и повзрослеть.
Rolf
2
Эта ссылка кажется мертвой, но вот она на WayBackMachine web.archive.org/web/20120902014555/http://blog.mysyncpad.com/…
jocull
4

На той же виртуальной машине есть еще один язык, что и erlang -> Elixir

Это очень интересная альтернатива Erlang, посмотрите эту.

Также у него есть быстрорастущий веб-фреймворк на его основе-> Phoenix Framework

NoDisplayName
источник
0

Я предпочитаю Erlang Node. Если вам нужен параллелизм, Node можно заменить на Erlang или Golang из-за их легких процессов.

Erlang нелегко изучить, поэтому требуется много усилий, но его сообщество активно, поэтому вы можете получить от этого помощь, это только причина, по которой люди предпочитают Node.

Сумит Пугалия
источник