Time will tell.
History has not so far been kind to projects which attempt to supplant cPython, whether they are other Python variants such as PyPy, or other languages such as julia.
Python has a lot of detractors, but (despite some huge missteps with the 2-3 transition) the core team keeps churning out stuff that people want to use.
Mojo is being positioned "as a member of the Python family" but, like Pyrex/Cython, it has special syntax, and even worse, the calling convention is both different than Python, and depends on the type of variable being passed. And the introspection is completely missing.
What about numpyro?
Disclaimer: I contribute to numpyro occasionally.
If you don't mind me asking, what's the deal with NumPyro why you chose to work it?
But the first thing that gave me pause about Julia? They sort of pivoted to say "we're general purpose" but the whole index-starting-at-one thing really belies that -- these days, that's pretty much the province of specialty languages.
It resonates with me, as does little-endian. There are evergreen arguments about both of these, but they stand out to me as two of the few places where I appear to be in sync with the majority.
> Pascal is using 1-ord, Fortran, R, Mathematica. If anything, it seems there's a longer tradition of 1-ord in scientific computing.
Actually, Pascal let you define the starting point, but, historically, COBOL (business) and FORTRAN started at one, and these days, it's Matlab (engineering), as well as R, Mathematica, and Julia. But, really, my point was that Julia is hyped to take over from Python, and it seems if that's the focus, then you should think long and hard about what features of Python to change, and, well, obviously that wasn't really the direction they came from.
> semantics like that, without unnecessarily sacrificing performance—I don't think they get enough credit for that from programming guys.
It's good work, but at the same time, a bit overblown IMO. For example, the creators claim homoiconicity, but that stretches the definition of that word to where Python would be homoiconic as well, and it's obviously not.
As far as the multiple dispatch goes, that's actually not that difficult of a puzzle piece when you are compiling ahead of time with unboxed objects.
Expr(:call, :+, 1, Expr(:call, :*, 2, 3)) |> eval # 7
The fact that it displays as 1 + 2 * 3 instead of (+ 1 (* 2 3)) ... meh. The whole point is to make metaprogramming easy, which Julia is quite successful at (for better or worse -- some people shouldn't be allowed near macros).Long term it can find applications outside of ML-specific hardware.