¿Cuán maduro es el proyecto de lenguaje de computación científica "Julia"?

Estoy considerando aprender un nuevo lenguaje para usar en proyectos de modelado numérico / simulación, como un reemplazo (parcial) para C ++ y Python que uso actualmente. Me encontré con Julia , que suena un poco perfecta. Si hace todo lo que dice, podría usarlo para reemplazar C ++ y Python en todos mis proyectos, ya que puede acceder al código de la biblioteca de computación científica de alto nivel (incluido PyPlot) y ejecutar bucles a una velocidad similar a C. También me beneficiaría de cosas como las rutinas adecuadas que no existen en ninguno de los otros idiomas.

Sin embargo, es un proyecto relativamente nuevo, actualmente en la versión 0.x, y encontré varias advertencias (publicadas en varias fechas en el pasado) de que no está listo para el uso diario. En consecuencia, me gustaría obtener información sobre el estado del proyecto en este momento (febrero de 2014, o cada vez que se publique una respuesta), para ayudarme a evaluar si personalmente debería considerar invertir el tiempo para aprender este idioma en esta etapa.

Agradecería respuestas que se centran en hechos relevantes específicos sobre el proyecto Julia ; Me interesan menos las opiniones basadas en la experiencia con otros proyectos.

En particular, un comentario de Geoff Oxberry sugiere que la API de Julia todavía está en un estado de cambio, lo que requiere que el código se actualice cuando cambia. Me gustaría tener una idea de hasta qué punto es así: ¿qué áreas de la API son estables y cuáles pueden cambiar?

Supongo que normalmente estaría haciendo álgebra lineal (por ejemplo, resolviendo problemas propios), integración numérica de EDO con muchas variables y trazando usando PyPlot y / o OpenGL, así como el procesamiento de números de bajo nivel en estilo C (por ejemplo, para simulaciones de Monte Carlo ) ¿El sistema de bibliotecas de Julia está completamente desarrollado en estas áreas? En particular, ¿la API es más o menos estable para ese tipo de actividades, o vería que mi antiguo código tenderá a romperse después de actualizar a una nueva versión de Julia?

Finalmente, ¿hay otros problemas que valga la pena considerar al decidir si usar a Julia para un trabajo serio en este momento?

Julia, en este punto (mayo de 2019, Julia v1.1 con v1.2 a punto de salir) está bastante madura para la informática científica. La versión v1.0 significó el fin de la ruptura anual del código . Con eso, muchas bibliotecas de computación científica han tenido el tiempo de crecer simplemente sin interrupciones. Se puede encontrar una visión general de los paquetes de Julia en pkg.julialang.org .

Para la computación científica central, la biblioteca DifferentialEquations.jl para ecuaciones diferenciales (ODE, SDE, DAE, DDE, simulaciones de Gillespie, etc.), Flux.jl para redes neuronales y la biblioteca JuMP para programación matemática (optimización: lineal, cuadrática, programación de enteros mixtos, etc.) son tres de los pilares del ecosistema informático científico. La biblioteca de ecuaciones diferenciales en particular está mucho más desarrollada de lo que vería en otros idiomas, con un gran equipo de desarrollo que implementa características como integradores EPIRK , Runge-Kutta-Nystrom , ecuación diferencial de retardo rígido / diferencial-algebraico yintegradores de ecuaciones diferenciales estocásticas rígidas adaptables al tiempo , junto con un montón de otras ventajas como análisis de sensibilidad adjuntos , DSL de reacción química , Newton-Krylov sin matriz y compatibilidad completa con GPU (sin transferencia de datos), con entrenamiento de ecuaciones diferenciales neuronales , todo con resultados fantásticos de referencia (descargo de responsabilidad: soy el desarrollador principal).

Lo que es un poco alucinante sobre el ecosistema maduro de Julia es su composibilidad. Esencialmente, cuando alguien crea una función genérica de biblioteca como las de DifferentialEquations.jl, puede usar cualquier tipo AbstractArray / Number para generar un código nuevo sobre la marcha. Entonces, por ejemplo, hay una biblioteca para la propagación de errores ( Measurements.jl ) y cuando la pega en el solucionador ODE, automáticamente compila una nueva versión del solucionador ODE que realiza la propagación de errores sin muestreo de parámetros . Debido a esto, es posible que no encuentre algunas características documentadas porque el código de las características se genera solo, por lo que debe pensar más sobre la composición de la biblioteca.

