¿Cuál es tu experiencia con el nitrógeno en Erlang?
web-frameworks nitrogen (4)
He hecho muy poco con Nitrogen hasta ahora, pero he estado monitoreando la lista de correo durante meses, así que creo que tengo algo útil que decir al respecto.
A su preocupación sobre la sintaxis de Erlang y el marco de Nitrógeno, respondía que eso suena como un caso puro de falta de familiaridad, más que de inadecuación. Objetivamente, HTML no es un lenguaje hermoso, y tiene muchas peculiaridades. Estás acostumbrado a esto ahora, así que no parece tan malo. Dale una oportunidad a Nitrogen / Erlang y puedes encontrar que te acostumbras muy pronto también.
Para su pregunta sobre la comparación con otros lenguajes y marcos, diría que la mayor diferencia es que con Nitrogen, todo el sitio web está siendo atendido directamente por el tiempo de ejecución de Erlang. Ruby on Rails tiene este modo, pero está destinado solo para pruebas. Muchos otros frameworks ni siquiera ofrecen la opción de ejecutar todo en un solo proceso de larga ejecución.
La ejecución de toda la aplicación web y su infraestructura subyacente en un solo proceso de larga ejecución tiene implicaciones significativas sobre cómo se ejecuta el sitio:
Con Apache, cada niño muere en cada N conexiones, donde N = 500 o menos, y no puede decir si un niño dado siempre manejará todas las solicitudes de un cliente dado. Debido a que HTTP no tiene estado, pero las aplicaciones web casi siempre requieren algún estado del cliente, un hijo de Apache debe reconstruir su visión del estado del cliente como parte del manejo de una nueva conexión. De forma predeterminada, esto significa volver al disco para los datos persistentes almacenados sobre ese cliente. Existen alternativas como memcached , pero estas no están integradas en el núcleo de una pila de tipo LAMP. Con Erlang, nada se elimina periódicamente, y Erlang ofrece instalaciones estándar como Mnesia que proporcionan DBs en memoria con respaldo de disco.
Por cierto, si está familiarizado con nginx , está basado en los mismos principios que Erlang, y es rápido por la misma razón. La principal diferencia entre nginx y una instancia de Erlang que ejecuta un servidor web es que nginx no es un entorno de programación, por lo que todavía tiene que delegar mucho procesamiento a código externo. Eso significa que comparte el mismo IPC y los problemas de estado persistente que Apache.
Debido a que el tiempo de ejecución se mantiene activo continuamente y es un entorno de programación completamente funcional, es probable que pueda construir más partes de su sistema en Erlang que con una pila de tipo LAMP atada juntas. Esto magnifica los beneficios anteriores. Las diversas partes de su sistema pueden coordinarse mediante el paso de mensajes y Mnesia en lugar de IPC y MySQL de peso pesado, y todas las piezas se mantienen en funcionamiento continuamente, lo que lleva a una reconstrucción del estado que requiere menos tiempo.
Una docena de niños Apache que acceden al almacén de datos del estado del cliente persistente es una bola de pelo basada en bloqueo. Todos los marcos manejan el bloqueo y lo mismo para usted de forma transparente, pero lo que no pueden ocultar es el tiempo que lleva hacer todo esto correctamente.
Erlang es un lenguaje funcional impuro, que implica pero no requiere pureza de datos; También está construido con multiprocesamiento en mente, yendo claro hasta el núcleo del diseño del tiempo de ejecución. Estos dos hechos significan que es menos probable que pases el tiempo esperando en bloqueos en un servidor basado en Erlang que uno ingenuamente construido en uno de los otros marcos. Ciertamente, es posible optimizar los retrasos de bloqueo en otros sistemas, pero ¿es eso realmente lo que quiere hacer? ¿Desea estar en el milésimo equipo que tiene que aprender a optimizar su pila web después de que el servicio se haga popular, o preferiría dejarlo todo en manos de las herramientas para que pueda dedicar su tiempo a hacer algo que nadie más haya hecho? ?
He estado revisando el Proyecto de Nitrógeno, que se supone es el marco de desarrollo web más maduro para Erlang.
Erlang, como lenguaje, es extremadamente impresionante. Sin embargo, con respecto a Nitrogen, lo que no me interesa es utilizar la sintaxis poco común de Erlang (a menos que sea nativo en PROLOG) para crear interfaces de usuario.
¿Cuál es su experiencia con él en comparación con otros marcos web generales como Django o Rails?
Yo, una vez, también me preocupé por la sintaxis de Erlang. He desarrollado un par de herramientas para aliviar sus molestias en la programación web diaria, y quizás encuentre útil una o ambas:
ErlyDTL es una implementación de Erlang del lenguaje de plantillas de Django; no está disponible en Nitrogen, pero está disponible en otros marcos, como Zotonic, Erlang Web, BeepBeep y Chicago Boss
Chicago Boss es un marco de Erlang de pila completa que genera una gran cantidad de código para que pueda acceder a los campos de datos con llamadas de función en lugar de la sintaxis de registros bastante detallados de Erlang (por ejemplo,
Person:name()lugar dePerson#person.name)
Tenga en cuenta que Nitrogen no incluye una capa de base de datos, por lo que no es realmente comparable a Rails o Django. Para obtener una comparación completa de los marcos basados en bases de datos, consulte mi respuesta a esta pregunta de :
Echaría un vistazo a Webmachine si fuera usted. Es bastante simple, rápido y te deja la interfaz a ti.
Erlang web también debe ser considerado maduro. Es un marco MVC, mientras que Nitrogen está más basado en eventos. Es una cuestión de preferencia.
No he usado las otras herramientas mencionadas aquí, excepto Webmachine, que creo que es una herramienta maravillosa, pero no es un marco web como los demás. Es como procesador HTTP, y es ideal para construir interfaces relajadas.
También te sugiero que le des una oportunidad a la sintaxis de Erlang. Erlang es uno de mis idiomas favoritos para usar.