¿Tiene Julia alguna esperanza de quedarse en la comunidad estadística?

Recientemente leí una publicación de R-Bloggers, que se vinculaba a esta publicación de blog de John Myles White sobre un nuevo lenguaje llamado Julia . Julia se aprovecha de un compilador justo a tiempo que le da tiempos de ejecución rápidos y malvados y lo pone en el mismo orden de magnitud de velocidad que C / C ++ (el mismo orden , no igualmente rápido). Además, utiliza los mecanismos de bucle ortodoxos con los que estamos familiarizados aquellos de nosotros que comenzamos a programar en lenguajes tradicionales, en lugar de las declaraciones de aplicar R y las operaciones vectoriales.

R no va a desaparecer de ninguna manera, incluso con tiempos tan increíbles de Julia. Tiene un amplio soporte en la industria y numerosos paquetes maravillosos para hacer casi cualquier cosa.

Mis intereses son de naturaleza bayesiana, donde la vectorización a menudo no es posible. Ciertamente, las tareas en serie se deben realizar utilizando bucles e implican un gran cálculo en cada iteración. R puede ser muy lento en estas tareas de bucle en serie, y C / ++ no es un paseo por el parque para escribir. Julia parece una gran alternativa a escribir en C / ++, pero está en su infancia y carece de la funcionalidad que me encanta de R. Solo tendría sentido aprender a Julia como un banco de trabajo de estadísticas computacionales si obtiene suficiente soporte de la comunidad estadística y la gente comienza a escribir paquetes útiles para ello.

Mis preguntas siguen:

1. ¿Qué características necesita tener Julia para tener el encanto que hizo de R el lenguaje de facto de las estadísticas?

2. ¿Cuáles son las ventajas y desventajas de aprender a Julia a hacer tareas computacionalmente pesadas, en lugar de aprender un lenguaje de bajo nivel como C / ++?

Creo que la clave será si las bibliotecas comienzan a desarrollarse o no para Julia. Está muy bien ver ejemplos de juguetes (incluso si son juguetes complicados) que muestran que Julia saca a R del agua en las tareas en las que R es malo.

Pero los bucles mal hechos y los algoritmos codificados a mano no son la razón por la cual muchas de las personas que conozco que usan R usan R. Lo usan porque para casi cualquier tarea estadística bajo el sol, alguien ha escrito el código R para ello. R es tanto un lenguaje de programación como un paquete de estadísticas; en la actualidad, Julia es solo el primero.

Creo que es posible llegar allí, pero hay lenguajes mucho más establecidos (Python) que aún luchan por ser kits de herramientas estadísticas utilizables.

Estoy de acuerdo con muchos de los otros comentarios. "Esperanza"? Seguro. Creo que Julia ha aprendido mucho de lo que R y Python / NumPy / Pandas y otros sistemas han hecho bien y mal a lo largo de los años. Si fuera más inteligente de lo que soy y quisiera escribir un nuevo lenguaje de programación que sería el sustrato para un entorno de desarrollo estadístico en el futuro, se parecería mucho a Julia.

Dicho esto, pasarán 5 años antes de que esta pregunta pueda ser respondida en retrospectiva. A partir de ahora, Julia carece de los siguientes aspectos críticos de un sistema de programación estadística que podría competir con R para los usuarios cotidianos:

(lista actualizada con el tiempo ...)

• tipos de factores ordenados opcionalmente
• la mayoría de las pruebas estadísticas y modelos estadísticos
• programación analfabeta / soporte de análisis reproducible
• Trazado de clase R, o incluso de clase Matlab

Para competir con R, Julia y los paquetes de estadísticas adicionales deberán estar lo suficientemente limpios y completos como para que los no programadores inteligentes, digamos estudiantes de posgrado en ciencias sociales, puedan usarlo razonablemente. Hay mucho trabajo para llegar allí. Tal vez suceda, tal vez fracase, tal vez algo más (¿R 3.0?) Lo sustituirá.

Actualizar:

Julia ahora admite DataFrames con datos / NA faltantes, módulos / espacios de nombres, formulatipos e model.matrixinfraestructura, trazado (más o menos), soporte de bases de datos (pero todavía no para DataFrames) y pasar argumentos por palabras clave. Ahora también hay un IDE (Julia Studio), soporte de Windows, algunas pruebas estadísticas y algo de soporte de fecha / hora.

