I don't think Julia really solves any problems that aren't already solved by Python. Python is sometimes slower (hot loops), but for that you have Numba. And if something is truly performance critical, it should be written or rewritten in C++ anyway.

But Julia also introduces new problems, such as JIT warmup (so it's not really suitable for scripting) and is still not considered trustworthy:

https://yuri.is/not-julia/

> Python is sometimes slower (hot loops), but for that you have Numba

This is a huge understatement. At the hedge fund I work at, I learned Julia by porting a heavily optimized Python pipeline. Hundreds of hours had gone into the Python version – it was essentially entirely glue code over C.

In about two weeks of learning Julia, I ported the pipeline and got it 14x faster. This was worth multiple senior FTE salaries. With the same amount of effort, my coworkers – who are much better engineers than I am – had not managed to get any significant part of the pipeline onto Numba.

> And if something is truly performance critical, it should be written or rewritten in C++ anyway.

Part of our interview process is a take-home where we ask candidates to build the fastest version of a pipeline they possibly can. People usually use C++ or Julia. All of the fastest answers are in Julia.

As your comment already hints at, using Python often ends up a hodgepodge of libraries and tools glued together, that work for their limited scope but show their shaky foundations any time your work is outside of those parts. Having worked with researchers and engineers for years on their codebases, there is already too much "throw shit at the wall and see what sticks" temptation in this type of code (because they'd much rather be working on their research than on the code), and the Python way of doing things actively encourages that. Julia's type hierarchies, integrated easy package management, and many elements of its design make writing better code easier and even the smoother path.

> I don't think Julia really solves any problems that aren't already solved by Python.

I don't really need proper furniture, the cardboard boxes and books setup I had previously "solved" the same problems, but I feel less worried about random parts of it suddenly buckling, and it is much more ergonomic in practice too.

> I don't think Julia really solves any problems that aren't already solved by Python.

But isn't the whole point of this article that Matlab is more readable than Python (i.e. solves the readability problem)? The Matlab and Julia code for the provided example are equivalent[1]: which means Julia has more readable math than Python.

[1]: Technically, the article's code will not work in Julia because Julia gives semantic meaning to commas in brackets, while Matlab does not. It is perfectly valid to use spaces as separators in Matlab, meaning that the following Julia code is also valid Matlab which is equivalent to the Matlab code block provided in the article.

    X = [ 1 2 3 ];
    Y = [ 1 2 3;
          4 5 6;
          7 8 9 ];
    Z = Y * X';
    W = [ Z Z ];

Yes, Python code is indeed fast if you write it in C++... what a bizarre argument. The whole selling point of Julia is that I can BOTH have a dynamic language with a REPL, where I can redefine methods etc, AND that it runs so fast there is no need to go to another language.

It's wild what people get used to. Rustaceans adapt to excruciating compile times and borrowchecker nonsense, and apparently Pythonistas think it's a great argument in favor of Python that all performance sensitive Python libraries must be rewritten in another language.

In fairness, we Julians have to adapt to a script having a 10 second JIT latency before even starting...

>I don't think Julia really solves any problems that aren't already solved by Python.

You read the article that compares MATLAB to Python? It's saying MATLAB, although some issues exist, still relevant because it's math-like. GP points out Julia is also math-like without those issues.

In Julia, you explicitly need to still reason about and select GPU drivers + manage residency of tensors; in RunMat we abstract that away, and just do it for you. You just write math, and we do an equivalent of a JIT to just figure out when to run it on GPU for you.

Our goal is to make a runtime that lets people stay at the math layer as much as possible, and run the math as fast as possible.

Sometimes slower? No, always slower. And no one wants to deal with the mess that is creating an interface with C or C++. And I wouldn’t want to code in that either, way too much time, effort, headache.