¿Cuándo debería considerar el uso de varios idiomas en un sistema de fondo?

Si tienes una opción, no lo hagas.

Pero a veces no lo haces.

A medida que pasan los años, sus sistemas migrarán gradualmente. Nuestro front-end migró a Rails (para reducir los costos asociados con el mantenimiento de un personal de desarrollo competente), por ejemplo, y esto nos dio un incentivo para terminar la transición de nuestro back-end de Perl a Ruby (que ya era importante porque el analizador de expresiones regulares de Ruby tiene capacidades que Perl no tiene).

Sin embargo, durante mucho tiempo, el 80% de nuestra infraestructura todavía estaba en Perl.

Durante el período de transición, mi entonces jefe reescribió muchas cosas en el único idioma en el que * él * se sentía cómodo, Bash.

Entonces, cuando dejó la compañía y me encontré en los reinados, más o menos, estaba mirando una infraestructura que era 30% Bash, 20% Perl, 40% Ruby (mis cosas, principalmente) y 10% C (bibliotecas importadas por algunos de los desarrolladores de Ucrania, realmente utilizados por los sistemas Perl, en su mayoría). Todos los bits se comunicaron a través de varias soluciones API combinadas que utilizan HTTP, SSH o, a veces, simplemente soltando archivos en carpetas aparentemente aleatorias para que otras partes del sistema las recojan a una hora programada.

Fue una pesadilla.

Ahora es un año y cambia más tarde. Los sistemas Bash han sido reemplazados, los sistemas Perl han quedado en desuso junto con las ahora innecesarias bibliotecas C …

Y estoy sentado aquí, escribiendo esto, y pensando: “Me pregunto si valdría la pena presentarle a Julia la mezcla. Un lenguaje compilado con un analizador de expresiones regulares intuitivo sería una gran ayuda, y a medida que avanzamos hacia un papel más analítico para nuestros clientes, el aumento de velocidad de 18x que obtendríamos con un lenguaje compilado versus uno interpretado valdría la pena. inconvenientes menores … pero maldita sea, es tan molesto que Julia indexa desde 1 en lugar de 0. ¿Sería capaz de soportar eso?

Este es el momento en que viajaré de regreso al futuro para suicidarme y evitar que suceda. Yo lo veo. Lo reconozco Sé que lo que estoy considerando es una mala idea.

Pero aún podría, sobre todo porque sería divertido.

La mayoría de las veces, solo viene con el territorio.

Tú serás:

  • Ejecutar una base de datos escrita en un idioma (por ejemplo, mysql, escrito en c, o CouchDB, escrito en Erlang). Escribirá el código de la base de datos en SQL (o algo más si está ejecutando una base de datos noSQL). Puede que tenga que escribir procedimientos almacenados y disparadores en cualquier idioma que admita la base de datos.
  • Estarás ejecutando un servidor web, tal vez el demonio Apache (c creo) o tal vez un servidor de aplicaciones como Jetty (Java). O tal vez algo de alto rendimiento como Yaws (Erlang).
  • Es posible que necesite instalar algunos módulos del núcleo y / o bibliotecas en tiempo de ejecución, probablemente escritas en c, pero quién sabe.
  • Utilizará varios módulos para su servidor, que podrían escribirse en cualquier cosa, desde c hasta pear, java o lo que sea.
  • Puede usar un marco, que podría escribirse en otra cosa nuevamente.
  • Puede que esté o no escribiendo código adicional, ya sea extensiones a un marco o algo más extenso, en cuyo caso probablemente debería apegarse a un idioma por simplicidad. (Sin embargo, si tiene varias funciones principales diferentes, cada una de las cuales se ejecuta como un subsistema independiente, por ejemplo, un sistema de gestión de contenido, un sistema de procesamiento de transacciones y un paquete financiero, las consideraciones de diseño, la disponibilidad de marcos y bibliotecas, etc. pueden llevarlo a diferentes idiomas para diferentes subsistemas).
  • Si va a generar páginas web, necesitará algo de HTML y quizás JavaScript (aunque, en ese caso, está usando código como datos).
  • Es posible que tenga algún software de administración y seguridad del sistema escrito en algo completamente diferente.
  • Y casi seguro que tendrá que escribir varios archivos de “pegamento” e init en forma de scripts de shell.

