Julia ha qualche speranza di restare nella comunità statistica?

Di recente ho letto un post di R-Blogger, collegato a questo post di John Myles White su una nuova lingua chiamata Julia . Julia si avvale di un compilatore just-in-time che gli fornisce tempi di esecuzione rapidi malvagi e lo pone sullo stesso ordine di grandezza della velocità di C / C ++ (lo stesso ordine , non altrettanto veloce). Inoltre, utilizza i meccanismi di looping ortodossi che hanno familiarità con quelli di noi che hanno iniziato a programmare su linguaggi tradizionali, anziché le istruzioni di R e le operazioni vettoriali.

R non se ne va affatto, anche con tempi così fantastici da Julia. Ha un ampio supporto nel settore e numerosi pacchetti meravigliosi per fare praticamente qualsiasi cosa.

I miei interessi sono di natura bayesiana, dove spesso vettorializzare non è possibile. Certamente le attività seriali devono essere eseguite usando loop e comportano un calcolo pesante ad ogni iterazione. R può essere molto lento in queste attività di loop seriale e C / ++ non è una passeggiata nel parco per scrivere. Julia sembra un'ottima alternativa alla scrittura in C / ++, ma è nella sua infanzia e manca di molte funzionalità che amo di R. Avrebbe senso imparare Julia come banco di lavoro di statistica computazionale se ottiene abbastanza supporto dalla comunità delle statistiche e le persone iniziano a scrivere pacchetti utili per questo.

Le mie domande seguono:

1. Quali caratteristiche deve avere Julia per avere il fascino che ha reso R il linguaggio di fatto delle statistiche?

2. Quali sono i vantaggi e gli svantaggi di imparare Julia a svolgere compiti pesanti dal punto di vista computazionale, rispetto all'apprendimento di un linguaggio di basso livello come C / ++?

Penso che la chiave sarà se le librerie inizieranno o meno a essere sviluppate per Julia. Va bene vedere esempi di giocattoli (anche se sono giocattoli complicati) che mostrano che Julia soffia R fuori dall'acqua nei compiti in cui R è pessimo.

Ma i cicli mal eseguiti e gli algoritmi codificati a mano non sono il motivo per cui molte delle persone che conosco che usano R usano R. Lo usano perché per quasi tutte le attività statistiche sotto il sole, qualcuno ha scritto il codice R per questo. R è sia un linguaggio di programmazione che un pacchetto statistico - attualmente Julia è solo la prima.

Penso che sia possibile arrivarci, ma ci sono linguaggi molto più affermati (Python) che ancora lottano per essere strumenti statistici utilizzabili.

Sono d'accordo con molti altri commenti. "Speranza"? Sicuro. Penso che Julia abbia imparato molto da ciò che R e Python / NumPy / Panda e altri sistemi hanno fatto bene e male nel corso degli anni. Se fossi più intelligente di me e volessi scrivere un nuovo linguaggio di programmazione che sarebbe il substrato per un ambiente di sviluppo statistico in futuro, assomiglierebbe molto a Julia.

Detto questo, ci vorranno 5 anni prima che a questa domanda si possa eventualmente rispondere a posteriori. A partire da ora, a Julia mancano i seguenti aspetti critici di un sistema di programmazione statistica che potrebbe competere con R per gli utenti quotidiani:

(elenco aggiornato nel tempo ...)

• tipi di fattore ordinati facoltativamente
• la maggior parte dei test statistici e dei modelli statistici
• supporto di analisi programmabili / riproducibili
• Tracciato di classe R o addirittura di classe Matlab

Per competere con R, Julia e i pacchetti di statistiche add-on dovranno essere abbastanza puliti e completi abbastanza che i non programmatori intelligenti, dicono gli studenti delle scienze sociali, possano ragionevolmente usarlo. C'è un sacco di lavoro da fare per arrivarci. Forse succederà, forse si consumerà, forse qualcos'altro (R 3.0?) Lo sostituirà.

Aggiornare:

Julia ora supporta DataFrames con dati / NA mancanti, moduli / spazi dei nomi, formulatipi e model.matrixinfrastruttura, stampa (sorta), supporto per il database (ma non ancora per DataFrames) e trasmissione di argomenti tramite parole chiave. Ora esiste anche un IDE (Julia Studio), supporto per Windows, alcuni test statistici e supporto per data / ora.

