# Does Julia have any hope of sticking in the statistical community?

I recently read a post from R-Bloggers, that linked to this blog post from John Myles White about a new language called Julia. Julia takes advantage of a just-in-time compiler that gives it wicked fast run times and puts it on the same order of magnitude of speed as C/C++ (the same order, not equally fast). Furthermore, it uses the orthodox looping mechanisms that those of us who started programming on traditional languages are familiar with, instead of R's apply statements and vector operations.

R is not going away by any means, even with such awesome timings from Julia. It has extensive support in industry, and numerous wonderful packages to do just about anything.

My interests are Bayesian in nature, where vectorizing is often not possible. Certainly serial tasks must be done using loops and involve heavy computation at each iteration. R can be very slow at these serial looping tasks, and C/++ is not a walk in the park to write. Julia seems like a great alternative to writing in C/++, but it's in its infancy, and lacks a lot of the functionality I love about R. It would only make sense to learn Julia as a computational statistics workbench if it garners enough support from the statistics community and people start writing useful packages for it.

My questions follow:

1. What features does Julia need to have in order to have the allure that made R the de facto language of statistics?

2. What are the advantages and disadvantages of learning Julia to do computationally-heavy tasks, versus learning a low-level language like C/++?

-
How is Julia better than Incanter (incanter.org) and other similar projects? –  Wayne Apr 2 '12 at 14:39
Re procedural constructs (e.g. looping): that sounds like a giant step backwards. We are at the cusp of a change from single and small-CPU platforms to massively parallel platforms. As this evolution occurs over the next decade or so, the easily and automatically parallelizable functional style of coding will reap huge advantages over procedural code. Many other considerations intervene in one's choice of a statistical platform, of course, but this one is worth bearing in mind as a long term strategy. –  whuber Apr 3 '12 at 16:14
Christopher, a good approach is to frame questions in a manner designed to solicit reasons and evidence. E.g., instead of "Does Julia have the necessary allure...," try something like "What elements of Julia might give it a chance of gaining traction and why"; instead of "Is it worth learning," ask "Why might Julia be worth learning now? What are its potential advantages?" You could further refine that question by specifying what kinds of uses of Julia you may be interested in, such as software development, solving one-off problems, biostatistics, data mining, etc. –  whuber Apr 3 '12 at 18:41
@Whuber: I appreciate the suggestions and have implemented them. Thank you! –  Christopher Aden Apr 3 '12 at 19:02
Christopher, well done! (And +1 for the question.) And now I think @naught could make a good case for this not to be CW, but I still agree with chl that multiple good answers are likely to emerge--that has become abundantly obvious--and so prefer to maintain the CW status of this thread. –  whuber Apr 3 '12 at 19:16

I think the key will be whether or not libraries start being developed for Julia. It's all well and good to see toy examples (even if they are complicated toys) showing that Julia blows R out of the water at tasks R is bad at.

But poorly done loops and hand coded algorithms are not why many of the people I know who use R use R. They use it because for nearly any statistical task under the sun, someone has written R code for it. R is both a programming language and a statistics package - at present Julia is only the former.

I think its possible to get there, but there are much more established languages (Python) that still struggle with being usable statistical toolkits.

-
Have you actually looked at the benchmark code (or the benchmarks) to know that the R methods are poorly written? I am trying to find it myself to see how the various languages were used... –  Josh Hemann Apr 4 '12 at 14:01
@JoshHemann I've looked at enough to know that across the board R is "slow-ish". It doesn't necessarily lose every time, and it does on occasion blow Python out of the water, but in all of those cases the "who wins" ribbon seems to go to which Python or R programmer actually wrote most of their stuff in C. –  Fomite Apr 4 '12 at 17:02
The benchmark code is terrible. 2000x speed gains are possible for their R examples. See stackoverflow.com/questions/9968578/… , especially the comments. –  Ari B. Friedman May 15 '12 at 13:44
You're right, @gsk. E.g., pisum (at github.com/JuliaLang/julia/blob/master/test/perf/perf.R) takes 7.76 seconds while a simple rewrite using idiomatic R (replicate(500, sum((1 / (10000:1))^2))[500]) takes 0.137 seconds, more than a fifty-fold speedup. –  whuber May 15 '12 at 14:21
@whuber Exactly. And compiling probably buys you another "x" or two. –  Ari B. Friedman May 15 '12 at 17:52