Para mí, una cosa muy importante para un lenguaje de análisis de datos es tener funcionalidad de álgebra de consulta / relacional con valores predeterminados razonables y diseño orientado de forma interactiva, e idealmente debería ser un lenguaje incorporado. En mi opinión, ningún lenguaje FOSS que he usado hace esto de manera efectiva, ni siquiera R.

data.frame es muy complicado para trabajar de forma interactiva; por ejemplo, imprime toda la estructura de datos en la invocación, la sintaxis $ es difícil de trabajar programáticamente, la consulta requiere auto referencia redundante (es decir, DF[DF$x < 10]), las uniones y la agregación son incómodas. Data.table resuelve la mayoría de estas molestias, pero como no es parte de la implementación principal, la mayoría del código R no hace uso de sus instalaciones.

Los pandas en python sufren las mismas fallas.

Estas quejas pueden parecer quisquillosas, pero estas fallas se acumulan y al final son significativas en conjunto, ya que terminan costando mucho tiempo.

Creo que si Julia tiene éxito como entorno de análisis de datos, se debe dedicar un esfuerzo a implementar operadores de tipo SQL (sin el equipaje de la sintaxis SQL) en un tipo de datos de tabla fácil de usar.

Puedo firmar bajo lo que dijeron Dirk y EpiGrad; Sin embargo, hay una cosa más que hace de R un idioma único en su nicho: el sistema de tipos orientado a datos.

R's fue especialmente diseñado para manejar datos, es por eso que está centrado en vectores y tiene cosas como data.frames, factores, NA y atributos.
Los tipos de Julia están, por otro lado, orientados al rendimiento numérico, por lo que tenemos escalares, modos de almacenamiento bien definidos, uniones y estructuras.

Esto puede parecer benigno, pero todos los que han intentado hacer estadísticas con MATLAB saben que realmente duele.

Entonces, al menos para mí, Julia no puede ofrecer nada que no pueda arreglar con un trozo C de pocas líneas y mata mucha expresividad realmente útil.

Puedo ver a Julia reemplazando a Matlab, lo que sería un gran servicio para la humanidad.

Para reemplazar R, deberías considerar todas las cosas que Neil G, Harlan y otros han mencionado, además de un gran factor que no creo que se haya abordado: la fácil instalación de la aplicación y sus bibliotecas.

En este momento, puede descargar un binario de R para Mac, Windows o Linux. Funciona fuera de la caja con una gran selección de métodos estadísticos. Si desea descargar un paquete, es un simple comando o clic del mouse. Simplemente funciona

Fui a descargar Julia y no es simple. Incluso si descarga el binario, debe tener instalado gfortran para obtener las bibliotecas adecuadas. Descargué la fuente e intenté makey falló sin un mensaje realmente útil. Tengo una licenciatura y un posgrado en ciencias de la computación, por lo que podría hurgar y hacer que funcione si estaba tan dispuesto. (No lo soy) ¿Joe Statistician hará eso?

R no solo tiene una gran selección de paquetes, tiene un sistema bastante sofisticado que crea binarios de la aplicación y casi todos los paquetes, automáticamente. Si, por alguna razón, necesita compilar un paquete desde el origen, eso no es realmente más difícil (siempre que tenga un compilador apropiado, etc., instalado en su sistema). No puede ignorar esta infraestructura, hacer todo a través de github y esperar una amplia adopción.

EDITAR: quería jugar con Julia, se ve emocionante. Dos problemas:

1) Cuando intenté instalar paquetes adicionales (olvídate de cómo se llaman en Julia), falló con oscuros errores. Evidentemente, mi Mac no tiene una herramienta similar a la que esperaban. No solo falla, sino que deja cosas por ahí que tengo que eliminar manualmente o otras instalaciones fallarán.

2) Forzan cierto espacio en una línea de código. No tengo los detalles frente a mí, pero tiene que ver con macros y no tener un espacio entre la macro y el paréntesis que abre sus argumentos. Ese tipo de restricción realmente me molesta, ya que he desarrollado mi formato de código durante muchos años y lenguajes y realmente pongo un espacio entre una función / nombre de macro y el paréntesis de apertura. Entiendo algunas restricciones de formato de código, pero ¿espacios en blanco dentro de una línea?

El lenguaje de Julia es bastante nuevo; Su tiempo en el foco puede medirse en semanas (aunque su tiempo de desarrollo puede medirse en años). Ahora, esas semanas en el punto de mira fueron semanas muy emocionantes --- vea, por ejemplo, la reciente charla en Stanford donde "acababa de comenzar" --- pero lo que pida en términos de infraestructura más amplia y soporte de paquetes llevará mucho más tiempo para materializar.

