But then, I remember a computer vision teacher 3 years ago laughing at the idea of using Python instead of Matlab as Matlab is the "obvious industry standard".
The two arguments that speak for Julia from a user perspective (there exist much stronger arguments for package developers).
a; Low overhead interoperability with Python, R, C and Fortran (and C++); You don't need to rewrite your code and you can start using Julia and slowly transition.
b; User code as fast as package/base library code. You are not stuck with what already exists.
I think these are areas where the 2-language model makes Python quite a bit less productive than Julia.
Example: in Julia I can easily define my own primitive type, let's say a ModInteger (an old video is here [2]) and it will be as fast as a normal "built in" integer in a for loop (and benefit from possible speedups: simd, parallelization, cuda, GPU - but don't have (much) experience in this area).
Likely such a ModInteger couldn't be as easily integrated in Numba?
[1]: https://discourse.julialang.org/t/julia-motivation-why-weren... [2]: (2013) https://www.youtube.com/watch?v=rUczbQ6ZPd8 (at ~37:00 mins)
The other place where Julia might see better speed is when you have an optimization algorithm and the objective function both written in Julia, which allows for optimization across functions, whereas in Python you could write a fast objective function with Numba but couldn't optimize across function call with the optimizer written in Fortran.
Julia's adoption rate is really impressive compared to R or things like numpy, etc. so I'm not worried about that. But I do think it will have to contend with a number of competitors in the same space.