I agree with a lot of the other comments. "Hope"? Sure. I think Julia has learned a lot from what R and Python/NumPy/Pandas and other systems have done right and wrong over the years. If I were smarter than I am, and wanted to write a new programming language that would be the substrate for a statistical development environment in the future, it would look very much like Julia.

This said, it'll be 5 years before this question could possibly be answered in hindsight. As of right now, Julia lacks the following critical aspects of a statistical programming system that could compete with R for day-to-day users:

(list updated over time...)

• optionally-ordered factor types
• most statistical tests and statistical models
• literate programming/reproduce-able analysis support
• R-class, or even Matlab-class plotting

To compete with R, Julia and add-on stats packages will need to be clean enough and complete enough that smart non-programmers, say grad students in the social sciences, could reasonably use it. There's a heck of a lot of work to get there. Maybe it'll happen, maybe it'll fizzle, maybe something else (R 3.0?) will supercede it.

## Update:

Julia now supports DataFrames with missing data/NAs, modules/namespaces, formula types and model.matrix infrastructure, plotting (sorta), database support (but not to DataFrames yet), and passing arguments by keywords. There is also now an IDE (Julia Studio), Windows support, some statistical tests, and some date/time support.

-
+! For windows support. –  Owe Jessen Apr 3 '12 at 19:49
literate programming/reproduce-able analysis support -> see IJulia. –  Piotr Migdal Jan 27 at 22:32
Add iJulia kernel for the iPython/Jupyter notebook ecosystem. –  thecity2 May 15 at 20:07
Julia Studio is being phased out, and Juno is now the IDE –  Antony Jun 29 at 12:47

I can sign under what Dirk and EpiGrad said; yet there is one more thing that makes R an unique lang in its niche -- data-oriented type system.

R's was especially designed for handling data, that's why it is vector-centered and has stuff like data.frames, factors, NAs and attributes.
Julia's types are on the other hand numerical-performance-oriented, thus we have scalars, well defined storage modes, unions and structs.

This may look benign, but everyone that has ever try to do stats with MATLAB knows that it really hurts.

So, at least for me, Julia can't offer anything which I cannot fix with a few-line C chunk and kills a lot of really useful expressiveness.

