Каков ваш опыт работы с азотом на Erlang?

Question

я проверял Азотный проект который считается наиболее зрелой средой веб-разработки для Erlang.

Эрланг как язык чрезвычайно впечатляет.Однако, что касается Nitrogen, то мне не очень нравится использовать довольно необычный синтаксис Erlang (если только вы не являетесь пользователем PROLOG) для создания пользовательских интерфейсов.

Каков ваш опыт работы с ним по сравнению с другими Основной поток веб-фреймворки, такие как Django или Rails?

Answer 1

Пока что я очень мало сделал с Nitrogen, но слежу за списком рассылки уже несколько месяцев, поэтому думаю, что могу сказать по этому поводу что-то полезное.

На ваше беспокойство по поводу синтаксиса Erlang и платформы Nitrogen я бы ответил, что это скорее похоже на незнание, а не на непригодность.Объективно HTML не является красивым языком, и у него есть множество особенностей.Теперь ты к этому привык, так что это не кажется таким уж плохим.Дайте Nitrogen/Erlang шанс, и вы, возможно, тоже быстро к нему привыкнете.

На ваш вопрос о сравнении с другими языками и платформами, я бы сказал, что самая большая разница заключается в том, что с Nitrogen весь веб-сайт обслуживается непосредственно средой выполнения Erlang.В Ruby on Rails такой режим есть, но он предназначен только для тестирования.Многие другие платформы даже не предлагают возможности запускать все в рамках одного длительного процесса.

Запуск всего веб-приложения и его базовой инфраструктуры в рамках одного длительного процесса существенно влияет на работу сайта:

• В Apache каждый дочерний элемент уничтожается при каждом N соединении, где N=500 или около того, и вы не можете сказать, будет ли данный дочерний элемент всегда обрабатывать все запросы данного клиента.Поскольку HTTP не имеет состояния, а веб-приложениям почти всегда требуется некоторое состояние клиента, дочерний элемент Apache должен перестроить свое представление о состоянии клиента в рамках обработки нового соединения.По умолчанию это означает возврат к диску для хранения постоянных данных об этом клиенте.Есть альтернативы, например кэширование памяти, но они не встроены в ядро ​​стека типов LAMP.В Erlang ничего не отключается периодически, и Erlang предлагает стандартные средства, такие как Mnesia, которые предоставляют базы данных в памяти с резервным копированием на диск.

  Кстати, если вы знакомы nginx, он построен на тех же принципах, что и Erlang, и по той же причине он быстр.Основное различие между nginx и экземпляром Erlang, на котором работает веб-сервер, заключается в том, что nginx не является средой программирования, поэтому ему все равно приходится делегировать большую часть обработки внешнему коду.Это означает, что у него те же проблемы IPC и постоянного состояния, что и у Apache.

• Поскольку среда выполнения работает непрерывно и представляет собой полнофункциональную среду программирования, вы, вероятно, сможете создать больше частей своей системы на Erlang, чем с помощью сплетенного стека типов LAMP.Это усиливает вышеуказанные преимущества.Различные части вашей системы могут координироваться посредством передачи сообщений и Mnesia вместо тяжеловесного IPC и MySQL, и все части остаются в рабочем состоянии постоянно, что приводит к менее трудоемкому восстановлению состояния.

• Около дюжины детей Apache, имеющих доступ к постоянному хранилищу данных о состоянии клиента, представляют собой комок волос на основе блокировки.Все фреймворки прозрачно обрабатывают блокировки и тому подобное, но они не могут скрыть, сколько времени требуется, чтобы сделать все это правильно.

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

Answer 2

Я тоже когда-то был обеспокоен синтаксисом Clunky Erlang. Я построил пару инструментов для облегчения его раздражения для повседневных веб-программирования, и, возможно, вы найдете один или оба из них полезны:

• Erlydtl. является реализацией Erlang языка шаблона Django; Он не доступен в азоте, но он доступен в других рамках, таких как Zotonic, Erlang Web, Beepbeep и Chicago Boss

• Чикагский босс Является ли Full-State Erlang Framework, которая делает много генерации кода, чтобы вы могли получить доступ к полям данных с функциональными вызовами вместо синтаксиса довольно многословных записей Erlang (например, Person:name() вместо Person#person.name)

Обратите внимание, что азот не включает в себя слой базы данных, поэтому он не совсем сопоставим с рельсами или Django. Для всестороннего сравнения базы данных, ориентированных на базе данных, проверьте мой ответ на этот вопрос Stackoverflow:

https://stackoverflow.com/questions/1822518/current-state-of-erlang-web-development-frameworks-template-languages/2898271.

Answer 3

Я бы проверил WebMachine. на твоем месте. Это довольно просто, быстро и покидает интерфейс к вам.

Answer 4

Erlang web. также следует считать зрелыми. Это каркас MVC, в то время как азот больше событий на основе событий. Это вопрос предпочтений.

Я не использовал другие инструменты, упомянутые здесь, кроме WebMachine, которые, я думаю, это замечательный инструмент, но это не веб-каркас, как другие. Это как HTTP-процессор и идеально подходит для создания реставральных интерфейсов.

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