The rapid adoption of Julia, the open source, high level programing language with roots at MIT, shows no sign of slowing according to data from Julialang.org. In 2020, the number of downloads jumped 87 percent to more than 24 million (2020 v. 2019) and the number of available packages rose 73 percent to roughly 4800. Last year (2019 v. 2018) the number of downloads jumped 77 percent. In the most recent TIOBE index, Julia jumped from #47 to #23 and TIOBE CEO Paul Jansen said Julia is the top candidate to jump into the top 20 (used languages) next year.
Julia is hot.
One prominent Julia user, Rick Stevens, associate director of Argonne National Laboratory, told HPCwire, I saw the 87 percent increase and think it is wonderful to see Julia growing. I think that Julia has great potential to replace C/C++/Python (and of course Fortran) in scientific and technical computing as it matures. The low level performance is excellent. It will be important for it to be adopted as a first-class target language by CPU/GPU vendors.
Launched roughly in the 2012 timeframe by four computer scientists including Alan Edelman of MIT, the number of Julia users has more than doubled in the past three years. Julia was intended to provide a powerful but easier-to-use programming language for scientific computing. Julia is a dynamic language and the tension between the high performance delivered by so-called static programming languages and the lesser performance delivered by high-level dynamic programming languages, which emphasize abstraction, speed of development, and portability, hasnt gone away.
Edelman, who won the 2019 IEEE Sidney Fernbach Award, in part for his work on Julia, argued in his SC19 Fernbach talk that convenience with sufficient performance is winning out in the programming wars. Moreover, the rise of heterogeneous computing and the complications it presents to programmers, he said, has increased the tilt away from static programming towards dynamic languages. Heres a brief snippet from his SC2019 talk:
When youre writing various algorithms, you dont necessarily want to think about whether youre on a GPU, or whether youre on a distributed computer. You dont necessarily want to think about how youve implemented the specific data structure. What you want to do is talk about what you want to compute, not how you want to compute it, right? That is the big problem, to get people to talk about what you want to compute, and not how you want to compute it. Because if you put in your software, how youre going to compute it, and if your software is filled with that muck, I promise you, nobodys ever going to change it. No ones going to innovate on it. When the person who wrote it is no longer in the project, no ones ever going to touch it.
[S]ome of the reasons why Julia is working very well is because we have particularly well-designed abstractions. We have something called multiple dispatch and we have a very careful balance between the static and dynamic. It interfaces with LLVM. It plays nicely with Python. We also have had lots of people take legacy codes in MPI, and plug them into Julia you dont get all the benefits, but what you do have, which might be the most important benefit, is other people can now run your code once its inside of Julia. So its much easier for other people. You can actually give your old code new life when you plug it into a higher level language.
During his talk, Edelman presented an example in which a group of researchers decided to scrap their legacy climate code in Fortran and write it from scratch in Julia. There was some discussion around performance tradeoffs they might encounter in the move to a high level programming language. The group was willing to accept a 3x slowdown for the flexibility of the language. Instead, said Edelman, the switch produced 3x speedup. (See HPCwire coverage of Edelmans talk, Julia Programmings Dramatic Rise in HPC and Elsewhere)
The Julia organization hasnt been shy about tackling the perceived performance shortcomings of dynamic versus static languages. Heres an excerpt from Julias introductory documentation on performance and differentiation from other dynamic languages:
Scientific computing has traditionally required the highest performance, yet domain experts have largely moved to slower dynamic languages for daily work. We believe there are many good reasons to prefer dynamic languages for these applications, and we do not expect their use to diminish. Fortunately, modern language design and compiler techniques make it possible to mostly eliminate the performance trade-off and provide a single environment productive enough for prototyping and efficient enough for deploying performance-intensive applications. The Julia programming language fills this role: it is a flexible dynamic language, appropriate for scientific and numerical computing, with performance comparable to traditional statically-typed languages.
Because Julia’s compiler is different from the interpreters used for languages like Python or R, you may find that Julia’s performance is unintuitive at first. If you find that something is slow, we highly recommend reading through the Performance Tips section before trying anything else. Once you understand how Julia works, it’s easy to write code that’s nearly as fast as C.
Julia features optional typing, multiple dispatch, and good performance, achieved using type inference and just-in-time (JIT) compilation, implemented using LLVM. It is multi-paradigm, combining features of imperative, functional, and object-oriented programming. Julia provides ease and expressiveness for high-level numerical computing, in the same way as languages such as R, MATLAB, and Python, but also supports general programming. To achieve this, Julia builds upon the lineage of mathematical programming languages, but also borrows much from popular dynamic languages, including Lisp, Perl, Python, Lua, and Ruby.
The most significant departures of Julia from typical dynamic languages are:
- The core language imposes very little; Julia Base and the standard library are written in Julia itself, including primitive operations like integer arithmetic
- A rich language of types for constructing and describing objects, that can also optionally be used to make type declarations
- The ability to define function behavior across many combinations of argument types via multiple dispatch
- Automatic generation of efficient, specialized code for different argument types
- Good performance, approaching that of statically-compiled languages like C
A Julia user survey conducted last June provides a snapshot of the Julia user community and many of its feature preference and practices. Its based on 2,565 interviews. Currently most users (60%) work in academia but there is a growing push to expand Julia in industry. Within industry, the biggest user segments are software/IT professionals (12%) and engineering (11%).
Interestingly, only about half of the Julia currently use hardware accelerators now, although that number is growing. Julia is also not widely used in the cloud. Currently Julia programs are run mostly on local clusters.
Performance, ease-of-use, and the open source nature of Julia were top choices for popular technical features. No surprise, the lack of licensing fees was the top non-tech feature. Among top technical challenges cited were slow compile times and the relative immaturity of packages. Juno and VS Code with Julia plug-in were top rates editors for 2020.
At JuliaCon held (virtually) in late July, one particularly active BOF tackled efforts to have industry share code with the Julia community. Greater involvement of industry seems generally seems to be on Julias agenda and represents another step towards building its popularity. Theres a recap of JuliaCon posted on the Julia website.
It will be interesting to monitor Julia’s traction going forward; making it into the top 20 of the TIOBE Index next year would be a strong indicator.
Slides source: Julia June 2020 survey: https://julialang.org/assets/2020-julia-user-developer-survey.pdf
2020 stats source: Julia newsletter, https://juliacomputing.com/blog/2021/01/newsletter-january/