-
(+1) Good point. Some further thoughts: The lack of data.frame-like facilities in Python has long bothered me, but now Pandas seems to have resolve this issue. Formula are among some of the planned extensions of statsmodels (well, we know that sometimes it's better to avoid the formula interface in R). There's a data.frame proposal for Julia (pretty quick compared to Python!), (...) –  chl Apr 2 '12 at 16:55
I think @mbq also has a point about C. If I need speed on the same order of magnitude as C/C++...I can use C/C++ with R. –  Fomite Apr 2 '12 at 19:14
@EpiGrad, yes, you can write C/C++ and interface cleanly with R. But that's a weakness, not a strength of the language. With Julia, end users will never need to write C to get speed. –  Harlan Apr 3 '12 at 14:07
@Harlan It's only a weakness if you already know both Julia and C. I'd assert time spent in C < time spent learning a new language and reimplementing everything from scratch. –  Fomite Apr 3 '12 at 16:52
@Harlan And to be blunt, those people aren't going to be rewriting their stuff in Julia. R as a statistics package, not a programming language is their use case. –  Fomite Apr 3 '12 at 17:22

For me, one very important thing for a data analysis language is to have query/relational algebra functionality with reasonable defaults and interactively-oriented design, and ideally this should be a built-in of the language. IMO, no FOSS language that I've used does this effectively, not even R.

data.frame is very clunky to work with interactively - for example, it prints the whole data structure on invocation, the \$syntax is hard to work programatically with, querying requires redundant self reference (i.e., DF[DF$x < 10]), joins and aggregation are awkward. Data.table solves most of these annoyances, but as it is not part of the core implementation, most R code does not make use of its facilities.

Pandas in python suffers from the same faults.

These gripes may seem nitpicky, but these faults accumulate and in the end are significant in aggregate as they end up costing a lot of time.

I believe if Julia is to succeed as a data analysis environment, effort must be devoted to implementing SQL type operators (without the baggage of SQL syntax) on a user friendly table data type.

-
+1--An interesting point, thoughtfully explained. Welcome to our community! –  whuber Jun 6 '12 at 13:03
Thank you, it's good to be here. –  Yike Lu Jun 6 '12 at 19:42
To be nit-picky, large Pandas DataFrames actually don't print out all of their contents when invoked, as happens in R. They switch to displaying column headers along with a count of null/non-null values. Also, while I agree the syntax isn't ideal, scoping issues make it hard to eliminate the self-reference for comprehension-style filtering. It is wordier, but it's also resistant to namespace collisions if a DataFrame has extra columns at runtime you didn't expect. –  goodside Oct 13 '12 at 17:57

The Julia language is pretty new; it's time in the spot light can be measured in weeks (even though its development time can of course be measured in years). Now those weeks in the spot light were very exciting weeks---see for example the recent talk at Stanford where "it had just started"---but what you ask for in terms of broader infrastructure and package support will take much longer to materialize.

So I'd keep using R, and be mindful of the developing alternatives. Last year a lot of people went gaga over Clojure; this year Julia is the reigning new flavour. We'll see if it sticks.

-
Thank you for the insight. I figured it might be a little early to tell on Julia. You're probably a bit biased, but do you see RCpp as a valid alternative in the interim, or is there too much programming knowledge needed to make it worth the hassle? –  Christopher Aden Apr 2 '12 at 0:19
Because of what I have seen via Rcpp, I am even more impressed by Julia---about 50, 60, 70 fold increases for simple looping as in MCMC, and several hundred fold for "degenerate" examples like fibonacci are essentially the same as Rcpp got! But I also know that with Rcpp I still get access to the 3700 CRAN packages---as well as countless C++ libraries---whereas Julia right now has almost nothing. That said, the promise of Julia is huge. But maybe there is a "then" as well as a "now". Time will tell. –  Dirk Eddelbuettel Apr 2 '12 at 0:25
And don't forget Incanter, which is supposed to become a statistical environment based on Clojure. How is Julia superior to that? –  Wayne Apr 3 '12 at 15:35
@Wayne, let's not muddy the waters here. Open a new question for that (perhaps one that asks for comparison between multiple languages) –  naught101 Apr 3 '12 at 22:01
@naught011: I'm simply echoing Dirk's point that Clojure was flavor of the month, then specifically Incanter, now Julia. I don't think that Julia or Incanter (or Clojure) stand a chance of being generalized statistical platforms. –  Wayne Apr 4 '12 at 0:40

I can see Julia replacing Matlab, which would be a huge service for humanity.

To replace R, you'd need to consider all of the things that Neil G, Harlan, and others have mentioned, plus one big factor that I don't believe has been addressed: easy installation of the application and its libraries.

Right now, you can download a binary of R for Mac, Windows, or Linux. It works out of the box with a large selection of statistical methods. If you want to download a package, it's a simple command or mouse click. It just works.

I went to download Julia and it's not simple. Even if you download the binary, you have to have gfortran installed in order to get the proper libraries. I downloaded the source and tried to make and it failed with no really useful message. I have an undergraduate and a graduate degree in computer science, so I could poke around and get it to work if I was so inclined. (I'm not.) Will Joe Statistician do that?

R not only has a huge selection of packages, it has a fairly sophisticated system that makes binaries of the application and almost all packages, automatically. If, for some reason, you need to compile a package from source, that's not really any more difficult (as long as you have an appropriate compiler, etc, installed on your system). You can't ignore this infrastructure, do everything via github, and expect wide adoption.

EDIT: I wanted to fool around with Julia -- it looks exciting. Two problems:

1) When I tried installing additional packages (forget what they're called in Julia), it failed with obscure errors. Evidently my Mac doesn't have a make-like tool that they expected. Not only does it fail, but it leaves stuff lying around that I have to manually delete or other installs will fail.

2) They force certain spacing in a line of code. I don't have the details in front of me, but it has to do with macros and not having a space between the macro and the parenthesis opening its arguments. That kind of restriction really bugs me, since I've developed my code formatting over many years and languages and I do actually put a space between a function/macro name and the opening parenthesis. Some code formatting restrictions I understand, but whitespace within a line?