Así que seguiría usando R y sería consciente de las alternativas en desarrollo. El año pasado mucha gente se volvió loca por Clojure; este año Julia es el nuevo sabor reinante. Veremos si se pega.

Bruce Tate aquí, autor de Siete idiomas en siete semanas. Aquí hay algunos pensamientos. Estoy trabajando en Julia para el libro de seguimiento. Lo siguiente es solo mi opinión después de algunas semanas de juego.

Hay dos fuerzas fundamentales en juego. Primero, todos los idiomas tienen una vida útil. R será reemplazado algún día. No sabemos cuando. Los nuevos idiomas tienen un tiempo extremadamente difícil de evolucionar. Cuando un nuevo lenguaje evoluciona, generalmente resuelve un punto de dolor abrumador.

Estas dos cosas están relacionadas. Para mí, estamos empezando a ver que un tema toma forma alrededor de idiomas como R. No es lo suficientemente rápido, y es más difícil de lo que debe ser. Aquellos que pueden vivir dentro de un determinado sobre de rendimiento y permanecer en bibliotecas establecidas están bien. Aquellos que no pueden necesitar más y están empezando a buscar más.

La cuestión es que las arquitecturas informáticas están cambiando y, para aprovecharlas, el lenguaje y sus construcciones deben construirse de cierta manera. La opinión de Julia sobre la concurrencia es interesante. Optimiza lo correcto para dicho lenguaje: distribución transparente y el movimiento eficiente de datos entre procesos. Cuando uso a Julia para tareas típicas, mapas y transformaciones y cosas similares, solo estoy llamando a funciones. No tengo que preocuparme por la fontanería.

Para mí, el hecho de que Julia sea más rápida en un procesador es interesante, pero no demasiado perjudicial para R. Lo que es interesante para mí es que a medida que los procesadores dependen cada vez más del multinúcleo para el rendimiento, los problemas informáticos técnicos están en una posición ideal. para aprovechar al máximo, dado el lenguaje correcto.

La otra característica que ayudará a que eso suceda son las macros. El ritmo del idioma es intenso en este momento. Las macros le permiten construir con bloques de construcción más grandes y limpios. Mirar las bibliotecas es interesante pero no cuenta la imagen completa. Debe observar el crecimiento de las bibliotecas. La trayectoria de Julia es bastante acertada aquí.

Clojure es interesante para algunos porque no hay un lenguaje técnico que haga lo que R puede hacer, por lo que algunos buscan un lenguaje de propósito general para llenar ese vacío. En realidad soy un gran fan. Pero Clojure es una deformación cerebral bastante grave. Clojure estará allí para los programadores que necesitan hacer computación técnica. No será para ingenieros y científicos. Simplemente hay mucho que aprender.

Entonces, para mí, Julia o algo así reemplazará absolutamente a R algún día. Es cuestión de tiempo.

Cada vez que veo un nuevo idioma, me pregunto por qué no se puede mejorar un idioma existente.

Las grandes ventajas de Python son

• Un amplio conjunto de módulos (no solo estadísticas, sino también gráficas de bibliotecas, salida a pdf, etc.)
• construcciones de lenguaje que terminas necesitando a largo plazo (construcciones orientadas a objetos que necesitas en un gran proyecto; decoradores, cierres, etc. que simplifican el desarrollo)
• muchos tutoriales y una gran comunidad de soporte
• acceso a mapreduce, si tiene muchos datos para procesar y no le importa pagar unos centavos para ejecutarlos en un clúster.

Para superar a R, Julia, etc., Python podría usar

• desarrollo de compilación justo a tiempo para Python restringido para darle más velocidad en una sola máquina (pero mapreduce es aún mejor si puede soportar la latencia)
• una biblioteca estadística más rica

Julia no se hará cargo de R muy pronto. Echa un vistazo a Microsoft R abierto.

https://mran.revolutionanalytics.com/open/

Esta es una versión mejorada de R que usa automáticamente todos los núcleos de su computadora. Es la misma R, el mismo lenguaje, los mismos paquetes. Cuando lo instales, RStudio también lo usará en la consola. La velocidad de MRO es incluso más rápida que Julia. Hago mucha informática pesada y he usado a Julia más de un año. Cambié a R recientemente porque R tiene un mejor soporte y RStudio es un editor increíble. Julia todavía está en una etapa temprana y posiblemente no esté alcanzando a Python o R muy pronto.

