¿Es Erlang una buena opción de idioma para sistemas críticos de rendimiento en comparación con Scala y Go? ¿Por qué tenemos casos de, por ejemplo, Twitter migrando de RoR a Scala? ¿Podría ser porque Scala es más “amigable” cuando se trata de sintaxis?

En primer lugar, ¡apoyo totalmente la respuesta de Ngoc Doc!

En segundo lugar, Erlang ya se usa para aplicaciones críticas de rendimiento, y lo usaría en un instante sobre Go y Scala para mis propios proyectos (como lo demuestra mi historial de confirmación de github).

En tercer lugar, también vivo en el mundo real y tengo que lograr resultados. Incluso en mi empresa, donde establecí la dirección de la tecnología mucho, elegí Ir. No es que no me hubiera encantado usar Erlang, y no pasa un día en que no quisiera que Go tuviera algo de la simplicidad de Erlang, pero Go tiene un propósito, y no es lo mismo que el propósito de Erlang (ni el de Scala) .

Vale la pena entender los por qué de cada idioma para saber cuándo y cómo.

Como dijo Ngoc Doc, el “pensamiento” de Erlang no se parece a ningún otro y ESO es lo que lo hace tan útil. Ese pensamiento se aplica, no se recomienda. ¿Podrías hacer todo lo que puedes hacer en Erlang, en Scala? Algo así como. Pero en Erlang no podrías hacerlo de otra manera. Erlang compartimenta errores, fallas, estado y complejidad en la raíz del tiempo de ejecución. La capa “vm” de Erlang trae conceptos que ninguno de los otros lenguajes tiene. Esto, por diseño, lo obliga a adoptar patrones que no necesita revisiones constantes de código y conferencias y patrones de diseño para imponer. La capacidad de actualizar el código sin reiniciar un programa (tiene que agotar la conexión de los servidores HTTP antes de poder reiniciarlos, pero ¿cómo puede esperar a que desaparezcan todas las llamadas telefónicas?) Es un beneficio adicional que la sintaxis está basada en expresiones , pero incluso si el viejo C me diera este tipo de aislamiento, sería un campista feliz. Ninguno de los otros idiomas hace esto. Por ejemplo, con frecuencia me enojo porque un programa de golang completo morirá si una gorutina arroja una excepción de desreferencia de puntero nulo. ¿Erlang existiría y aportaría algo nuevo y bastante fundamentalmente diferente a la tabla, si se hiciera HOY, después de haber tenido JavaScript, Scala, F # y Haskell en la última década? ¡Puedes apostar!

Scala fue construido específicamente para la gente de Java. No estoy diciendo que fue una sintaxis pensada para ser amigable con la gente de Java, sino que fue creada lentamente en las tiendas ortodoxas de Java. Trabajé en tal tienda. Para uno de mis buenos amigos y colegas que es un genio de Scala, fue un viaje frustrante de 18 meses presentarlo a mi equipo que dependía de sus patrones idiomáticos en Java. Traté de promocionar Erlang o Javascript y salí a reír antes de que pudiera terminar esa oración. Esto no quiere decir que Scala no sea un lenguaje sorprendente y hermoso en sí mismo, pero su * propósito * de existencia no es ser “simplemente otro lenguaje funcional”. Su propósito es ser más fácil para que las tiendas ortodoxas de Java se muevan gradualmente, sin sacrificar el código existente, y sean funcionales y limpios mientras lo hacen. Dicho de otra manera, ¿existiría Scala, y estaría en la forma en que está, si no hubiera un mandato para interactuar con Java y ejecutarse en la JVM?