-
Julia's still VERY much in its infancy. I'm no historian, but I'd bet that clean binaries of R didn't come out in the first few months, either. Your point about the distribution system is something I haven't seen mentioned much thus far. Then again, I would also wager that CRAN did not sprout up the same time as R. A "CJAN" would definitely be nice for large-scale adoption. –  Christopher Aden Apr 3 '12 at 18:57
You might be interested then to know, @Christopher, that R is really an independently developed clone of a package (S, then S-Plus) that had been a (mild) commercial success and was under development ten years previously. That gave it a significant head start that Julia (and most other such efforts) never have. –  whuber Apr 3 '12 at 19:19
@ChristopherAden: I agree that Julia is yet young. But I would strenuously disagree that "a 'CJAN' would definitely be nice for large-scale adoption": it's an absolute necessity. The only tools I can think of that don't have a CRAN-like infrastructure are highly specialized -- like JAGS. But Julia, like R, is general purpose. –  Wayne Apr 4 '12 at 0:46
The day Open Source Language will replace MATLAB will be the best day to the engineering world. –  Drazick Aug 2 '13 at 13:07
"I can see Julia replacing Matlab, which would be a huge service for humanity." I couldn't agree more. –  davidav Oct 3 '13 at 11:16

Every time I see a new language, I ask myself why an existing language can't be improved instead.

• a rich set of modules (not just statistics, but plotting libraries, output to pdf, etc.)
• language constructs that you end up needing in the long run (objected-oriented constructs you need in a big project; decorators, closures, etc. that simplify development)
• many tutorials and a large support community
• access to mapreduce, if you have a lot of data to process and don't mind paying a few pennies to run it on a cluster.

In order to overtake R, Julia, etc., Python could use

• development of just-in-time compilation for restricted Python to give you more speed on a single machine (but mapreduce is still better if you can stand the latency)
• a richer statistical library
-
This may be true, but for a very-casual user, Python's language design may be a little harder to use than something like Matlab, or Julia, which has an even more math-like syntax. You can say y = 3x+2 in Julia and it works! –  Harlan Apr 3 '12 at 16:20
That's funny: when I first saw Python some 10+ years ago I had exactly the same reaction (why is this needed? Why not just improve what's out there already? Why learn a whole new set of bizarre syntactic quirks, names of classes, methods, and procedures, and all the rest?). :-) –  whuber Apr 3 '12 at 16:43
@NeilG Not professional statisticians so much as non-programmer researchers in especially the sciences. Python's great for programmers, but if all you want to do is load your psychology data and fit some models (quickly), a very simple math-like syntax might be preferable to Python's elegant object-based design. –  Harlan Apr 3 '12 at 17:05
@NeilG Keep in mind part of the success of R is that it's not just used by statisticians. It's used by people who do statistics. And social scientists, clinicians and first-year science graduate students are absolutely very casual users. –  Fomite Apr 4 '12 at 17:07
I think (CrossValidated member) John D Cook's blog post is spot on: I'd much rather program math in a general purpose language than try to code math and systems problems in a math language. If the Julia community can keep this in mind, there is a good chance the language will stick for analytic programming in general (stats being only one part of that). See johndcook.com/blog/2012/04/02/why-scipy –  Josh Hemann Apr 6 '12 at 4:35

Bruce Tate here, author of Seven Languages in Seven Weeks. Here are a few thoughts. I am working on Julia for the followup book. The following is just my opinion after a few weeks of play.

There are two fundamental forces at play. First, all languages have a lifespan. R will be replaced some day. We don't know when. New languages have an extremely difficult time evolving. When a new language does evolve, it usually solves some overwhelming pain point.

These two things are related. To me, we're starting to see a theme taking shape around languages like R. It's not fast enough, and it's harder than it needs to be. Those who can live within a certain performance envelope and stay within established libraries are fine. Those who can't need more, and they're starting to look for more.

