The Julia Language – A fresh approach to technical computing
julialang.org
julialang.org
I wouldn't say it's non-obvious: the things you have to do would be obvious to any programmer who's written code in something like C++. The problem usually tends to be that MATLAB, R, and Python tend to train people to want to use sub-optimal programming styles, like something heavy on array allocations, even if writing a function that does a loop is perfectly optimal. If someone is always told that mapping one function at a time ("vectorization") is the optimal way to do things, then they will try it when they go to a more optimal language. So it's really just a re-education issue.
Being permissive lowers the barrier for non CS people, one of the main target of the language, to start using the language, especially in the REPL/Notebook, even if they are not the most effective at the language.
A highly tuned kernel function can be inlined into a not so finely tuned outer function and vice versa, our metaprogramming tools see both functions the same, etc.
But since fast and slow code are so similar, and both give the same ultimate result, it becomes less obvious for someone who is reading someone's code to see what was made to make it fast (even if it's easy to see what the code does because of it's high level nature). I think that's something that could improve over time with better tooling, using the meta-capabilities of the language to create linters and compiler suggestions that guide the users into making the small changes in the code that makes the most difference.
Most performance tips are similar across most fast languages: minimize OS-managed allocations, use cache and SIMD friendly memory layouts, better algo design in general. I find that these optimizations are typically easier in Julia than in most languages.
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).
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.
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.
No need to rewrite Django:
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.
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!).