Per me, una cosa molto importante per un linguaggio di analisi dei dati è disporre di funzionalità di algebra relazionale / relazionale con valori predefiniti ragionevoli e design orientato interattivamente, e idealmente dovrebbe essere integrato nel linguaggio. IMO, nessun linguaggio FOSS che ho usato lo fa efficacemente, nemmeno R.

data.frame è molto ingombrante con cui interagire in modo interattivo - ad esempio, stampa l'intera struttura dei dati durante l'invocazione, la sintassi $ è difficile da lavorare programmaticamente, la query richiede un auto-riferimento ridondante (cioè, DF[DF$x < 10]), i join e l'aggregazione sono scomodi. Data.table risolve la maggior parte di questi fastidi, ma poiché non fa parte dell'implementazione di base, la maggior parte del codice R non utilizza le sue funzionalità.

I panda in pitone soffrono degli stessi difetti.

Queste lamentele possono sembrare pignole, ma questi difetti si accumulano e alla fine sono significativi in ​​termini di aggregazione poiché finiscono per costare molto tempo.

Credo che se Julia deve avere successo come ambiente di analisi dei dati, è necessario impegnarsi per implementare operatori di tipo SQL (senza il bagaglio della sintassi SQL) su un tipo di dati di tabella intuitivo.

Posso firmare sotto quello che hanno detto Dirk ed EpiGrad; eppure c'è un'altra cosa che rende R un linguaggio unico nella sua nicchia: il sistema di tipi orientato ai dati.

R è stato appositamente progettato per la gestione dei dati, ecco perché è centrato sui vettori e ha elementi come data.frames, fattori, NA e attributi.
I tipi di Julia sono d'altra parte orientati alle prestazioni numeriche, quindi abbiamo scalari, modalità di memorizzazione ben definite, sindacati e strutture.

Questo può sembrare benigno, ma chiunque abbia mai provato a fare statistiche con MATLAB sa che fa davvero male.

Quindi, almeno per me, Julia non può offrire nulla che non posso risolvere con un pezzo di C a poche righe e uccide molta espressività davvero utile.

Vedo Julia che sostituisce Matlab, che sarebbe un enorme servizio per l'umanità.

Per sostituire R, dovresti considerare tutte le cose che Neil G, Harlan e altri hanno menzionato, oltre a un grande fattore che non credo sia stato risolto: una facile installazione dell'applicazione e delle sue librerie.

Adesso puoi scaricare un binario di R per Mac, Windows o Linux. Funziona immediatamente con una vasta selezione di metodi statistici. Se vuoi scaricare un pacchetto, è un semplice comando o un clic del mouse. Funziona e basta.

Sono andato a scaricare Julia e non è semplice. Anche se scarichi il binario, devi avere gfortran installato per ottenere le librerie appropriate. Ho scaricato la fonte e ho provato a makefarlo e non è riuscito senza un messaggio davvero utile. Ho una laurea e una laurea in informatica, quindi potrei curiosare e farlo funzionare se ero così propenso. (Non lo sono.) Joe Statistician lo farà?

R non ha solo una vasta selezione di pacchetti, ha un sistema abbastanza sofisticato che rende automaticamente binari dell'applicazione e quasi tutti i pacchetti. Se, per qualche motivo, è necessario compilare un pacchetto dal sorgente, non è affatto più difficile (purché nel proprio sistema sia installato un compilatore appropriato, ecc.). Non puoi ignorare questa infrastruttura, fare tutto tramite github e aspettarti un'adozione ampia.

EDIT: Volevo scherzare con Julia - sembra eccitante. Due problemi:

1) Quando ho provato a installare pacchetti aggiuntivi (dimentica quello che vengono chiamati in Julia), non è riuscito con errori oscuri. Evidentemente il mio Mac non ha uno strumento simile a quello che si aspettavano. Non solo fallisce, ma lascia in giro cose che devo eliminare manualmente o altre installazioni falliranno.

2) Costringono una certa spaziatura in una riga di codice. Non ho i dettagli di fronte a me, ma ha a che fare con le macro e non avere uno spazio tra la macro e la parentesi che apre i suoi argomenti. Questo tipo di restrizione mi infastidisce molto, dal momento che ho sviluppato la mia formattazione del codice in molti anni e lingue e in effetti inserisco uno spazio tra una funzione / nome macro e la parentesi di apertura. Alcune restrizioni di formattazione del codice capisco, ma gli spazi all'interno di una riga?

