>Julia libraries are still wrapping Fortran numerical library

You say that, but Julia is rapidly acquiring native numerical libraries that outperform OpenBLAS:

https://discourse.julialang.org/t/realistically-how-close-is...

There’s been a tremendous amount of work optimizing blas _and_ ensuring it’s numerically stable. Julia made a good choice to use blas first. Though it’s good to see new native implementations.

For Nim, there’s also NimTorch which is interesting in that it builds on Nim’s C++ target to generate native PyTorch code. Even Python is technically a second class citizen for the C++ code. Most ML libraries are C++ all the way down.

https://github.com/sinkingsugar/nimtorch

Not necessarily true with Julia. Many libraries like DifferentialEquations.jl are Julia all of the way down because the pure Julia BLAS tools outperform OpenBLAS and MKL in certain areas. For example see:

https://github.com/YingboMa/RecursiveFactorization.jl/pull/2...

So a stiff ODE solve is pure Julia, LU-factorizations and all. This is what allows it to outperform the common C and Fortran libraries very consistently. See https://benchmarks.sciml.ai/html/MultiLanguage/wrapper_packa... and https://benchmarks.sciml.ai/html/Bio/BCR.html

Julia is in the process of replacing many C and Fortran numerical libraries with pure Julia implementations, because they have similar performance.