The thing is, computer architectures are changing, and to take advantage of them, the language and its constructs need to be constructed in a certain way. Julia's take on concurrency is interesting. It optimizes the right thing for such a language: transparent distribution and the efficient movement of data between processes. When I use Julia for typical tasks, maps and transforms and the like, I am just calling functions. I don't have to worry about the plumbing.

To me, the fact that Julia is faster on one processor is interesting, but not overly damning for R. The thing that is interesting to me is that as processors depend more and more on multicore for performance, technical computing problems are just about ideally positioned to take the best possible advantage, given the right language.

The other feature that will help that happen is indeed macros. The pace of the language is just intense right now. Macros let you build with bigger, cleaner building blocks. Looking at libraries is interesting but doesn't tell the whole picture. You need to look at the growth of libraries. Julia's trajectory is pretty much spot on here.

Clojure is interesting to some because there's no technical language that does what R can, so some look to a general purpose language to fill that void. I am actually a huge fan. But Clojure is a pretty serious brain warp. Clojure will be there for programmers who need to do technical computing. It won't be for engineers and scientists. There's just too much to learn.

So to me, Julia or something like it will absolutely replace R some day. It's a matter of time.

-

I think it's unlikely that Julia will ever replace R, for a lot of the reasons previously mentioned. Julia is a Matlab replacement, not a R replacement; they have different goals. Even after Julia has a fully-fleshed out statistics library, no one would ever teach an Intro to Statistics class in it.

However, an area in which it could be incredible is as a speed-optimized programming language that's less painful than C/C++. If it were seamlessly linked to R (in the style of Rcpp), then it would see a ton of use in writing speed-critical segments of code. Unfortunately no such link exists currently:

-
But now there is one: comments.gmane.org/gmane.comp.lang.julia.devel/15153 did'nt try it (yet). –  kjetil b halvorsen Jun 22 '14 at 14:34

The following probably does not deserve to be an answer, but it is too important to be buried as a comment to someone else's response...

I have not heard much said about memory consumption, just speed. R's entire semantics being pass-by-value can be painful, and this has been one criticism of the language (which is a separate issue from how many great packages already exist). Good memory management is important, as is having ways of dealing with out-of-core processing (e.g. numpy's memory mapped arrays or pytables, or Revolution Analytics' xdf format). While PyPy's JIT compiler allows for some striking Python benchmarks, memory consumption can be quite high. So, does anyone have experience with Julia and memory usage yet? Sounds like there are memory leaks on the Windows "alpha" version that will no doubt be addressed, and I am still waiting on access to a Linux box to play with the language myself.

-
True, but there are ways to use pass-by-reference in R (Reference Classes, for one). –  Ari B. Friedman May 15 '12 at 13:46
And R isn't really strictly pass-by-value. Lazy evaluation and some clever optimization means that often data isn't copied unless it has to be. –  Ari B. Friedman May 7 '13 at 18:42

I am interested by the promise of better speed and easy parallelisation using different architectures. For that reason I will certainly watch Julia development but I am unlikely to use it until it can handle generalised linear mixed models, the has a good generic bootstrap package, a simple model language for building design matrices the capability equivalent to ggplot2 and a wide range from machine learning algorithms.

No statistician can afford to have a fundamentalist attitude to the choice of tools. We will use whatever enables us to get the job done most efficiently. My guess is I will be sticking with R for a few years yet, but but it would be nice to be pleasantly surprised.

-
Hi Mervyn, and welcome to Stats.SE! Julia has made some substantial improvements in the time since I created this post (almost a year ago!). Douglas Bates ported some of his GLM (maybe GLMM?) code to Julia dmbates.blogspot.com/2012/04/r-programmer-looks-at-julia.html), and the main Github page has seen many updates in the past year. My take on Julia thus far (I've used it on and off since last year) has been that's a nice tool for speed, which I use for some crude MCMC, but it hasn't replaced R in my toolchain yet. Can't wait for either R to get faster, or Julia to be more widespread! –  Christopher Aden Apr 15 '13 at 22:05
Doug hasn't ported GLMMs yet. If someone wants to help with that I'm sure he would be happy ... –  Ben Bolker Jan 25 '14 at 17:24

The luxury of NA's in R does not come without performance penalties. If Julia supports NA's with a smaller performance penalty then it becomes interesting to a segment of the stats community, but NA's also impose considerable extra work when using compiled code with R.

Many of the packages in R rely on routines written in legacy languages (C, Fortran, or C++). In some cases the compiled routines were developed outside R and later used as the basis for R library packages. In others the routines were first implemented in R and then critical segments translated to a compiled language when performance was found lacking. Julia will be attractive if it can be used to implement equivalent routines There is an opportunity to design low-level support for NA's in a way that simplifies NA handling over what we have now when using R with compiled code.

The massive number of R libraries represents the efforts of many many users. This was possible because R provided capabilities that weren't otherwise available/affordable. If Julia is to become widely used, it needs a group of users who find it does what they need so much better than the alternatives that is worth the effort needed to supply very basic things (e.g., graphics, date classes, NA's, etc.) available from existing languages.

