But languages doesn't work in silos. I don't want a fast language that I cannot use for writing, say web servers, without rewriting 90% of django.
The proposition of python is that you get acceptable performance with an insane package repository that means you can ship so much faster.
And if you absolutely need to write for loops, use clever things like numba or cython.
Stop reinventing the wheel people.
Julia was created with 20 years of extra knowledge from Python, Matlab, R and other languages, and from a domain that basically didn't exist when Python was designed, resulting in a set of features that cannot be added to Python at this point. It's a different wheel, which can move faster so even if the cars with the old wheel are way ahead, it can still eventually catch up (creating libraries in Julia from scratch is easier and faster so it can compete even 20 years late and with much lower support). Should we stop trying to create improved languages, stay with the languages we have now forever and simply create increasingly "clever" ways to compensate any flaw (that can't be directly fixed without breaking all that legacy)?
Plus Julia has web frameworks like Genie, but it's true that they are nowhere near as mature (especially compared to a project that is considerably older than Julia itself).
Easier than what? In what ways is it faster?
I did mention from scratch because of course, if your library requires another library that does not exist (and you don't want to use the FFI), it won't be faster or easier (though I did mention in the previous comment that it's something all new languages will have to go through, until it's not a problem anymore).
You absolutely do not. There are a ton of holes in the Python package ecosystem that have been plugged by Julia. For example, stiff ODE solvers that mix with structured matrices, like block banded matrices, are very common in PDE fields, but Python really just has (very slow) stiff ODE solvers and unstructured sparse matrices are the only thing you can mix with that, along with a lack of a solid sparse AD. You can keep going down the list of all of these applications that are wide open, and where Julia libraries already are either (a) existing where Python libraries don't exist or (b) are orders of magnitude faster. So let's be a bit more concrete there: there are areas where Python packages can get you by, and there are not, and there are a lot of things in the not category (which is why we as devs exist!).
That's really bad advice. Re-inventing the wheel is a good idea, and should definitely happen from time to time. If you can use new technology and ditch old preceptions, you may actually be able to make a better wheel.
Even if it fails, it's a good idea to try.
No need to rewrite Django:
I think Julia is older than numba by the way. Personally I haven't used it much, but I like the idea.
For run-of-the-mill numerical computation, like you said it's good writing loops and code that is really natural and run it fast. Most commonly used algorithms for data science and scientific computing are already written in Julia, you don't need to write them from scratch. But it's good to have libraries that you can easily inspect, understand and extend within your code.
A really interesting trend in the data science community is that languages can be used in conjunction with one another. This can be seen in projects like Jupyter (Julia, Python, Latex, and R), Julia's FFI, and Apache Arrow.