Things to know before using Julia for Machine-Learning | by Emmett Boudreau | Towards Data Science

Julia is a high-level dynamic programming language that has some interesting quirks and features of its own that make it a truly interesting and very unique language to learn and utilize. As a Data-Scientist, nothing is more exciting than learning a new programming language to program AI in. But there are some important things to note going into Julia, and some things you should know prior to even trying to use it.
“ Walks like Python, Runs like C”
I think one of many misleading things about Julia is a term that originates from the very idea of the language, and isn’t necessarily unfounded. However, I believe that this term provides a-lot of inaccuracies to new-comers to the language, as Julia’s frequent users would say that this definitely is an inaccurate description of Julia. Julia really is a beast of it’s own. Not only as a result of its differently written language, but also its many interesting, and sometimes downright astounding quirks.
Firstly, Julia’s syntax is somewhat similar to Python, but this similarity can be found in most programming languages, especially statistical languages. If I, as a pretty experienced programmer, had to compare the syntax to any specific language, I would say Microsoft’s Basic. That’s right, that silly language we all wrote when we were six years old is similar to this new-found open-source programming language out of MIT. This also doesn’t come with many caveats, it really is that simple. And my biggest supporting factor for this is probably the way functions and methods are done in Julia. Don’t believe me? Take a look at a little comparison:
And here’s that same function written in Julia. (Note I forgot the return)
That’s right, Julia is not (technically) an object oriented language. To me, this is Julia’s biggest quirk, and probably the biggest learning curve of learning Julia. All methods are contained within the Julia base, or modules, not constructors.
For example, something like a model.fit() function cannot exist in Julia. Instead, typically models have a fit method that takes a constructed datatype that typically contains more data inside of it. As I have written a machine-learning and statistics module for Julia, which you can take a look at here, I will be using the source from it to explain what this is like in practice, and exactly what’s going on. Here is a sample notebook which outlines using a test, train split, and fitting a model using Lathe in Julia.
mutable struct meanBaseline    y :: AbstractArrayend
These lines are a constructor for a model, which can be fit by simply calling a variable equal to it,
y = 1,5,3,6,8model = models.meanBaseline(y)
The reason why there is no X in this model is because it’s just a meanBaseline model, which will give us a baseline accuracy for a continous feature, other models would be exactly the same, just with an x.
So typically in an object-oriented language, like Python, after fitting our model we would use the model.fit(x,y) method, however because constructors in Julia do not contain methods, we must use a separate method to fit our model, at the root of our module. To do this, I used conditionals to determine the typeof() the input model.
function predict(m,x)if typeof(m) == TurtleShell        y_pred = pred_turtleshell(m,x)    end    if typeof(m) == majBaseline        y_pred = pred_catbaseline(m,x)    end    if typeof(m) == LinearRegression        y_pred = pred_linearregression(m,x)    end    if typeof(m) == meanBaseline        y_pred = pred_meanbaseline(m,x)    end    return(y_pred)end
As a result, predicting the model looks something like this:
models.fit(model,xtrain)
And that yields return of the fitted model’s prediction of the y for our X.
So the way I see it, for data-science, this is an interesting proposition. Sometimes it can be a little annoying to have to call a method for everything, but it’s welcome for me, because It is very different and interesting.
The worry for something like this is just how valuable it will be to a typical Data Scientist, especially for something like portfolio pieces, or any serious projects. Not being object oriented means that Julia will likely need to use PyCall to be even close to as versatile as Python. And even that is certainly not a sure-fire way to create any sort of applications in Julia. One of the greatest things about Python as apposed to R, and even Scala is that Python has so many fantastic libraries to do just about anything. You can develop web applications with Django and Flask that work with SQL databases, develop applications with multiple frameworks for desktop computers, as well as mobile devices. This is made easier primarily because Python is object-oriented. I would be very interested to see if Julia is going to take that anywhere, or leave it as it is.
These dis-advantages might be a little critical, as it isn’t exactly the purpose of this language. I like to think of it as a bridge between Python and Spark. And it is fantastic at that exact operation, being simple like Python, and the machine-learning base of Python, but having the big-data manipulation capabilities of Spark. It’s definitely something to take note of when starting your Julia data-science journey.
It’s important to note that Julia really is still in its infancy, just merely getting out of version 1.0. Often times when using Julia, it can really feel foreign, and a little bit too open-source, if you know what I mean. It feels refined, and fresh, but at the same time it can feel a little janky, especially when compared to languages that have been on the chopping block for more than 15 years.
As a result of the lack of versatility behind Julia as of version 1.0.4, It definitely feels like a-lot more is to come for Julia’s future. I like to think about early versions of Python and C++, it’s a slow and grueling process, but as more come to use, love, and accept Julia, it might become more widely accepted as a standard tool for Data-Science.
This is why I have been working on predictive modeling and statistical libraries for Julia, to make a switch a little easier with stronger documentation and simple functions with simple inputs and outputs. I’m really excited to see where Julia will go in the coming years, who knows? Maybe 5 years down the line our Python hats won’t be so sewed on, and we’ll use Julia Flux as our replacement for Pythonic Tensor. Regardless, Julia is definitely an awesome and unique tool to have in your scientific arsenal for predictive modeling, visualization, statistics, and machine learning.