Lo siguiente probablemente no merece ser una respuesta, pero es demasiado importante para ser enterrado como un comentario a la respuesta de otra persona ...

No he escuchado mucho sobre el consumo de memoria, solo la velocidad. El hecho de que la semántica completa de R pase por valor puede ser dolorosa, y esta ha sido una crítica del lenguaje (que es un tema separado de cuántos paquetes geniales ya existen). La buena gestión de la memoria es importante, al igual que tener formas de lidiar con el procesamiento fuera del núcleo (por ejemplo, matrices mapeadas en memoria o pytables de numpy , o el formato xdf de Revolution Analytics) Si bien el compilador JIT de PyPy permite algunos puntos de referencia llamativos de Python, el consumo de memoria puede ser bastante alto. Entonces, ¿alguien tiene experiencia con Julia y el uso de memoria todavía? Parece que hay pérdidas de memoria en la versión "alfa" de Windows que sin duda se abordarán, y todavía estoy esperando el acceso a una caja de Linux para jugar con el lenguaje yo mismo.

Creo que es poco probable que Julia reemplace a R, por muchas de las razones mencionadas anteriormente. Julia es un reemplazo de Matlab, no un reemplazo de R; Tienen diferentes objetivos. Incluso después de que Julia tenga una biblioteca de estadísticas completamente desarrollada, nadie enseñará una clase de Introducción a la Estadística en ella.

Sin embargo, un área en la que podría ser increíble es como un lenguaje de programación de velocidad optimizada que es menos doloroso que C / C ++. Si se vinculó sin problemas a R (en el estilo de Rcpp), sería muy útil escribir segmentos de código críticos para la velocidad. Lamentablemente, dicho enlace no existe actualmente:

https://stackoverflow.com/questions/9965747/linking-r-and-julia

Soy un novato de Julia y soy R competente. Las razones por las que a Julia me parece interesante hasta ahora están orientadas al rendimiento y la compatibilidad.

Herramientas de GPU. Me gustaría usar CUSPARSE para una aplicación estadística. Los resultados de CRAN indican que no hay mucho por ahí. Julia tiene enlaces disponibles que parecen funcionar sin problemas hasta ahora.

using CUSPARSE
N = 1000
M = 1000
hA = sprand(N, M, .01)
hA = hA' * hA
dA = CudaSparseMatrixCSR(hA)
dC = CUSPARSE.csric02(dA, 'O') #incomplete Cholesky decomp
hC = CUSPARSE.to_host(dC)

Herramientas de HPC. Se puede usar un clúster interactivamente con múltiples nodos de cómputo.

nnodes = 2
ncores = 12    #ask for all cores on the nodes we control
procs = addprocs(SlurmManager(nnodes*ncores), partition="tesla", nodes=nnodes)
for worker in procs
    println(remotecall_fetch(readall, worker, `hostname`))
end

Compatibilidad con Python. Hay acceso al ecosistema de Python. Por ejemplo, fue sencillo descubrir cómo leer datos de imágenes cerebrales:

import PyCall
@pyimport nibabel

fp = "foo_BOLD.nii.gz"
res = nibabel.load(fp)
data = res[:get_data]();

C compatibilidad. Lo siguiente genera un entero aleatorio usando la biblioteca estándar de C.

ccall( (:rand, "libc"), Int32, ())

Velocidad. Pensé que vería cómo funcionaba el paquete Distributions.jl contra el rnorm de R, que supongo está optimizado.

julia> F = Normal(3,1)
Distributions.Normal(μ=3.0, σ=1.0)

julia> @elapsed rand(F, 1000000)
0.03422067

En R:

> system.time(rnorm(1000000, mean=3, sd=1))
   user  system elapsed 
  0.262   0.003   0.266 

Julia 1.0 acaba de salir con un IDE muy útil (Juno). Llegó un poco tarde a la fiesta ya que Python ya ha dominado el aprendizaje automático, mientras que R continúa dominando cualquier otro tipo de análisis estadístico. Dicho esto, Julia ya está ganando protagonismo en el área de algoritmos financieros y comerciales, ya que el tiempo de desarrollo rápido y la ejecución son imprescindibles. En mi opinión, a menos que aparezca otro idioma que sea claramente mejor, el ascenso de Julia a la prominencia probablemente se verá así:

