Is the Julia Language Worth Learning? (Pros and Cons)
Julia promises high-performing code and ease of use, but also has a few downsides. Is it worth learning it?
Three things to consider
Introduced in 2012, Julia is still among the newest programming languages out there. As with any new tool, a good question is whether is it worth learning it now or not. Being both fast, interactive, and easy to pick up, there are several use cases that could be considered sweet spots for Julia adoption.
But of course, the answer will depend on your use case and goals.
But let’s first review some basic advice about what any programmer (or anyone who wants to eventually get a job that involves programming) should learn:
- Learn fundamentals of software development and good programming practices.
- If you can choose freely, pick the language in which you can be more productive.
- If you are looking for a job, let the job market inform you about which languages are in higher demand and learn them.
Can you be more productive with Julia?
Julia is fast
Let’s start with the most fundamental fact. Julia is fast. In fact, optimized Julia code can be just as fast as highly optimized C++ or Fortran code. Moreove, this code-optimization process will be much easier to accomplish in Julia, and the resulting program will require a factor of 2X or 3X fewer lines of code.
As a reference, you check out my post where I shared my first impressions after testing Julia and running benchmarks vs Python and Fortran (and later C++ as well), comparing code performance and the language syntax.
So, a first question to ask yourself is: do you need the speed of C? And then, would you want to get it at a lower cost than with a low-level programming language? Then, Julia might be a good choice for you.
But, what happens if you are working in an area where code performance is not so important? Is Python together with some (limited) and easy optimization add-ons like Numba good enough for your use case? Can you tolerate a hard-to-estimate slowdown factor? If this is the case, then sticking with Python and leveraging it’s much larger ecosystem of existing libraries is a wise choice.
(note: Numba-optimized Python will never be as fast as Julia, you can read my post about that). As discussed in that post, the slowdown factor can be hard to estimate, as it depends on the complexity of a given project. In a few words, you should expect Python to be slow.
Julia is easier and cleaner than C++
When compared with a low level language, a Julia program will requires substantially fewer lines of code to perform a given task. Sometimes, an entire Julia project’s code will be shorter than the code required to build a C++ project (the CMakeLists.txt file).
Not only Julia will require fewer lines of code, thanks to the interactive nature of the language, development will usually be much faster than in low-level languages.
Additionally, Julia’s syntax is also much easier to read, and therefore to maintain and to onboard collaborators to. For example, an important technique that goes by the name of generic programming is almost the default behavior of Julia, while achieving it in C++ results in undecipherable code very few people will understand, let alone be able to contribute to.
You can avoid the two-language problem
Of course, you can achieve a combination of writing fast code in C++, and interact with it in Python, for example.
This can be beneficial, but it is indeed quite challenging: you need to be proficient not in one language, but in two, and understand their interaction. Attempting this can be risky as well: as soon as you start making a few non-obvious design mistakes, you can end up with code that is slow as Python and hard to manage like C++.
This is the issue that Julia set out to solve in the first place: the so-called two-language problem of scientific computing. And it certainly has, to a great extent. With Julia, you can write easily-understood code that is also orders of magnitude faster than that of similarly high-level interactive languages.
If you are in a position where you want both performance and productivity, then you are in the sweet spot to become a Julia user. That is, if you don’t mind dealing with the present limitations of Julia.
What are the main limitations of Julia?
Julia is far from being perfect, and at present it has some rather non-trivial limitations. Sometimes, these limitations will be deal-breakers, but in many cases they represent reasonable trade-offs. Let’s see.
Younger ecosystem than Python or R
Let’s begin with an obvious statement: Julia’s ecosystem is still in its early stages in many areas, specially when compared with Python or R, which have an ecosystem that has been evolving for more than 20 years.
While Julia compensates for that by being able to call external programs, this situation is far from ideal, and some libraries are a little rough around the edges and just need time to improve, or lack certain functionality.
On the other hand, when comparing Julia’s ecosystem with that of low-level languages like C++ or Fortran, where package managers are far from being a well established practice, and developers still have to rely on copy-pasting code or trying to link to external libraries (which is usually very time-consuming), actually Julia gets the upper hand.
Compilation latency issues
Even though a lot of effort has been put into improving Julia’s JIT compiler, many packages still have a noticeable lag when attempting to run code for the first time. For example, importing a well-established plotting library and making a simple plot can take around 8 seconds. For some other packages, compile times can be much longer as well.
If we compare this with Python, this of course can be annoying. So quick scripting may not be the best use case for Julia. On the other hand, if you are anyway going to run a 10-minute simulation, waiting 8 seconds when you start your sessions won’t move the needle.
To be fair, we should also compare Julia’s compile times with that of other low-level languages such as C++.
As any experienced C++ developer knows, compiling a complex C++ project can mean that after you start compiling, you go get yourself some coffee. While one of the latest features in C++20 (modules) aims to improve compile times, it is not yet fully supported by most compilers and build systems.
So again, we have a trade-off here, where Julia is not as straightforward to use as other high-level languages, but still preferable to low-level languages.
Poor support for static compilation
So far we have been considering limitations of Julia when compared with other high-level languages, where nevertheless, Julia was still preferable to low-level languages.
So what is the trade-off between Julia and low-level languages? Well, the answer boils down to static compilation of small binaries and libraries, something for which Julia has poor support.
While this might seem like small potatoes at first (who cares if the size of a binary file is 450Kb or 150Mb, anyway?), this is only the tip of the iceberg. The problem is that the lack of static compilation implies that interoperability with other languages will be poor.
Actually, the interoperability only goes one way: it is very easy to call other languages from Julia, but the other way around is really challenging, to the point of almost being unfeasible. (see for example this post by Matthijs Cox, about how difficult it is right now to embed Julia in C++, where the author advices to avoid embedding if you can).
So if you want to write a universally-used library, or if you want to embed Julia on a desktop application, or within an app that runs in the browser, or in a low-memory device, then Julia is not a good choice… at least, not right now.
For the most part, Julia code has to be run within Julia. This means that you can write code for yourself or for other Julia users. On the positive side, the Julia community is fantastic, and the ecosystem is developing at a good pace. Importantly, this doesn’t mean that you can’t develop standalone applications with Julia: you can, but these applications will have to be based around Julia.
This being said, it’s not that there is no hope for static compilation. Actually, I’m very enthusiastic about progress being made in StaticCompiler.jl, which is however at a very early stage. As StaticCompiler.jl seems to be closely related to how Julia is used on GPUs, which is another major use-case for Julia, I would expect to see continued progress in this area.
Whenever static compilation becomes possible, improved Python and R integration should also lead to a substantial (and potentially huge) growth for Julia, as the user-base for Julia packages could grow enormously.
Will learning Julia help you get a job?
So, if you are looking for a job, and in the present stage of your career you are simply letting the job market inform you about what is in high demand, is totally comprehensible that learning Julia won’t be among your top priorities.
However, it is worth noting that there is a non-trivial amount of jobs that are beginning to mention Julia as a desirable skill: a simple job search should confirm that, at least for some geographies like the US.
It is also pretty clear that potential employers will have a favorable view on people who know Julia (or any other interesting and emerging language), as knowing more than just a few languages can help you highlight the fact that you are well-versed in computer programming.
Is learning Julia a good educational experience?
Regardless of the other points, I believe learning Julia is a great educational experience. If you become familiar with Julia, the language and ecosystem will naturally and easily expose you to great fundamental concepts and good programming practices:
- As Julia can be as fast as low-level languages if you get things right, that means that you can learn low-level optimization methods with Julia.
- Julia also has amazing high-level features like generic programming (via multiple-dispatch) and code generation (via macros), so learning the language will expose you to those concepts.
- Additionally, Julia has great tooling, so the ecosystem will expose you to very good programming practices like integrated testing and automatic documentation generation.
I believe you just can’t learn some of these things in Python, and on the other hand, learning them really well in C++ could definitively take you years, compared to months in Julia.
I believe investing time in learning Julia has a great payoff nonetheless because of the fundamentals and good practices you will get exposed to.
What will be the future of Julia?
My expectations about Julia are that it should absolutely take universities by storm, as it is a fantastic language for both research and education. We will see where the ecosystem develops from there in a few years.
Also, none of the weak points I mentioned are fundamental limitations, and it should be possible to address them over time.
As for industry adoption, I believe the language could be following a path similar to that of Matlab. For a long time, Matlab was regarded as a language only for academic use, and eventually became widely accepted for every-day tasks in engineering companies.
It could be only a matter of time before Julia adoption takes off in the same kind of companies that have adopted Matlab as well, as more and more young graduates with experience in the language start joining the industry and find use cases for Julia. These young people will eventually become managers, who can then influence job postings for their team members.
So, should you learn Julia? I hope that with the guideline I provided in this post your answer is yes, at least for the sake of a great learning experience, that shall put you in a road of becoming an excellent software developer.
Does this mean that you should become 100% committed to Julia? Absolutely not, as many of the current limitations can perhaps prevent you from doing all of your programming in the language
If you want to learn Julia, you can start with my tutorial, which focuses on users with a background in science and engineering:
Julia Programming: An Effective Tutorial
A final quote by Kent Beck, an influential software engineer, for inspiration:
“Make it work, make it right, make it fast.”