Mathematica does several optimizations before execution, and as such can exploit a priori knowledge of many problems.

The danger of course is when Wolfram takes those assumptions into a room of mathematicians. It is controversial for all the wrong reasons. =)

It is a common question by the way =)

https://stackoverflow.com/questions/60121757/julia-vs-mathem...

Julia already is a very high-level mathematics-oriented programming language, though.

The reason Mathematica is so much faster here is it’s using a different algorithm. When you compare using the same algorithm, Julia is 10-100x faster than Mathematica. https://julialang.org/benchmarks/

Yes, Julia has wrappers for many other languages, so there are options if you really need some specific chunk of C/C++, Fortran, Python, Octave or R etc.

Yet a polyglot project is bad design, and tends to become an abomination in time. This is one reason many Go programmers rewrote libraries rather than saturate their code with cgo/C and SWIG/C++ wrappers. Similarly, people are writing scalable versions of libraries in Julia to improve transparent parallel performance for problems too big for a single machine to feasibly handle.

Things are still undergoing change, but of course the commercial nvidia binary blobs will haunt everyone for awhile. =)

I feel like you’re misunderstanding how Julia syntax works. Julia syntax is Python syntax, for the most part. They’re not identical, but the differences are very small, and typically favor Julia—for example, compare:

x*(y.^2)

To the Python equivalent:

np.matmul(x, map(lambda x : x^2, y))

Note also that the first will be much faster because it can fuse the matrix multiplication with the exponentiation. That’s because Julia is a single language, and the whole thing is compiled at the same time. Python can’t fix the above code because NumPy is written in C, not Python.

Julia is just Python but fast.

Y-cruncher is closed source, there’s no way to know the number of lines of code it uses compared to Julia.