Ask HN: Why hasn't the deep learning community embraced Julia yet?

There are generic answers:

- Refactoring business logic costs. That's why it doesn't happen often.

- Interop between two different codebases (new Julia, old Python) costs (both at an org scale and at programming scale).

- It's a new lang. Hiring new programmers to a new meme language is very risky. You lose that programmer, your project is in trouble.

- You are underrating Python ecosystem strength.

- Python first mover advantage.

There are Julia specific reasons:

- No Julia programmers outside of MIT where as everyone has touched Python.

- Python is "simpler".

- Last I read Julia has some growing pains, like REPL boot times?

The fact that the ecosystem is largely created by academics is also a serious issue. Code quality is very low / things silently break / etc. This is partly an issue with Julia itself; the language offers few tools to verify the correctness of your code. (E.g. interfaces etc.)

Julia vs XYZ is an old topic. And yet this keeps coming up! There's quite a lot of blog posts on the topic. (E.g. here's mine: https://kidger.site/thoughts/jax-vs-julia/)

julia also has weird behaviors scattered all over the place

- pytorch or tensorflow - pandas - numpy - scipy - matplotlib - huggingface transformers - jupyter

R has multithread support: https://josephcrispell.github.io/2018/08/27/multi-threading-...

Julia's main draw was native really fast code with multi-thread/parallel support.

The other issue is that a parallelized c version of a data science algorithm can be scripted by Python or R pretty easily.

. slow startup time

. 1-based indexing