La lingua Julia è piuttosto nuova; è il tempo in cui la luce spot può essere misurata in settimane (anche se il suo tempo di sviluppo può ovviamente essere misurato in anni). Ora quelle settimane sotto i riflettori sono state settimane molto eccitanti --- vedi per esempio il recente discorso a Stanford in cui "era appena iniziato" --- ma quello che chiederai in termini di più ampia infrastruttura e supporto ai pacchetti richiederà molto più tempo materializzarsi.

Quindi continuerei a usare R ed essere consapevole delle alternative di sviluppo. L'anno scorso molte persone sono andate a galla per Clojure; quest'anno Julia è il nuovo sapore regnante. Vedremo se si attacca.

Bruce Tate qui, autore di Seven Languages ​​in Seven Weeks. Ecco alcuni pensieri. Sto lavorando su Julia per il libro di follow-up. Quella che segue è solo la mia opinione dopo alcune settimane di gioco.

Ci sono due forze fondamentali in gioco. Innanzitutto, tutte le lingue hanno una durata. R verrà sostituito un giorno. Non sappiamo quando. Le nuove lingue hanno un momento estremamente difficile in evoluzione. Quando una nuova lingua si evolve, di solito risolve un punto doloroso travolgente.

Queste due cose sono correlate. Per me, stiamo iniziando a vedere un tema che prende forma intorno a lingue come R. Non è abbastanza veloce ed è più difficile di quanto debba essere. Coloro che possono vivere all'interno di una determinata dotazione prestazionale e rimanere all'interno delle biblioteche stabilite stanno bene. Coloro che non possono aver bisogno di più e stanno iniziando a cercare di più.

Il fatto è che le architetture informatiche stanno cambiando e, per sfruttarle, il linguaggio e i suoi costrutti devono essere costruiti in un certo modo. L'interpretazione di Julia sulla concorrenza è interessante. Ottimizza la cosa giusta per un tale linguaggio: distribuzione trasparente e lo spostamento efficiente dei dati tra i processi. Quando uso Julia per compiti tipici, mappe e trasformazioni e simili, chiamo solo funzioni. Non devo preoccuparmi dell'impianto idraulico.

Per me, il fatto che Julia sia più veloce su un processore è interessante, ma non eccessivamente dannoso per R. La cosa interessante per me è che poiché i processori dipendono sempre di più dal multicore per le prestazioni, i problemi di calcolo tecnico sono quasi idealmente posizionati per trarre il massimo vantaggio possibile, data la lingua giusta.

L'altra caratteristica che aiuterà ciò che accade sono le macro. Il ritmo della lingua è solo intenso in questo momento. Le macro ti consentono di costruire con blocchi più grandi e più puliti. Guardare le biblioteche è interessante ma non racconta l'intero quadro. Devi guardare alla crescita delle biblioteche. La traiettoria di Julia è praticamente perfetta qui.

Clojure è interessante per alcuni perché non esiste un linguaggio tecnico che faccia ciò che R può, quindi alcuni cercano un linguaggio generico per colmare quel vuoto. In realtà sono un grande fan. Ma Clojure è un ordito cerebrale piuttosto grave. Clojure sarà lì per i programmatori che devono fare calcoli tecnici. Non sarà per ingegneri e scienziati. C'è troppo da imparare.

Quindi per me, Julia o qualcosa del genere sostituirà assolutamente R un giorno. È una questione di tempo.

Ogni volta che vedo una nuova lingua, mi chiedo perché non è possibile migliorare una lingua esistente.

I grandi vantaggi di Python sono

• un ricco set di moduli (non solo statistiche, ma stampa librerie, output in pdf, ecc.)
• costrutti linguistici di cui alla fine hai bisogno (costrutti orientati agli oggetti di cui hai bisogno in un grande progetto; decoratori, chiusure, ecc. che semplificano lo sviluppo)
• molti tutorial e una vasta community di supporto
• accedi a mapreduce, se hai molti dati da elaborare e non ti dispiace pagare qualche centesimo per eseguirli su un cluster.

Per superare R, Julia, ecc., Python potrebbe usare

• sviluppo della compilazione just-in-time per Python con restrizioni per darti più velocità su un singolo computer (ma mapreduce è ancora migliore se riesci a resistere alla latenza)
• una biblioteca statistica più ricca