(1) Comienza a comer el almuerzo de MATLAB. A los usuarios de MATLAB les gusta la sintaxis de MATLAB pero odian prácticamente todo lo demás. La lentitud, las costosas licencias, las formas muy limitadas de manejar estructuras de datos complejas que no son matrices. Recuerdo una cita en la que se dice que "si Julia reemplaza a MATLAB, será un gran servicio para la humanidad". Los usuarios de MATLAB pueden llegar a dominar a Julia muy rápidamente y quedarán impresionados por la facilidad con la que se escribe código de calidad que hace mucho más de lo que MATLAB puede hacer (¿Estructuras que son rápidas que puede colocar en matrices e iterar rápidamente?). No solo esto, los investigadores pueden hacer cajas de herramientas serias en Julia (un pequeño equipo de estudiantes de doctorado escribió un paquete de ecuaciones diferenciales de clase mundial) que hubiera sido imposible con MATLAB.

(2) Comienza a hacerse cargo de la investigación en métodos numéricos y simulación. El MIT está respaldando a Julia, y la comunidad de investigadores escucha al MIT. Las simulaciones numéricas y los nuevos métodos numéricos son problemas mal definidos que no tienen bibliotecas. Aquí es donde brilla Julia como idioma; Si no hay bibliotecas disponibles, es mucho más fácil escribir código de calidad rápida en Julia que en cualquier otro idioma. Será un lenguaje numérico / de simulación escrito por matemáticos para matemáticos (¿suena similar a R todavía?)

(3) Otro avance en Machine Learning ocurre que le da a Julia la ventaja. Este es un poco un comodín que podría no suceder. TensorFlow es genial, pero es extremadamente difícil de hackear. Python ya comenzó a mostrar grietas y TensorFlow comenzó a adoptar Swift (con Julia recibiendo una mención de honor). Si ocurre otro avance en el aprendizaje automático, será mucho más fácil implementar y piratear un paquete de Julia como Flux.jl.

(4) Julia comienza a alcanzar lentamente a R, lo que llevará un tiempo. Hacer estadísticas en MATLAB es doloroso, pero Juila ya está muy por delante de MATLAB con Distributions.jl. El hecho es que los flujos de trabajo R se pueden traducir fácilmente a Julia. La única ventaja real que tiene R es el hecho de que hay muchos paquetes escritos por estadísticos para estadísticos. Sin embargo, este proceso también es fácil de hacer en Julia. La diferencia es que Julia es rápida y no tiene que usar otro idioma para el rendimiento (los paquetes R más "serios" están escritos en lenguajes como C). El problema con R es que los paquetes escritos en R son demasiado lentos para manejar grandes conjuntos de datos. La única alternativa es traducir los paquetes a otro idioma haciendo que el desarrollo en R sea un proceso más lento que Julia.

Me interesa la promesa de una mejor velocidad y una fácil paralelización utilizando diferentes arquitecturas. Por esa razón, ciertamente veré el desarrollo de Julia, pero es poco probable que lo use hasta que pueda manejar modelos mixtos lineales generalizados, tenga un buen paquete de arranque genérico, un lenguaje de modelo simple para construir matrices de diseño, la capacidad equivalente a ggplot2 y una amplia gama de algoritmos de aprendizaje automático.

Ningún estadista puede permitirse tener una actitud fundamentalista respecto a la elección de herramientas. Utilizaremos lo que nos permita realizar el trabajo de la manera más eficiente. Supongo que todavía me quedaré con R durante algunos años, pero sería agradable estar gratamente sorprendido.

El lujo de NA en R no viene sin penalizaciones de rendimiento. Si Julia admite NA con una penalización de rendimiento menor, se vuelve interesante para un segmento de la comunidad de estadísticas, pero NA también impone un trabajo adicional considerable cuando se usa código compilado con R.

Muchos de los paquetes en R se basan en rutinas escritas en lenguajes heredados (C, Fortran o C ++). En algunos casos, las rutinas compiladas se desarrollaron fuera de R y luego se usaron como base para los paquetes de la biblioteca R. En otros, las rutinas se implementaron primero en R y luego los segmentos críticos se tradujeron a un lenguaje compilado cuando se descubrió que faltaba rendimiento. Julia será atractiva si se puede usar para implementar rutinas equivalentes Existe la oportunidad de diseñar soporte de bajo nivel para NA de una manera que simplifique el manejo de NA sobre lo que tenemos ahora cuando usamos R con código compilado.