En general, UTILIZARÁS múltiples idiomas, aunque no necesariamente escribirás código en todos ellos. Qué idiomas estarán determinados por una combinación de su entorno de tiempo de ejecución (lo que ya está allí con el que tiene que usar o con el que interactúa), las preferencias de su empresa / cliente, la disponibilidad de marcos / bibliotecas / SDK para funciones clave. La idoneidad de un idioma en particular para implementar su enfoque de diseño (por ejemplo, el uso de Erlang para admitir una concurrencia masiva) y sus propias preferencias estarán cerca del final de la lista.

Actualmente me estoy haciendo esta misma pregunta (de mí mismo) dónde trabajo.

La respuesta que se me ocurrió es que está bien usar varios idiomas en un sistema de fondo siempre que haya contratos bien definidos (¿Qué es un “contrato” de API y quién debe crearlo al crear un conjunto de API? ) y siempre que cada idioma tenga un alcance limitado a una unidad discreta de funcionalidad (también conocido como microservicio).

Esta parece ser una buena forma de eliminar el síndrome de “cuando tienes un martillo, todo parece un clavo” que muchos desarrolladores tienen con su idioma de elección, y permite utilizar el mejor lenguaje para una tarea determinada.

También fomentará más modularidad y menos monolítico … ness.

Algunas ideas de dónde dibujar las líneas del lenguaje:

  1. Sistemas existentes: si se integra con sistemas heredados, puede tener sentido implementar ciertas partes de un sistema en el lenguaje heredado. Solo lo suficiente para proporcionar un buen contrato (API) que otros usuarios internos puedan confiar para sus necesidades.
  2. Sistemas de almacenamiento: si tiene un servidor de base de datos de documentos que comprende JSON y Javascript, puede tener mucho sentido implementar muchos componentes en Javascript, por ejemplo, Nodo (Comparación de soluciones JavaScript del lado del servidor)
  3. Reclutamiento: algunos idiomas son simplemente sexys y atraerán a los mejores talentos. y dado que las personas talentosas son el recurso comercial n. ° 1 que siempre tiene un suministro limitado, esta puede ser una razón válida

Ahora, algunas advertencias.

  1. El más importante, aunque lo estoy considerando, no estoy haciendo esto con mi equipo, somos una tienda de un solo idioma (dos si se cuenta el mínimo de Javascript para las ventajas de la interfaz de usuario como segundo idioma).
  2. Esto aumenta las necesidades de contratación y los presupuestos y puede crear facciones políticas donde antes no existían.
  3. Si no se hace intencionalmente (elegir la mejor herramienta para una tarea) será una pesadilla. Consulte la respuesta de George Huestis a esta misma pregunta. La única razón válida para usar múltiples herramientas es una decisión técnica que debe basarse en un razonamiento sólido.

El uso de múltiples idiomas agrega complejidad, cierto. Sin embargo, con la suficiente frecuencia, simplemente no puede ejecutar las cosas en un solo idioma.

Considere que tendrá una base de datos SQL. Ahora es al menos 2 idiomas. Uno para su API (Python, Java, lo que sea) más SQL.

¿Necesita algo de procesamiento de imágenes o qué pasa con los archivos de audio? Esto podría involucrar un lenguaje de bajo nivel. (Construir su API completa con dicho lenguaje, cualquier cosa con una C en su nombre, podría ser engorroso)

No hemos hablado de optimizaciones de rendimiento, pero ya hay un montón de idiomas involucrados.

Si hay algo importante que contar sobre los idiomas, aquí está mi versión tldr:

Algunas tareas necesitan capacidades de bajo nivel, mientras que otras necesitan un buen vocabulario. Por ejemplo, con Python, su API se ejecuta en minutos, pero nunca realizará tareas de bajo nivel de manera eficiente y viceversa.