Una de las formas en que la composición es más útil es en álgebra lineal. Los solucionadores de ODE, por ejemplo, le permiten especificar jac_prototype, permitiéndole darle el tipo de Jacobian que se utilizará internamente. Por supuesto que hay cosas en la biblioteca estándar LineraAlgebra como Symmetricy Tridiagonalse puede usar aquí, pero teniendo en cuenta la utilidad de composibility en algoritmos de tipo genérico, la gente ha ido por ahora y construido bibliotecas enteras de tipo matriz. BandedMatrices.jl y BlockBandedMatrices.jl son bibliotecas que definen tipos de matriz con bandas (Block) que tienen lusobrecargas rápidas , lo que las convierte en una buena forma de acelerar la solución de discretizaciones rígidas de MOL de sistemas de ecuaciones diferenciales parciales. PDMats.jlpermite la especificación de matrices definidas positivas. Elemental.jl le permite definir un jacobiano disperso distribuido. CuArrays.jl define matrices en la GPU. Etc.

Entonces tienes todos tus tipos de números. Unitful.jl realiza la comprobación de unidades en tiempo de compilación, por lo que es una biblioteca de unidades sin gastos generales. DoubleFloats.jl es una biblioteca rápida de mayor precisión, junto con Quadmath.jl y ArbFloats.jl . ForwardDiff.jl es una biblioteca para la diferenciación automática en modo directo que utiliza aritmética de número dual. Y puedo seguir enumerando estos. Y sí, puede lanzarlos en bibliotecas de Julia suficientemente genéricas como DifferentialEquations.jl para compilar una versión específicamente optimizada para estos tipos de números. Incluso algo como ApproxFun.jlque funciona como objetos algebraicos (como Chebfun) funciona con este sistema genérico, permitiendo la especificación de PDE como ODE en escalares en un espacio de funciones.

Dadas las ventajas de la composibilidad y la forma en que los tipos se pueden usar para generar código nuevo y eficiente en las funciones genéricas de Julia, ha habido mucho trabajo para implementar implementaciones de la funcionalidad de la informática científica central en Julia pura. Optim.jl para optimización no lineal, NLsolve.jl para resolver sistemas no lineales, IterativeSolvers.jl para solucionadores iterativos de sistemas lineales y eigensystems, BlackBoxOptim.jl para optimización de caja negra, etc. Incluso la biblioteca de redes neuronales Flux.jl solo usa CuArrays. La compilación automática de código de jl en la GPU para sus capacidades de GPU. Esta composibilidad fue el núcleo de lo que creó cosas como ecuaciones diferenciales neuronales en DiffEqFlux.jl. Los lenguajes de programación probabilísticos como Turing.jl también son bastante maduros ahora y utilizan las mismas herramientas subyacentes.

Dado que las bibliotecas de Julia se basan fundamentalmente en herramientas de generación de código, no debería sorprendernos que haya muchas herramientas en torno a la generación de código. El sistema de difusión de Julia genera núcleos fusionados sobre la marcha que están sobrecargados por los tipos de matriz para proporcionar muchas de las características mencionadas anteriormente. CUDAnative.jl permite compilar el código de Julia en los núcleos de GPU. ModelingToolkit.jl elimina automáticamente el azúcar de los AST en un sistema simbólico para transformar el código matemático. Cassette.jlle permite "sobregrabar" la función existente de otra persona, utilizando reglas para cambiar su función antes del tiempo de compilación (por ejemplo: cambiar todas sus asignaciones de matriz a asignaciones de matriz estática y mover operaciones a la GPU). Se trata de herramientas más avanzadas (no espero que todos los que realizan computación científica tomen el control directo del compilador), pero así es como se están construyendo muchas de las herramientas de la próxima generación (o más bien, cómo se escriben las características por sí mismas).

En cuanto al paralelismo, mencioné las GPU, y Julia ha incorporado computación multiproceso y distribuida . El subprocesamiento múltiple de Julia muy pronto usará una arquitectura de tiempo de ejecución de tareas paralelas (PARTR) que permite la programación automática de subprocesos múltiples anidados . Si desea utilizar MPI, sólo puede utilizar MPI.jl . Y, por supuesto, la forma más fácil de usarlo es usar una configuración de tipo AbstractArray para usar el paralelismo en sus operaciones.