. more complicated than python (many ML practitioners aren't really great at CS)

. native speed (a clear Julia win) doesn't really matter in the ML world: in ML, speed matters on learning and inference, where the language used to build and massage models is irrelevant, all of them compile models to run on GPU/TPU/etc ...

If we don't get hung up on the exact literalness of that statement, there's a lot of truth to it. Being essentially a "lingua franca" that's easy to pick up has accelerated it in various seemingly unrelated fields. This, I assume, it to the seeming detriment of use-case specific languages like Julia.

Is it similar in ML?

Julia seems like an attempt at a better matlab, but the machine learning world moved to python first.

(Also 1-based indexing is almost as obnoxious as the 24/7 Julia shill brigade.)

When I want to experience a new language, I got to a place on the web, where I can try it.

For Python, there are https://www.online-python.com/ and many others.

For PHP there are https://3v4l.org and many others.

For Javascript there are https://jsfiddle.net/ and many others.

But every time I think "Hey, I might give Julia a try", I go to Google and type "try julia online" and find nothing. Every site either wants me to sign up or is dysfunctional. So I think "What? That cannot be. Lets try a different search". And search for "julia online repl". Again. Nothing works. And I give up.

I just did this again.

And I might try again in a year or so.

That's the situation here regarding Julia.

The ecosystem also feels weird. For example for CLI parsing in Python I do argparse/click, in Rust I do clap. Both work well (Rust especially so). Julia seems to have ArgParse.jl which I found unpleasant. My guess is that this sentiment spills to other areas as well in the ecosystem. I am sure that Julia has very well designed libraries, but most of the rest are not so honed for practical use, and most importantly, probably lacks some features that Python-equivalent ones have.

Also personally (I am far from a DL researcher but I do research), I find Julia's design headachy as well quite some times. I like Python yield statements for iterators but the equivalent in Julia is always more complicated. Making Julia code performant requires another layer of intuition of how the JIT works. Julia has type annotations but "type annotations as lightweight formal methods" often cannot be fulfilled due to design (for example one cannot annotate the equivalent of `map :: (a -> b) -> [a] -> [b]`). Of course I stand corrected as only a casual Julia user.

I also want to say that I only stated my criticism towards the language. There are many many good things about Julia that I will just omit due to time.

That said I'm no lover of python, I just think this is a huge contributing factor to its rise in popularity. A little conspiracy theory, if you will ;)

An initial disclaimer. I am an academic that has been involved in the Julia community for many years and written plenty of Julia code myself. In addition, my entire team uses Python as their day-to-day language to drive research (I do not code nearly as much as I used to these days) and Python was what I used for artificial intelligence research for many years as a student and researcher.

Looking at the other comments, I find that most focus on language features, implementation aspects, ergonomics, etc. I think this is a distraction for machine learning code, at the very least when it comes to research. Rather, I think we need to ask: What determines success for a machine learning researcher/practitioner?

Firstly, if we turn back the clock ten or so years, most models were written from scratch. This was the time when there was an active “battle” between Java, Matlab, and Python for mindshare. With the shift to deep learning (and GPGPUs), big libraries/frameworks have taken over as these models can be easily composed from primitives of varying degrees and coupled with training algorithms, regularisers, losses, etc. Pre-trained models have also become increasingly commonplace and although they can be ported between languages, the safest bet is of course to go with the training/inference code that the original authors used: Most likely, Python. Julia is putting up a decent fight here against libraries/frameworks backed by some of the richest corporate entities on the planet, but it makes were little sense for most people to go against the grain here as their success is determined by how fast (think man hours) they can put together experiments or push things into production. Dare I say that no one ever got fired for picking Python?

Secondly, if you are a Julian and at this point decry how sluggish the snake is, how its implementations are suboptimal stacks across language boundaries, has ancient ergonomics, etc. You are most likely missing the point. I doubt that this battle is won based on any of these “nice-to-haves”. I had the pleasure to sit down with among others Flux’s creator back in 2016 and what I said then I believe still holds today: “We can not just better express what models others can express, we need to enable the creation of new models which other languages can not easily express”. We have seen Julia gain some traction when it comes to Neural Differential Equations for example, which I believe is akin to what I am talking about here. Perhaps there is hope in Julia having a better interface when it comes to bridging symbolic and non-symbolic models, but ultimately it is difficult to predict the future in terms of which models will succeed and dominate the field.

To me, if we focus solely on the language itself Julia is largely superior. It has better ergonomics to express machine learning (well, maths in general), a better packaging system (the fact that I have known Python for more than 15 years and it still struggles when it comes to deployment boggles my mind), etc. But, at the end of the day, I think that the delta here is simply not big enough – yet? – to motivate the great majority of researchers and practitioners to make the jump and I respect what I believe is a very rational choice on their part.

In academia code is the means to an end, which is usually a paper. This means that the experience of writing the code, making sure it's portable, readable, etc. don't really matter. These are all industry concerns; specifics of implementation, not algorithm design/mathematical questions.

This isn't reflected in Julia as a language as much as it is in Julia as an ecosystem. Some of the packages I work with are poorly maintained or designed with 0 thought to the issues I described earlier. And since Julia is so new, there are few alternatives.

Imagine if your software was written by your college professor who'd pushed to prod maybe like 3 times in their life. Instead of just fixing the damn bug they're liable to make you fix it instead as an 'exercise for the reader', or posit that the problem input is outside of the scope of their class and refer you to another one.

My example of this is the Colors.jl package. Images, rather than being 3D arrays of floats/ints, instead become 2D arrays of RGB/HSV. But you can't do any arithmetic on RGB/HSV values, you need ColorVectorSpace.jl for that. I'm sure it makes sense, but I can't help but feel as if sense is taking precedence over the programmer's experience in many of these packages.

Again, I don't think Julia as a language is unfit for widespread use. But before it can be, it needs to burst out of its ivory bubble.

Python:

  >>> 2**2**2**2**2
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  ValueError: Exceeds the limit (4300) for integer string conversion

  #include <stdio.h>
  #include <stdlib.h>
  #include <math.h>
  
  int main(int argc, char* argv[])
  {
   printf("%.0lf\n", pow(pow(pow(pow(pow(2, 2), 2), 2), 2), 2));
   return EXIT_SUCCESS;
  }
  
  % gcc -o main -std=c18 -O2 -pipe -fPIC -fno-plt -fstack-protector-strong main.c && ./main
  4294967296

  julia> 2^2^2^2^2
  0

I would prefer as much as possible that we have the leanest tech stack possible. That means reducing the number of languages, libraries, etc to a sane amount.

Is this view, Python is a very good candidate for data science.

You can keep the same language for your data science logic and scientists, as well as for your more down to earth developments on infrastructure/techie stuff.