Julia non prenderà il controllo di R molto presto. Scopri Microsoft R aperto.

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

Questa è una versione avanzata di R che utilizza automaticamente tutti i core del tuo computer. È la stessa R, stessa lingua, stessi pacchetti. Quando lo installi, RStudio lo utilizzerà anche nella console. La velocità di MRO è persino più veloce di Julia. Faccio molto lavoro pesante e ho usato Julia per più di un anno. Di recente sono passato a R perché R ha un supporto migliore e RStudio è un editor fantastico. Julia è ancora in fase iniziale e probabilmente non raggiungerà Python o R molto presto.

Quanto segue probabilmente non merita di essere una risposta, ma è troppo importante per essere sepolto come un commento alla risposta di qualcun altro ...

Non ho sentito molto parlare del consumo di memoria, solo della velocità. L'intera semantica di R essendo pass-by-value può essere dolorosa, e questa è stata una critica al linguaggio (che è un problema separato da quanti grandi pacchetti esistono già). Una buona gestione della memoria è importante, così come avere modi di gestire l'elaborazione out-of-core (ad esempio array o pytable mappati in memoria di numpy o il formato xdf di Revolution Analytics). Mentre il compilatore JIT di PyPy consente alcuni benchmark Python sorprendenti, il consumo di memoria può essere piuttosto elevato. Quindi, qualcuno ha ancora esperienza con Julia e l'utilizzo della memoria? Sembra che ci siano perdite di memoria nella versione "alpha" di Windows che senza dubbio verranno risolte e sto ancora aspettando l'accesso a un box Linux per giocare con la lingua da solo.

Penso che sia improbabile che Julia sostituirà mai R, per molte delle ragioni precedentemente menzionate. Julia è una sostituzione Matlab, non una sostituzione R; hanno obiettivi diversi. Anche dopo che Julia ha una biblioteca di statistiche completamente definita, nessuno ci insegnerà mai una lezione di introduzione alla statistica.

Tuttavia, un'area in cui potrebbe essere incredibile è un linguaggio di programmazione ottimizzato per la velocità che è meno doloroso di C / C ++. Se fosse perfettamente collegato a R (nello stile di Rcpp), vedrebbe un sacco di utilizzo nella scrittura di segmenti di codice critici per la velocità. Purtroppo al momento non esiste un link simile:

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

Sono un novizio di Julia e sono competente. I motivi per cui trovo Julia interessante finora sono orientati alle prestazioni e alla compatibilità.

Strumenti GPU. Vorrei usare CUSPARSE per un'applicazione statistica. I risultati di CRAN indicano che non c'è molto là fuori. Julia ha a disposizione attacchi che sembrano funzionare senza problemi finora.

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)

Strumenti HPC. È possibile utilizzare un cluster in modo interattivo con più nodi di calcolo.

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

Compatibilità con Python. C'è accesso all'ecosistema Python. Ad esempio, è stato semplice scoprire come leggere i dati di imaging del cervello:

import PyCall
@pyimport nibabel

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

Compatibilità C. Di seguito viene generato un numero intero casuale utilizzando la libreria standard C.

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

Velocità. Ho pensato di vedere come il pacchetto Distributions.jl si è comportato in modo anomalo rispetto a R's rnorm, che presumo sia ottimizzato.

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

julia> @elapsed rand(F, 1000000)
0.03422067

In R:

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

Julia 1.0 è appena uscito con un IDE molto utilizzabile (Juno). È uscito un po 'tardi alla festa poiché Python ha già dominato Machine Learning, mentre R continua a dominare ogni altro tipo di analisi statistica. Detto questo, Julia sta già diventando importante nel settore della finanza e degli algoritmi di trading poiché i tempi rapidi di sviluppo E l'esecuzione sono indispensabili. Secondo me, a meno che non appaia un'altra lingua che sia nettamente migliore, l'ascesa alla ribalta di Julia probabilmente assomiglierà a qualcosa del genere:

(1) Inizia a mangiare il pranzo di MATLAB. Agli utenti MATLAB piace la sintassi MATLAB ma odiano praticamente tutto il resto. La lentezza, le costose licenze, i modi molto limitati di gestire strutture dati complesse che non sono matrici. Ricordo una citazione in cui si dice che "Se Julia sostituirà MATLAB, sarà un enorme servizio per l'umanità". Gli utenti di MATLAB possono acquisire familiarità con Julia molto rapidamente e resteranno colpiti dalla facilità con cui è possibile scrivere un codice di qualità che fa molto di più di quello che MATLAB può fare (strutture veloci che è possibile inserire in array e scorrere rapidamente?). Non solo, i ricercatori possono creare serie di strumenti a Julia (un piccolo team di dottorandi ha scritto un pacchetto di equazioni differenziali di livello mondiale) che sarebbe stato impossibile con MATLAB.

(2) Inizia a rilevare la ricerca di metodi numerici e simulazione. Il MIT sta gettando il suo peso dietro Julia e la comunità di ricerca ascolta il MIT. Le simulazioni numeriche e i nuovi metodi numerici sono problemi mal definiti che non hanno librerie. Qui è dove brilla Julia come lingua; se non ci sono librerie disponibili, è molto più facile scrivere un codice di qualità veloce in Julia rispetto a qualsiasi altra lingua. Sarà un linguaggio numerico / di simulazione scritto dai matematici per i matematici (sembra ancora simile a R?)