Julia también tiene el ecosistema subyacente básico que cabría esperar de un lenguaje de propósito general utilizado para aplicaciones científicas. Tiene el IDE de Juno con un depurador incorporado con puntos de interrupción , tiene Plots.jl para hacer todo tipo de tramas. Muchas herramientas específicas también son buenas, como Revise.jl actualiza automáticamente sus funciones / biblioteca cuando se guarda un archivo. Tiene sus DataFrames.jl , bibliotecas de estadísticas , etc. Una de las mejores bibliotecas es Distributions.jl, que le permite escribir algoritmos genéricos para la distribución (por ejemplo:rand(dist)toma un número aleatorio de cualquier distribución que se haya pasado), y hay una gran cantidad de distribuciones univariadas y multivariadas (y, por supuesto, el envío ocurre en tiempo de compilación, lo que hace que todo sea tan rápido como codificar una función específica de la distribución). Hay un montón de herramientas de manejo de datos , servidores web , etc., lo que sea. En este punto, es lo suficientemente maduro como para que si hay algo científico básico y esperarías que exista, solo lo buscas en Google con .jl o Julia y aparecerá.

Luego hay algunas cosas a tener en cuenta en el horizonte. PackageCompiler está buscando construir binarios a partir de las bibliotecas de Julia, y ya tiene algunos éxitos pero necesita más desarrollo. Makie.jl es una biblioteca completa para el trazado acelerado por GPU con interactividad, y todavía necesita más trabajo, pero realmente está buscando convertirse en la principal biblioteca de trazado en Julia. Zygote.jl es una biblioteca de diferenciación automática de fuente a fuente que no tiene los problemas de rendimiento de un AD basado en rastreo (Flux's Tracker, PyTorch, Jax), y que está buscando funcionar en todos los códigos puros de Julia. Etc.

En conclusión, puede encontrar mucho movimiento en muchos lugares, pero en la mayoría de las áreas ya existe una biblioteca sólida y madura. Ya no está en un lugar donde preguntas "¿será adoptado?": Julia ha sido adoptada por suficientes personas (millones de descargas) que tiene el impulso para quedarse para siempre. Tiene una comunidad realmente agradable, por lo que si alguna vez quieres disparar la brisa y hablar sobre computación paralela o ecuaciones diferenciales numéricas, algunas de las mejores salas de chat para eso están en Julialang Slack . Si es un idioma que debe aprender es una pregunta personal, y si es el idioma adecuado para su proyecto es una pregunta técnica, y esas son diferentes. ¿Pero es un lenguaje que ha madurado y cuenta con el respaldo de un gran grupo consistente de desarrolladores? Eso parece ser un sí afirmativo.

Si no, ¿es posible dar una estimación aproximada del orden de magnitud de cuánto tiempo debo esperar antes de considerarlo nuevamente?

Mi estimación aproximada de orden de magnitud de cuánto tiempo lleva madurar los lenguajes de la ciencia computacional es de alrededor de una década.

Ejemplo 1: SciPy comenzó en 2001 más o menos. En 2009, se lanzó Scipy 0.7.0, y el integrador ODE tenía una interfaz para VODE (que es el equivalente de ode15s, aproximadamente; ode15sestá basado en NDF, VODE es BDF / Adams-Bashforth, dependiendo). Con SciPy 0.10.0, una interfaz para dopri5, que es más o menos el equivalente de MATLAB ode45, un método Runge-Kutta de cuarto orden típicamente introducido como el primer método práctico de integración numérica para estudiantes universitarios. SciPy 0.10.0 se lanzó en diciembre de 2011, y les tomó cerca de 10 años incluir una característica de MATLAB presentada a cada estudiante de ingeniería que conozco.

Ejemplo 2: Mathworks se fundó en 1984. En su primer lanzamiento, utilizaron un puerto LAPACK para C llamado JACKPAC (después de Jack Little, un ingeniero de MathWorks que lo escribió). No lo reemplazaron con LAPACK hasta 2000.

Julia puede tomar menos tiempo, pero estimaría que unos 10 años desde su fundación se convertirán en la corriente principal. (Ya ha pasado más o menos un año; ¿quizás 9-10 años, entonces?)

¿El sistema de bibliotecas de Julia está completamente desarrollado en estas áreas? En particular, ¿la API es más o menos estable para ese tipo de actividades, o vería que mi antiguo código tenderá a romperse después de actualizar a una nueva versión de Julia?

No uso a Julia, así que toma lo que digo con un grano de sal, ya que solo he visto a Jeff Bezanson hacer presentaciones sobre Julia. Se han inclinado hacia atrás para facilitar el enlace y el uso de bibliotecas de C, Python y Fortran. Si no puede encontrar una biblioteca de Julia que haga lo que desea, escriba una cuña de Julia para una biblioteca en un idioma más establecido. En consecuencia, no creo que la falta de bibliotecas sea una preocupación. Creo que una preocupación será asegurarse de que los cambios en las características del lenguaje principal no te muerdan el culo. Si observa los hitos en el repositorio de Julia Git, verá que la etiqueta de "ruptura" se usa bastante (12 veces en la versión 0.2, 5 veces en la versión 0.3). Para mí, eso sugiere que el lenguaje central todavía está evolucionando, por lo que dudo en usar el lenguaje en este momento.

EDITAR: Aurelius saca un buen punto:

¿Qué te hace suponer que Julia alguna vez se convertirá en la corriente principal, y no solo morirá en la oscuridad como tantos otros idiomas? SciPy / numpy tenía / tiene el respaldo de una comunidad de python en constante crecimiento, que Julia no tiene.

En la respuesta original, decidí evitar la pregunta de "¿Julia logrará convertirse en la corriente principal?" cuanto más se pueda. Fallar es fácil; El éxito es difícil. Creo que la mejor comparación de Julia es con lenguajes técnicos informáticos como MATLAB, R y Octave. Los lenguajes HPC (Chapel, Fortress, UPC, etc.) tienen una audiencia más limitada que los lenguajes de computación técnica, y los lenguajes de propósito general (C, Python, C ++, etc.) tienen una audiencia más amplia que los lenguajes de computación técnica.

Algo que creo que ayuda a Julia es el diseño para el rendimiento sin sacrificar la expresividad. Julia es mucho más competitiva con lenguajes compilados como C que MATLAB, R o incluso Python. Este objetivo de diseño también es una característica que puede atraer personas de los idiomas existentes, como:

• Las personas que se preocupan mucho sobre el rendimiento y provienen de lenguajes como C y Fortran, pero están dispuestos a sacrificar una pequeña gota de rendimiento (tal vez un factor de 2 Ish) para pasar de lenguaje compilado a un menor número de líneas de lenguaje interpretado (junto con un REPL para desarrollo y prueba más rápidos).
• Las personas que se preocupan por la alta productividad y provienen de lenguajes como Python, R y MATLAB, pero quieren más rendimiento. Cuando se trata de ejecución, Python puro, MATLAB puro y R puro son lentos. Los desarrolladores en esos idiomas han hecho todo lo posible para envolver bibliotecas en lenguajes compilados, pero no se puede envolver todo, y en algún momento, el lenguaje central lo ralentizará. Core Julia es más rápido, lo que te permite hacer más ciencia más rápido.
• Personas que se preocupan por el software libre. Julia es interpretada y libre (también lo es Python, Octave, etc.); MATLAB no lo es.

Julia también está intentando facilitar el paralelismo; No me siento terriblemente calificado para ampliar ese punto, y no creo que sea el principal atractivo del lenguaje, pero creo que es un punto de venta en el que están trabajando, y espero que otros puedan arrojar luz sobre él.

Sin embargo, incluso con el mérito técnico de su lado, los creadores del lenguaje tienen que hacer el trabajo preliminar para promover el idioma y evangelizar. Jeff Bezanson, Alan Edelman, Stephen Karpinski y Viral Shah están trabajando muy duro para que el idioma tenga éxito. Alan Edelman tiene profundos lazos con la comunidad de la ciencia computacional, y ha trabajado en proyectos a nivel de lenguaje antes (en particular, la extensión Star-P de MATLAB). Jeff Bezanson ha estado haciendo el circuito de conferencias para promocionar a Julia entre científicos e ingenieros computacionales por un tiempo. En el MIT, han estado haciendo un buen trabajo al reclutar estudiantes y personal (en particular, Steven G. Johnson) para contribuir agregando bibliotecas a Julia. Tienen un artículo en Wired y lograron obtener un artículo de Wikipedia para ellos, todo después de solo un año. Su repositorio Git tiene miles de estrellas, cientos de tenedores, y cientos de relojes, por lo que para los estándares de código abierto, su proyecto ha sido un éxito. Creo que han hecho todo lo correcto hasta ahora, por lo que es cuestión de mantener ese esfuerzo y construir comunidad. Todavía podrían fallar, pero llegar hasta aquí me sugiere que tienen una posibilidad razonable de éxito.

Creo que vale la pena aprender a Julia. Lo he usado para producir algunos códigos de elementos finitos de investigación y producirlos muy rápidamente. He estado muy satisfecho con mi experiencia.

Julia ha habilitado un flujo de trabajo para mí que he encontrado difícil de lograr con otros idiomas. Puede usarlo como un lenguaje de creación de prototipos como MATLAB, pero a diferencia de MATLAB cuando tiene un código de trabajo y está pasando por iteraciones de creación de perfiles para acelerarlo, reemplazar los puntos de acceso con código C es sencillo. Han hecho de la interfaz con C (y Python) una prioridad en el diseño.

Por lo tanto, el lenguaje me ha permitido pasar rápidamente de mis formulaciones matemáticas al código funcional y luego del código funcional al código de alto rendimiento. Creo que esta característica de Julia es subestimada, pero agrega un gran valor.

En muchos casos, obtuve el rendimiento C (en comparación con mi propio código C) en cuestión de horas después de producir un código funcional de elementos finitos. Hasta ahora, si uso solo las funciones de Julia, generalmente llego a ~ 3 veces más lento que C. Después de esto, reemplazo los puntos calientes con funciones C (Julia viene con un generador de perfiles de muestreo de pila para ayudar a identificarlos). A menudo, esto solo requiere reemplazar las líneas de código del punto de acceso ofensivo con una "llamada", con Julia manejando cualquier clasificación.

Creo que lo principal que Julia está perdiendo en este momento, aunque eso me hace dudar en considerarlo para proyectos más grandes, es la falta de un depurador totalmente compatible y un soporte deficiente para trazar (en este momento, su mejor opción para trazar es en realidad solo una interfaz en matplotlib que he tenido descanso la mayoría de las veces). La retroalimentación inmediata sobre el código es realmente importante. Tampoco sé cómo sobrevivir sin una depuración interactiva, y en este sentido, estoy muy mimado por MATLAB y GDB.

Según mi experiencia, Julia todavía no está lista para el uso diario (científico) (estoy hablando de la versión estabilizada 0.4 de marzo de 2016). El lenguaje en sí es agradable, rico en características y consistente; Un refrescante paso adelante tanto de Matlab como de Python. Ciertamente, hay casos de uso en los que Julia es una buena opción incluso en esta etapa temprana. Pero si necesita bibliotecas científicas confiables y maduras, no puedo recomendar hacer el movimiento ahora. Los principales problemas que encontré son:

• Los paquetes fuera del núcleo de Julia no son confiables. Se rompen con las actualizaciones, cambian, se reemplazan, a veces son incompletas o simplemente se rompen.
• Las características de paralelismo de Julia (las características potenciales más prometedoras de Matlab Killer) son inmaduras. Encontrará fallas de segmentación, pérdidas de memoria, fallas y un rendimiento decepcionante. A veces no juegan bien con otras partes de julia, por ejemplo, algunos de los solucionadores para sistemas lineales o paquetes fuera del núcleo. Si bien estas características parecen prometedoras, a menudo fallaron lo suficiente para mí. Casi nunca fue suficiente simplemente escribir @parallelfrente al ciclo for, donde en teoría debería hacerlo.
• Muchas pequeñas cosas, pequeños errores y problemas con los que uno podría vivir: rastros de pila de llamadas no tan agradables y a veces erróneos, un pequeño historial de intérpretes con errores, carga lenta de paquetes, mal rendimiento de uno u otro paquete / función, etc. Lo que me molestó la mayoría es el paquete PyPlot, un contenedor para matplotlib, actualmente no hay alternativa. Es realmente genial que esté allí y funciona principalmente. Pero si necesita trazar datos, prepárese para un rendimiento y problemas muy lentos.

Todo esto mejorará. Estoy seguro de que algún día Julia será superior a Matlab y Python en casi todos los aspectos. Es muy probable que se desarrollen paquetes innovadores para ello. Parece que ya hay una gran comunidad. Incluso ahora hay una gran cantidad de paquetes con casos de uso que van desde opencl hasta servidores web. Usar las bibliotecas python o c es muy fácil, por lo que probablemente no se tope con un muro en términos de disponibilidad de la biblioteca. Una gran fortaleza de Julia será la facilidad con la que se puede unir la funcionalidad de alto rendimiento de varias fuentes en un lenguaje moderno y coherente de alto nivel (ver respuestas más arriba). Pero en su conjunto, descubrí que no era lo suficientemente maduro ni estable como para ser utilizado de manera productiva.