Is it time to move to Julia? - Ideas2IT

Is it time to move to Julia?

Share This

Python is booming in popularity. It is used in DevOps, Data Science, Web Development and Security. Python, however, is one of the slowest languages. In this blog, I’m making a case to switch to Julia.

First things first, why is Python slow?

  • There is a “global interpreter lock (GIL)” that carefully controls thread execution in Python. The interpreter can only execute one operation at a time, regardless of how many threads it has. If you have a single-threaded, single interpreter application, it will make no difference to the speed however. Removing the GIL would have no impact on the performance of your code, in that case.
  • Python doesn’t implement the JIT or Just in Time compilation. JIT enables optimizations to be made at runtime which help JAVA, for example, run faster when it’s repeatedly processing the same thing.

Python is a dynamically typed language. Statically-typed languages are designed that way because of the way the CPU operates. If everything eventually needs to equate to a simple binary operation, you have to convert objects and types down to a low-level data structure. Python does this for you, you just never see it, nor do you need to care. It is hard to optimise a language that is so dynamic. The reason many alternatives to Python are so much faster is that they make compromises to flexibility in the name of performance.

This is where Julia comes in. Its creators set themselves this as a standard,

We want a language that’s open source, with a liberal license. We want the speed of C with the dynamism of Ruby. We want a language that’s homoiconic, with true macros like Lisp, but with obvious, familiar mathematical notation like Matlab. We want something as usable for general programming as Python, as easy for statistics as R, as natural for string processing as Perl, as powerful for linear algebra as Matlab, as good at gluing programs together as the shell. Something that is dirt simple to learn, yet keeps the most serious hackers happy. We want it interactive and we want it compiled.

How does Julia achieve these lofty aims and how does it compare to the restrictions we listed above?

  • Julia is JIT compiled. At its best, Julia can approach or match the speed of C.
  • Dynamically typed by default but can be defined to work as static. Julia’s syntax is similar to Python’s—terse, but also expressive and powerful.  You can specify types for variables, like “unsigned 32-bit integer.” But you can also create hierarchies of types to allow general cases for handling variables of specific types—for instance, to write a
    function that accepts integers generally without specifying the length or signing of the integer. And, finally, you can do without typing entirely if it isn’t needed in a
    particular context.
  • Since the original target audience for Julia was users of scientific computing languages and environments like Matlab, R, Mathematica, and Octave Julia’s syntax for Math operations looks more like the way Math formulas are written outside of the computing world, making it easier for non-programmers to pick up on. This allows Data Scientists to focus on Data Science and not worry about programming too much.

Julia’s disadvantage is that its Libraries aren’t as extensive as Python. However, that is solved since it can interface with Python code by way of the PyCall library, and even share data between Python and Julia. Julia can also interface directly with external libraries written in C and Fortran.

Over time, as we start processing larger and larger data-sets, it’s likely most Data Scientists who now use Python will move to Julia. Perhaps you should, too.