Go es un lenguaje industrial hecho para la practicidad del mundo real, no se preocupa por la sintaxis y la teoría. Siempre he encontrado que Google está en el extremo más “tradicional y ortodoxo” del espectro, por mucho que les gustaría pensar que no son Microsoft. Google ama C y Java y la programación de procedimientos. Go fue construido para ser un “C más seguro” o un “Java más rápido / más simple” con punteros de función y cierres añadidos. Creo que Go también es políticamente menos amenazante para la ortodoxia, aquellos que están basados ​​en Java y C, pero con tener Tuve el beneficio de tres décadas de experiencia para limpiar algo de basura que era innecesario. Las GRANDES contribuciones de Go no están en la sintaxis en sí, sino que se compila en código nativo, puede compilarlo para incluir todo hasta libc en él, resolviendo así el infierno de dependencia para siempre, facilitando las implementaciones y la distribución de aplicaciones, teniendo un compilador ridículamente rápido, Etcétera.

He estado usando Erlang y Scala durante años. A la hora de aprender Erlang, es un gran error decir que Scala es más fácil de aprender que Erlang. Puedes aprender Erlang en solo uno o dos días, pero te lleva semanas o meses aprender Scala. Erlang es mucho más simple. Puedes aprender el 90% de Erlang en un fin de semana simplemente leyendo y haciendo ejercicios desde este sitio: Aprende algo de Erlang

Filosóficamente, Erlang cambiará tu forma de pensar acerca de la programación. Scala apenas te cambiará nada. Mi consejo es tener valor para aprender Erlang primero, luego Scala después.

Para el rendimiento del código de subproceso único, Erlang no es una buena opción porque es claramente más lento que Scala y Go. Recientemente hay una discusión sobre este tema: Sobre el rendimiento del sistema Erlang – Programación Erlang

Mi favorito:

La cuestión es que Erlang es un lenguaje de programación concurrente, por lo que está optimizado para la concurrencia y los problemas que contiene. HiPE optimiza la parte secuencial del sistema, pero no puede hacer nada sobre los planificadores, etc., por lo que no afecta las características de concurrencia (que tampoco debería). HiPE hace un muy buen trabajo, pero para mini puntos de referencia secuenciales, HiPE o no HiPE nunca será tan rápido como C ++. Tampoco optimizamos para eso. Comparar HiPE con GCH, OCaml o cualquier otro compilador nativo común es realmente injusto. Los otros compiladores crean binarios directamente sobre el sistema operativo, sin soporte para concurrencia masiva en ninguna VM. No quiere decir que no sean realmente buenos compiladores, pero resuelven un problema diferente.

Construir sistemas grandes con Erlang mostrará la imagen completa, no ejecutar micro benchmarks. Si su negocio es vender programas de juego de la vida, rannkuch-redux o mandelbrot, se sentirá muy decepcionado si intenta hacer el programa más rápido en Erlang. Si, por otro lado, está escribiendo un servidor grande, se sorprenderá de qué nivel de concurrencia, qué tiempo de actividad y qué utilización de hardware logrará.

Entonces, realmente estamos trabajando en la optimización, pero no en optimizar los puntos de referencia, sino en hacer posible la implementación de sistemas altamente disponibles, escalables, paralelos y concurrentes.

Esa es una gran pregunta, e intentaré agregar mis 2 centavos. Creo que cuando se trata de estilos de programación funcionales, tanto Erlang como Scala son excelentes opciones, pero los diferentes equipos tienen diferentes razones para elegir uno sobre el otro.

Actualmente estoy construyendo y manteniendo la infraestructura y los sistemas de back-end en una startup llamada CentralApp usando Scala como el idioma principal en el back-end. Como programador, para mí las cosas que realmente importaban eran:

• un sistema de tipo estático
• programación funcional
• concurrencia
• expresividad: tipos, sintaxis

Evalué a Erlang y Scala en esos aspectos y, en mi opinión, Scala resultó ser una mejor opción.

La mayoría de las arquitecturas de back-end nuevas tienden a distribuirse con preocupaciones dispersas entre los microservicios que manejan un aspecto específico de su producto. Estamos construidos con el mismo paradigma y tenemos algo así como 20 servicios Scala ejecutándose en nuestro backend: somos un producto que intenta hacer muchas cosas y preferimos compartimentar.

