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

55

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?

Nathaniel
fuente
2
Parece que esta pregunta podría no ser adecuada para el formato Stack Exchange porque es subjetiva. Conozco a algunas personas que se desarrollan activamente en Julia, les encanta y piensan que está totalmente listo para el horario estelar (siempre que esté dispuesto a actualizar su base de código en respuesta a los cambios en la API de Julia). Hay otras personas que no sienten la necesidad de usar a Julia en este momento (como yo).
Geoff Oxberry
1
Ser subjetivo en sí mismo no hace una pregunta inadecuada para el formato Stack Exchange: consulte blog.stackoverflow.com/2010/09/good-subjective-bad-subjective . Si tiene una política del sitio contra preguntas subjetivas, le pido disculpas. Sin embargo, creo que es solo un poco subjetivo: su comentario ya me da una mejor idea de la situación que la que tenía antes de hacer la pregunta. Puede ser muy difícil para un extraño tener una idea aproximada de cuán maduro es un proyecto.
Nathaniel
Su punto sobre los cambios de API parece bastante importante para mí, por lo que agregué un párrafo a la pregunta que solicita específicamente detalles al respecto. Si actualizar a Julia tenderá a romper mi código anterior, podría ser un poco decisivo para mí en esta etapa.
Nathaniel
Tienes toda la razón sobre "subjetivo bueno versus subjetivo malo" (una de mis publicaciones favoritas del blog de Stack Exchange); Publiqué el comentario porque estoy esperando ver la respuesta. Con estos "¿qué opinas sobre _____?" preguntas, las respuestas pueden limitarse a un par de publicaciones muy bien pensadas, o pueden ser extensas, repetitivas y repetitivas "¡yo también!" publicaciones Lo primero es genial; este último no lo es, así que les doy un mensaje de cortesía para decir: veamos cómo funciona esto.
Geoff Oxberry
3
Gracias por publicar una recompensa, @AntonMenshov. Observo que Julia ahora aprobó la versión 1.0 (que no tenía en 2014 cuando publiqué esto), por lo que sería muy bueno tener una respuesta actualizada.
Nathaniel

Respuestas:

44

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.

Chris Rackauckas
fuente
2
Gran respuesta. Una pregunta: ¿Julia permite una evolución elegante del código de investigación a un sistema de producción? ¿O es más como matlab donde no hay esperanza?
user14717
66
Muchos paquetes, como DifferentialEquations.jl, comenzaron como código para un proyecto de investigación . El sistema de empaquetado de Julia hace que sea bastante simple convertir el código de trabajo en un paquete con CI y pruebas unitarias para mantenimiento futuro. Y el hecho de que la mayoría del código es puro Julia hace que la implementación sea mucho más fácil ya que no tiene que mantener un montón de sistemas de compilación / binarios. Entonces definitivamente diría que sí. Tenemos algunos códigos de propiedad que se lanzarán pronto. Lo único que aún falta es construir binarios (PackageCompiler).
Chris Rackauckas
28

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.

Geoff Oxberry
fuente
¿Qué te hace asumir 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. No me malinterpreten, me encantaría tener una mejor herramienta disponible que C ++ / Python / Fortran / Matlab (y no sé nada sobre Julia), pero ha habido muchos intentos de nuevos lenguajes HPC que han fallado.
Aurelius
3
Con respecto a los cambios de última hora, en realidad ha habido muy pocos cambios de lenguaje de última hora (es decir, sintaxis, semántica) desde antes de 0.1, hace más de un año, de hecho, no puedo pensar en ninguno, el lenguaje central es bastante estable. Los problemas etiquetados como "rotos" son cambios en las API de biblioteca estándar. Estos son bastante fáciles de manejar al dejar los métodos de desaprobación que permiten que su código anterior siga funcionando pero imprima una advertencia. Los paquetes son mucho más cambiantes, por lo que sospecho que en este momento el verdadero problema es que actualizar sus paquetes puede romper su código incluso si el lenguaje en sí no lo hace.
StefanKarpinski
Gracias por la edición Geoff, buena entrada. Espero que algo mejor tenga éxito. Es un poco perverso pensar que semanalmente uso Matlab para la creación rápida de prototipos de algos, python para automatización / scripting y C ++ y / o Fortran para trabajo "serio", pero ese es el mundo en el que vivimos. Aunque tristemente pesimista. La tendencia de 5-10 años en HPC es la programación heterogénea y el paralelismo masivo, y eso es intrínsecamente difícil de crear un lenguaje simple. Su batalla cuesta arriba es una pendiente muy empinada por muchas razones.
Aurelius
Gran análisis Quería decir que todo lo que haces por HPC siempre está ligeramente roto. Es un espacio de innovación, donde hacer / romper es parte del curso. Julia tiene muchas cosas buenas que hacer, pero creo que muchos de los trucos provienen de la integración LLVM, nuevamente un objetivo muy conmovedor. Aprendería un poco, pero dale unos años hasta que esperes usarlo día a día.
meawoppl
21

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.

Reid.Atcheson
fuente
Gracias, esta es una respuesta muy útil. Tengo algunas preguntas de seguimiento. En primer lugar, ¿utiliza una versión lanzada o se mantiene al día con la fuente? Si es esto último, ¿tiene muchos problemas con la ruptura de su código debido a actualizaciones? En segundo lugar, ¿cómo se "rompe" exactamente la interfaz de matplotlib? En realidad, estaba bastante emocionado de escuchar que el trazado se realizó a través de matplotlib, porque puede representar LaTeX en etiquetas de eje (LaTeX real, usando una instalación de TeX), y para mí esa es una característica excelente. Pero si la interfaz es escamosa, entonces no es tan genial ...
Nathaniel
Me mantengo al día con la fuente porque también estoy tratando de contribuir al proyecto. Hasta ahora no he tenido ningún descanso, pero solo tuve una gran cantidad de escritura y teoría y ahora estoy volviendo a mi código y veremos cómo funciona. Las matrices de Numpy están indexadas en 0 y de fila principal de forma predeterminada. y Julia está indexada en 1 y tiene una columna principal de forma predeterminada, por lo general esto no causa problemas, pero el trazado de datos no estructurados requiere que se pasen las matrices de índice, por lo que he tenido que hacer cosas extrañas como pasar p'-1 a una malla triangular no estructurada rutinas, donde p es un mapa de índice.
Reid.Atcheson
9

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.

johannes_lalala
fuente