La gran cantidad de bibliotecas R representa los esfuerzos de muchos usuarios. Esto fue posible porque R proporcionó capacidades que de otro modo no estaban disponibles / asequibles. Si Julia se va a utilizar ampliamente, necesita un grupo de usuarios que descubran que hace lo que necesitan mucho mejor que las alternativas que vale la pena el esfuerzo necesario para proporcionar cosas muy básicas (por ejemplo, gráficos, clases de fechas, NA, etc.) ) disponible en idiomas existentes.

Seré directo, no tengo experiencia con R, pero trabajo con muchas personas que piensan que es una excelente herramienta para el análisis estadístico. Mi experiencia es en el almacenamiento de datos, y debido al modelo de programación fácilmente distribuido pero más estándar de Julia, creo que podría ser un sustituto muy interesante para la parte de transformación de las herramientas ETL tradicionales que generalmente hacen el trabajo muy mal, la mayoría no tiene forma de crear fácilmente una transformación estandarizada o reutilizar los resultados de una transformación ya realizada en un conjunto de datos anterior. Se destaca el soporte para tuplas tipeadas y definidas, si quiero construir un cubo OLAP que básicamente necesita construir tuplas más detalladas (tablas de hechos) a partir de tuplas ya calculadas, las herramientas ETL de hoy no tienen 'bloques de construcción' para hablar de eso. poder ayudar, Esta industria ha trabajado en torno a este problema a través de diversos medios en el pasado, pero hay compensaciones. Los lenguajes de programación tradicionales pueden ayudar al proporcionar transformaciones definidas centralmente, y Julia podría simplificar las agregaciones y distribuciones no estándar comunes en los sistemas de almacenamiento de datos más complejos.

También puedes usar Julia y R juntas. Hay interfaz de Julia-a-R . Con estos paquetes puedes jugar con Julia mientras llamas a R cuando tenga una biblioteca que sea necesaria.

Julia tiene, sin duda, todas las posibilidades de convertirse en un sueño de los usuarios avanzados de las estadísticas hecho realidad, tome SAS por ejemplo, su poder radica en los numerosos procesos escritos en C: lo que Julia puede hacer es proporcionarle los procesos con el código fuente, con matrices como un dispensador de tipo de datos incorporado con SAS / iml. No tengo dudas de que los estadísticos acudirán en masa a Julia una vez que se den cuenta de lo que este cachorro puede hacer.

Ah, sí, Julia superará a R bastante rápido. Y las razones principales serán "macros", el 95% del lenguaje se implementa en Julia, y su sintaxis parsimoniosa y sin ruido. Si no tiene experiencia con el tipo de lenguajes lisp, es posible que aún no lo entienda, pero verá muy rápidamente cómo la interfaz de fórmula R se convertirá en un mecanismo obsoleto y feo, y será reemplazado por micro lenguajes de modelado especializados similares a CL macro de bucle El acceso a referencias de bajo nivel de un objeto también es una gran ventaja. Creo que R aún no entendía que ocultar aspectos internos del usuario realmente complica y simplifica las cosas.

Como lo veo ahora (teniendo años de uso intensivo de R detrás, y acaba de terminar de leer el manual de Julia), los principales inconvenientes de Julia con respecto a R no son soporte para la herencia estructural (esto fue intencional). El sistema de tipos de Julia es menos ambicioso que S4; también admite despacho múltiple y herencia múltiple, pero con una captura: solo hay un nivel de clases concretas. Por otro lado, rara vez veo jerarquías de clases en R más profundas que 3 niveles.

El tiempo lo dirá, pero será antes de lo que la mayoría de los usuarios de R piensan :)

Los primeros casos de uso objetivo de Julia son problemas numéricos. Básicamente, puede dividir estos campos de análisis y ciencia computacional en ciencia de datos (basada en datos) y ciencia de simulación (basada en modelos). Julia se ocupa primero de los casos de uso de la ciencia de la simulación. También se ocupan de los casos de la ciencia de datos, pero más lentamente. R nunca será muy útil para la ciencia de la simulación, pero Julia será muy útil para ambos en un par de años.

Debe poder aplicar cualquier función a grandes conjuntos de datos que no se ajusten a la memoria de forma transparente para el usuario.
Eso incluye al menos ejecutar modelos de efectos mixtos, modelos de supervivencia o MCMC en conjuntos de datos que se ajustan en el disco pero no en la memoria. Y si es posible en conjuntos de datos distribuidos en varias computadoras.