-

I will be up front, I have no experience with R, but I work with plenty of people that think it is an excellent tool for statistical analysis. My background is in data warehousing, and due to Julia's easily distributed, but more standard programming model, I think it could be a very interesting substitute for the transform portion of traditional ETL tools that generally do the job very poorly , most have no way of easily creating a standardized transform, or re-using the results of a transform already performed on a prior data-set. The support for tightly defined and typed tuples stands out, if I want to build an OLAP cube that basically needs to build more detailed tuples (fact tables) out of tuples already calculated, today's ETL tools have no 'building blocks' to speak of that can help, this industry has worked around this issue through various means in the past, but there are trade-offs. Traditional programming languages can help by providing centrally defined transformations, and Julia could potentially simplify the non-standard aggregations and distributions common in more complex data warehouse systems.

-

Julia has without doubt every chance of becoming a statistics power-users dream come true, take SAS for example, it's power lies in the numerous procs written in C - what Julia can do is give you the procs with the source code, with matrices as a built in data type dispensing with SAS/iml. I have no doubt that statisticians will flock to Julia once they get a handle on just what this puppy can do.

-
Welcome to Stats.SE, Jimbo. I disagree with your assertion. I think we've seen what Julia is able to do, but the problem at this point is that there aren't nearly as many domain-specific packages for it as there are in R. R will continue to reign supreme in open source statistics as long as researchers see more benefit to using the numerous packages in the R universe. That's my take, at least. –  Christopher Aden May 6 '13 at 16:07

You can also use Julia and R together. There is Julia-to-R interface. With this packages you can play with Julia while calling R whenever it has a library that would be needed.

-

Oh yes, Julia will overtake R quite quickly. And the primary reasons will be "macros", 95% of the language is implemented in Julia, and its noise free, parsimonious syntax. If you don't have experience with lisp type of languages you might not understand it as yet, but you will see pretty quickly how R formula interface will became an obsolete and ugly mechanism, and will be replaced by specialized modeling micro languages akin to CL loop macro. Access to low level references of an object is also a big plus. I think R still didn't get that hiding internals from the user actually complicates than simplifies the things.

As I see it now (having years of heavy use of R behind, and just finished reading Julia manual), Julia's main drawbacks with respect to R is no support for structural inheritance (this was intentional). Julia's type system is less ambitious than S4; it also supports multiple dispatch and multiple inheritance, but with a catch - there is only one level of concrete classes. On the other hand I rarely see class hierarchies in R deeper than 3 levels.

Time will tell, but it will be sooner than most R users think:)

-
You make a good point about macros: decades later people still underestimate how powerful Lisp really is. However, as you imply in point #1, this language is essentially a Matlab replacement, not an R replacement. I think you also ignore the fact that it is language plus libraries (packages) that people use and Julia doesn't even have 1% of what it needs there. –  Wayne Apr 6 '12 at 14:32
@Wayne, I don't ignore anything, the OP was about the future and not about what is now. In 5 years, we might see many more libraries for stats in Julia than there are now for R. And this, just because Julia has a good chance to be a much better language. –  VitoshKa Apr 12 '12 at 18:44
If julia really becomes a MATLAB replacement, then it will have huge benefits to use the same language for engineering and statistics! The overlapping areas (such as time series) are huge. –  kjetil b halvorsen Jun 22 '14 at 14:44