(3) Accade un altro passo avanti nell'apprendimento automatico che dà a Julia il vantaggio. Questo è un po 'un jolly che potrebbe non accadere. TensorFlow è eccezionale, ma è estremamente difficile da hackerare. Python ha già iniziato a mostrare crepe e TensorFlow ha iniziato ad adottare Swift (con Julia che ha ricevuto una menzione d'onore). Se si verifica un'altra svolta nel machine learning, sarà molto più semplice implementare e hackerare in un pacchetto Julia come Flux.jl.

(4) Julia inizia lentamente a raggiungere R, che richiederà del tempo. Fare statistiche in MATLAB è doloroso, ma Juila è già molto più avanti di MATLAB con Distributions.jl. Il fatto è che i flussi di lavoro R possono essere facilmente tradotti in Julia. L'unico vero vantaggio che R ha è il fatto che ci sono così tanti pacchetti scritti da statistici per statistici. Questo processo, tuttavia, è anche facile da fare a Julia. La differenza è che Julia è veloce e non devi usare un'altra lingua per le prestazioni (i pacchetti R più "seri" sono scritti in lingue come C). Il problema con R è che i pacchetti scritti in R sono troppo lenti per gestire grandi serie di dati. L'unica alternativa è quella di tradurre i pacchetti in un'altra lingua rendendo lo sviluppo in R un processo più lento di Julia.

Sono interessato dalla promessa di una migliore velocità e facilità di parallelizzazione utilizzando architetture diverse. Per questo motivo guarderò sicuramente lo sviluppo di Julia, ma è improbabile che lo utilizzerò fino a quando non sarà in grado di gestire modelli misti lineari generalizzati, ha un buon pacchetto bootstrap generico, un linguaggio di modello semplice per la costruzione di matrici di progettazione la capacità equivalente a ggplot2 e una vasta gamma dagli algoritmi di apprendimento automatico.

Nessuno statistico può permettersi di avere un atteggiamento fondamentalista nei confronti della scelta degli strumenti. Useremo qualunque cosa ci consenta di svolgere il lavoro nel modo più efficiente. Suppongo che starò ancora con R per qualche anno, ma sarebbe bello essere piacevolmente sorpresi.

Il lusso di NA in R non arriva senza penalità di prestazione. Se Julia supporta i NA con una penalità di prestazione minore, allora diventa interessante per un segmento della comunità delle statistiche, ma i NA impongono anche un lavoro extra considerevole quando si usa il codice compilato con R.

Molti dei pacchetti in R si basano su routine scritte in linguaggi legacy (C, Fortran o C ++). In alcuni casi le routine compilate sono state sviluppate all'esterno di R e successivamente utilizzate come base per i pacchetti di librerie R. In altri le routine sono state inizialmente implementate in R e poi i segmenti critici sono stati tradotti in un linguaggio compilato quando le prestazioni sono risultate carenti. Julia sarà attraente se può essere utilizzata per implementare routine equivalenti. C'è un'opportunità per progettare un supporto di basso livello per le NA in un modo che semplifichi la gestione delle NA rispetto a ciò che abbiamo ora quando usiamo R con codice compilato.

L'enorme numero di librerie R rappresenta gli sforzi di molti molti utenti. Ciò è stato possibile perché R ha fornito funzionalità che non sarebbero state altrimenti disponibili / convenienti. Se Julia deve essere ampiamente utilizzata, ha bisogno di un gruppo di utenti che ritengono che faccia ciò di cui hanno bisogno molto meglio delle alternative che valgono lo sforzo necessario per fornire cose di base (ad es. Grafica, classi di date, NA, ecc. ) disponibile dalle lingue esistenti.

Sarò in anticipo, non ho esperienza con R, ma lavoro con molte persone che pensano che sia uno strumento eccellente per l'analisi statistica. Il mio background è nel data warehousing e, grazie al modello di programmazione Julia facilmente distribuibile, ma più standard, penso che potrebbe essere un sostituto molto interessante per la parte trasformata degli strumenti ETL tradizionali che generalmente svolgono il lavoro molto male, la maggior parte non ha modo di creare facilmente una trasformazione standardizzata o riutilizzare i risultati di una trasformazione già eseguita su un set di dati precedente. Il supporto per tuple ben definite e tipizzate si distingue, se voglio costruire un cubo OLAP che fondamentalmente ha bisogno di costruire tuple più dettagliate (tabelle dei fatti) su tuple già calcolate, gli strumenti ETL di oggi non hanno "blocchi" per parlarne può aiutare, questa industria ha aggirato la questione in vari modi in passato, ma ci sono compromessi. I linguaggi di programmazione tradizionali possono aiutare fornendo trasformazioni definite a livello centrale e Julia potrebbe potenzialmente semplificare le aggregazioni e le distribuzioni non standard comuni nei sistemi di data warehouse più complessi.

Puoi anche usare Julia e R insieme. C'è l' interfaccia Julia-to-R . Con questi pacchetti puoi giocare con Julia mentre chiami R ogni volta che ha una libreria che sarebbe necessaria.

Julia ha senza dubbio tutte le possibilità di diventare una statistica che i sogni degli utenti diventano realtà, prendi ad esempio SAS, il potere sta nei numerosi proc scritti in C - quello che Julia può fare è darti i proc con il codice sorgente, con matrici come un tipo di dati incorporato che distribuisce con SAS / iml. Non ho dubbi che gli statistici affluiranno a Julia una volta che avranno capito cosa può fare questo cucciolo.

Oh sì, Julia supererà R abbastanza rapidamente. E i motivi principali saranno le "macro", il 95% della lingua è implementato in Julia e la sua sintassi parsimoniosa e priva di rumore. Se non hai esperienza con i linguaggi di tipo lisp potresti non capirlo ancora, ma vedrai abbastanza rapidamente come l'interfaccia della formula R diventerà un meccanismo obsoleto e brutto e verrà sostituita da micro linguaggi di modellazione specializzati affini a CL macro ad anello. Anche l'accesso a riferimenti di basso livello di un oggetto è un grande vantaggio. Penso che R non abbia ancora capito che nascondere gli interni all'utente in realtà complica piuttosto che semplifica le cose.

Come la vedo ora (avendo anni di intenso uso di R alle spalle, e appena finito di leggere il manuale di Julia), i principali inconvenienti di Julia rispetto a R non supportano l'eredità strutturale (era intenzionale). Il sistema di tipi di Julia è meno ambizioso di S4; supporta anche la spedizione multipla e l'ereditarietà multipla, ma con una cattura: esiste solo un livello di classi concrete. D'altra parte vedo raramente gerarchie di classi in R più profonde di 3 livelli.

Il tempo lo dirà, ma sarà prima di quanto la maggior parte degli utenti R pensi :)

I primi casi d'uso target di Julia sono problemi numerici. Fondamentalmente, puoi suddividere questi campi di analisi e scienza computazionale in scienza dei dati (data driven) e scienza della simulazione (model driven). Julia si occupa prima dei casi d'uso della scienza della simulazione. Si stanno anche occupando dei casi di data science, ma più lentamente. R non sarà mai molto utile per la scienza della simulazione, ma Julia sarà molto utile per entrambi in un paio d'anni.

Deve essere in grado di applicare qualsiasi funzione a set di dati di grandi dimensioni che non rientrano nella memoria in modo trasparente per l'utente.
Ciò include almeno l'esecuzione di modelli di effetti misti, modelli di sopravvivenza o MCMC su set di dati che si adattano al disco ma non alla memoria. E se possibile su set di dati distribuiti su più computer.