Я пока очень мало сделал с Азотом, но я уже несколько месяцев слежу за списком рассылки, поэтому думаю, что мне есть что сказать об этом.
На ваше беспокойство по поводу синтаксиса Erlang и структуры Nitrogen я бы ответил, что это звучит как чистый случай незнакомства, а не непригодности. Объективно, HTML не является красивым языком, и у него есть много причуд. Вы привыкли к этому сейчас, так что это не так уж плохо. Дайте азоту / Эрлангу шанс, и вы тоже сможете быстро к этому привыкнуть.
На ваш вопрос о сравнении с другими языками и фреймворками я бы сказал, что самое большое отличие состоит в том, что с Nitrogen весь веб-сайт обслуживается непосредственно средой выполнения Erlang. В Ruby on Rails есть такой режим, но он предназначен только для тестирования. Многие другие фреймворки даже не предлагают возможность запуска всего в течение одного длительного процесса.
Запуск всего веб-приложения и его базовой инфраструктуры в рамках одного длительного процесса имеет существенные последствия для работы сайта:
При использовании Apache каждый дочерний элемент уничтожается через каждые N соединений, где N = 500 или около того, и вы не можете сказать, будет ли данный дочерний процесс всегда обрабатывать все запросы данного клиента. Поскольку HTTP не имеет состояния, но веб-приложения почти всегда требуют определенного состояния клиента, дочерний элемент Apache должен перестроить свое представление о состоянии клиента как часть обработки нового соединения. По умолчанию это означает возврат на диск для постоянных данных, хранящихся об этом клиенте. Существуют альтернативы, такие как memcached , но они не встроены в ядро стека типа LAMP. С Erlang ничто не прерывается периодически, и Erlang предлагает стандартные средства, такие как Mnesia, которые предоставляют дисковые БД в оперативной памяти.
Кстати, если вы знакомы с nginx , он построен на тех же принципах, что и Erlang, и работает быстро по той же причине. Основное различие между nginx и экземпляром Erlang, работающим на веб-сервере, заключается в том, что nginx не является средой программирования, поэтому ему все еще приходится делегировать большую часть обработки внешнему коду. Это означает, что у него тот же IPC и постоянные проблемы с состоянием, что и у Apache.
Поскольку среда выполнения постоянно работает и является полнофункциональной средой программирования, вы, вероятно, сможете собрать больше компонентов вашей системы в Erlang, чем с помощью стека LAMP-типа. Это увеличивает вышеуказанные преимущества. Различные части вашей системы могут координировать свои действия посредством передачи сообщений и Mnesia вместо мощных IPC и MySQL, и все компоненты постоянно работают и работают, что приводит к сокращению времени восстановления состояния.
Десяток или около того детей Apache, которые все получают доступ к постоянному хранилищу данных о состоянии клиента, - это шарик на основе блокировки. Все фреймворки прозрачно обрабатывают блокировку и тому подобное для вас, но то, что они не могут скрыть, это время, которое требуется, чтобы все это сделать правильно.
Erlang - это нечистый функциональный язык, который подразумевает, но не требует чистоты данных; он также построен с учетом многопроцессорности, что делает его более понятным для ядра среды исполнения. Эти два факта означают, что вы с меньшей вероятностью будете тратить время на ожидание блокировок на сервере на основе Erlang, чем наивный, построенный на одной из других платформ. Конечно, можно оптимизировать задержки блокировки в других системах, но действительно ли это то, что вы хотите делать? Хотите ли вы быть в тысячной команде, которая должна научиться оптимизировать свой веб-стек после того, как сервис станет популярным, или вы бы предпочли оставить все это инструментам, чтобы вы могли тратить свое время на то, что еще никто не делал?