Cómo empujar Erlang a mi lugar de trabajo

Question

Creo que Erlang es muy adecuado para sistemas de servidores desarrollados en mi lugar de trabajo (actualmente desarrollado en Java). Soy un poco escéptico sobre cómo esto sería aceptado tanto por los desarrolladores (que no tienen idea sobre funcional o Erlang) como por los gerentes.

¿Alguna idea sobre cómo abordar el problema? Estoy pensando en algún sistema híbrido, donde el núcleo duro de gran infraestructura fiable utiliza Elrang, y cosas específicas aplicación desarrollada en Java (como nodos?)

Answer 1

Hay algunos enfoques, y tampoco tengo ninguna garantía de que en realidad el trabajo

• Implementa algo sustancial en un corto período de tiempo, tal vez usando tu propio tiempo. No se lo digas a nadie hasta que tengas algo que mostrar que funcione. A menos que tengas un colega en eso.
• Levanta un montón de proyectos de Erlang que son buenas demostraciones de las funciones que deseas. Preséntelo a sus gerentes y trate de enmarcarlos sobre el riesgo de mantener el uso de Java con este tipo de tecnología disponible.

Si la empresa para la que trabaja en realidad tienen una base de trabajo de código en Java ya, no son propensos a tomar en serio cuando usted sugiere volver a escribir en otro idioma.

La verdadera prueba de que usted cree que Erlang es una opción mucho mejor: renuncie y ponga en marcha una empresa competidora y aporte la visión tecnológica que tiene en su industria actual. Sus gerentes realmente están comparando una situación de riesgo similar a como lo haría si renunciara a su trabajo, y están buscando los mismos hechos seguros para el éxito que usted, y considerarán dejar un cheque de pago "seguro".

---

En cuanto a la forma de integrar, echa un vistazo a la aplicaciónjinterface en Erlang. Permite que el código Java envíe mensajes a los nodos Erlang, y permite a Java exponer buzones a los nodos Erlang como si existieran procesos Erlang.

Answer 2

Todo se trata de ROI (retorno de la inversión) a un gerente: un gerente estará preocupado por el rendimiento (de la empresa). Para apelar a su naturaleza empresarial, tendrá que defenderse usando dólares $ (o la moneda que corresponda).

Tenga en cuenta que emprender un proyecto de "skunkwork" para "probar" que su solución basada en Erlang puede ser contraproducente: "¿Así que tuvo tiempo para jugar con Erlang, por qué no pasó el tiempo en el proyecto? " (Por supuesto, no todos los gerentes/compañías pensarían de esta manera).

Tienes que tener en cuenta propuesta completa p. impacto en el equipo, habilidades para desarrollar, etc. Se trata de dinero.

Si tengo un consejo para usted: comience poco a poco, siembre una semilla, créelo y mírelo crecer.

---

Un hombre sabio dijo una vez:

"No se trata de la tecnología, se trata de el mercado de productos &".

Answer 3

Comience por no apuntar a una reescritura pero usando erlang para una nueva característica/proyecto.Las reescrituras pueden ser costosas y arriesgarse en Erlang por algo que ya es una empresa costosa y que lleva mucho tiempo es difícil de vender. Pero si hay una nueva pieza que se puede hacer en Erlang y Java, tienes más posibilidades. El proyecto será lo suficientemente pequeño como para que pueda descubrir temprano si Erlang es una buena opción y adaptarse en consecuencia. Y cuando Erlang se pruebe a sí mismo en ese proyecto, tendrá mejores datos para presentar su caso.

Answer 4

Estamos introduciendo RabbitMQ en nuestra infraestructura, que actualmente ejecuta una combinación de aplicaciones C++, Java y Python. No estoy con la intención específica para mover el equipo hacia Erlang, pero si lo fuera, la introducción de una herramienta bien escrito de terceros que sólo pasa a usar Erlang es una muy buena manera de conseguir el pie en la puerta.

Una advertencia importante es que mientras que Erlang es un lenguaje maravilloso para aprender, la tecnología que rodea (OTP en particular) tiene una enorme curva de aprendizaje y es extremadamente primitiva de muchas maneras (depuración, IDE, etc.). Está mejorando todo el tiempo, pero los conversos renuentes te crucificarán si no les adviertes sobre el dolor de aprender a programar en un entorno radicalmente diferente. Incluso cosas simples como la falta de tecnología de sentido de código (por ejemplo, tipo 'foo.' Y el IDE le dice a qué métodos puede llamar en foo) pueden dejar un sabor realmente desagradable en la boca.