Al evaluar Scala y Erlang (había programado brevemente en Erlang pero nunca en Scala al comenzar, pero tenía algunos conocimientos de programación funcional para empezar), descubrí que el sistema de tipos de Scala (y la falta de uno de Erlang [1]) muy atractivo. Quería modelar el problema como tipos y hacer que esos tipos se relacionen entre sí. Scala fue una gran elección cuando se trataba de eso.

Entonces quería algo que tuviera soporte de primera clase para FP y tanto Erlang como Scala estaban a la par entre sí. Scala y Erlang también están bien equipados para crear código concurrente, y te sugiero que leas esto [2]. Scala también hereda el patrón de concurrencia del actor de Erlang con Akka.

El código de Scala, a mis ojos, también es más fácil de leer. Por ejemplo, considero que las implicidades (aunque tenga cuidado con ellas) son muy útiles, y ayudan a que el código sea generalmente agradable de leer. También hay mixins y rasgos [3] que hacen que la programación sea muy agradable para mí.

Por el lado del rendimiento, se sabe que tanto Scala como Erlang tienen puntos de referencia impresionantes y aplicaciones industriales de la vida real (Erlang se usa para impulsar algunos de los servidores de mensajería más activos del mundo, Scala impulsa sitios web de alto tráfico como Twitter y Foursquare), por lo que no Realmente pierdes mucho eligiendo uno sobre el otro. También mencionó que Twitter cambió de RoR a Scala, y aquí hay un pequeño video interesante [4] que describe por qué.

Cuando se trata de bibliotecas, Scala tiene algunos de los marcos de trabajo de alta calidad, kits de herramientas:

• Chispa – chispear
• Akka
• Jugar
• Mancha
• Finagle
• + interoperabilidad con bibliotecas Java existentes (== ¡un gran número!)
• … para nombrar unos pocos.

–

En general, creo que es más una cuestión de preferencia que otra cosa. Creo que Scala y Erlang son realmente buenas opciones, pero su kilometraje puede variar.

Otra cosa que las arquitecturas orientadas al servicio nos permiten hacer es poder decidir sobre las tecnologías más adecuadas para un trabajo. Hasta ahora, he tenido dificultades para encontrar algo que Scala no pueda resolver: diría que contratar ingenieros de Scala puede ser un poco difícil, pero dada la marca de Scala, también encontrarás algunos ingenieros realmente buenos.

Notas al pie

[1] Tipos (o falta de ellos)

[2] ¿Por qué Scala es bueno para la concurrencia?

[3] Mixins vs composición en scala

[4] O’Reilly OSCON Java 2011: Raffi Krikorian, “Twitter: De Ruby on Rails a la JVM”

No he usado erlang aunque he jugado un poco con él. Parece que el lenguaje tiene un punto óptimo que son los sistemas de mensajería y los sistemas que tienen una lectura muy alta en todo momento, es decir, sistemas de entrega de anuncios. Hay muchas cosas sobre erlang que lo hacen muy robusto. Sin embargo, hay algunas cosas que lo hacen menos general y es por eso que muchas aplicaciones terminan usando java o lenguajes basados ​​en java y cada vez más se van.

En mi propio inicio, estoy planeando usar algunos idiomas, incluidos go y clojure y posibles scala. Miré a Erlang, pero descubrí que si bien el lenguaje es “simple”, solo faltan bibliotecas y, francamente, las personas que lo saben me hicieron decidir no considerarlo realmente. Mucha más gente conoce Java y cada vez más GO y nodo y demás. Entonces, si no tiene una necesidad absoluta para él, entonces probablemente no haya una razón para usarlo.

Thant dijo que Elixir es un proyecto muy interesante y parece estar trabajando para corregir algunos de los “problemas” que Erlang tiene, incluyendo una sintaxis más fácil de entender, más bibliotecas y más marcos web y una comunidad que parece más enfocada en aplicaciones prácticas en lugar de más teóricas. unos. Sin embargo, es difícil decir si despegará.

En cuanto a Scala y GO, no olvidemos Clojure. Clojure es un lenguaje impresionante que no tiene algunas de las complejidades que tiene Scala. Tiene una comunidad increíble que solo se enfoca en resolver problemas y crear excelentes bibliotecas y herramientas. También es “más puro” y luego scala. Además, clojurescript es realmente impresionante y hace que el desarrollo en JavaScript sea casi divertido.

Ir es realmente muy interesante, pero por la razón opuesta son estos otros idiomas. Es muy simple y directo. Carece de la complejidad que tienen estos otros idiomas. Pero eso hace que sea mucho más fácil de leer y comprender. Tiene simultaneidad. Es rápido porque está compilado. Ya se está utilizando en algunas aplicaciones bastante importantes. Personalmente, me gusta la programación funcional, sin embargo, cuando tienes un lenguaje que ofrece lo que Go ofrece, es difícil de resistir.

Al final, la elección del idioma y la plataforma se reduce a muchos factores y debe hacer su debida diligencia para decidir cuál es el adecuado para sus necesidades. Esto dice que la mayoría de las aplicaciones más grandes usan una variedad de idiomas. Por ejemplo, scala se está haciendo más grande en el área de procesamiento de datos a través de Spark. Que es un área con la que no creo que Erlang tenga fortalezas. Sin embargo, Go tampoco tiene un proyecto, creo que se llama Marathon, que se ocupa de la gestión de clústeres que se desarrolla con el lenguaje. Lo cual es intrigante porque esa herramienta se conecta con una herramienta escrita en Java, creo.

Es un momento muy interesante en el mundo de los lenguajes de programación para estar seguro.

¿Por qué tenemos casos de, por ejemplo, Twitter migrando de RoR a Scala? A pesar de que Scala está destinado a ser utilizado con el paradigma funcional, ¿no sería Erlang aún mejor?

Hay muchos factores que afectan la elección de un idioma. Creo que Thomas hizo un buen trabajo al explicar eso.

¿Podría ser porque Scala es más “amigable” cuando se trata de sintaxis?

La belleza se encuentra en los ojos del que observa. Personalmente, creo que Lisp es hermosa. Muchos estarían en desacuerdo. Pero sí, la sintaxis puede ser un factor.

Otro gran caso que no puedo entender es Google. Es bien sabido (por las presentaciones de Go en Google I / O 2011) que las aplicaciones principales están construidas en C ++ o Java. Entonces, ¿por qué habrían tenido que crear Go (golang) si Erlang puede encajar en el papel?

¿Porque ellos pueden? Síndrome de NIH? Además, Go es un lenguaje de propósito muy general y aborda algunos de los problemas con los idiomas actuales (incluido Erlang). Puede verse como un esfuerzo no solo para crear una herramienta para sus necesidades sino también para cambiar la programación en su conjunto. Tal vez Google quiera crear un mejor lenguaje para todos sus productos futuros (fuera de línea, en línea, móvil, computadora de escritorio …). Incluso se aventuraron en un reemplazo de Javascript. Digamos que Google hace muchos experimentos de piratería, investigación y desarrollo. Algunos fallaron horriblemente. Go resulta ser útil para que lo desarrollen más y lo popularicen.

– Otro gran caso que no puedo entender es Google. Es bien sabido (por las presentaciones de Go en Google I / O 2011) que las aplicaciones principales están construidas en C ++ o Java. Entonces, ¿por qué habrían tenido que crear Go (golang) si Erlang puede ajustarse al rol?

Lea las razones en los siguientes artículos:
– Vaya a Google: diseño de idiomas al servicio de la ingeniería de software
– Menos es exponencialmente más

Creo que no es el síndrome “No inventado aquí”.