Ah, just the right time to publish about numpy - right when everyone is moving over to Julia because of numpy's warts.

I'm interested in Julia, but if numpy has warts, I suppose Julia has not yet had time to even grow its skin.

Theoretically Julia is better for scientific computing, the only issue is its package ecosystem isn't as mature as Python's. But it's growing incredibly fast and there have already been libraries available for a few years that would be really impractical to write and maintain at such a level in C++ for Python. I assume that for science at least Julia will catch on a lot.

> Theoretically Julia is better for scientific computing, the only issue is its package ecosystem isn't as mature as Python's.

That's not a small issue. The ecosystem is probably the reason people choose NumPy over MATLAB, for example. NumPy is not inherently superior to MATLAB, and most academicians that adopted NumPy in the 2000's already had a MATLAB license, so cost was not a concern either.

I started using python and numpy/scipy back then because it was vastly easier to deploy on a server or supercomputer. The matlab compiler meanwhile is clunky and adds new bugs and additional steps. Julia doesn't really match python in this regard either.

For more pure research and prototyping things both can do, I still think matlab is better though I rarely use it. I just like the idea of being able to easily deploy the code later somehow. Kind of an entrepreneurial feature.

In Julia, there is one package manager and it gets things right. https://docs.julialang.org/en/v1/stdlib/Pkg/ It's super nice to have no fragmentation when it comes to packaging. In Pkg, package states are immutable, always reproducible, and quick. Julia packages that have binary dependencies usually build them all for every platform using the binary builder infrastructure (https://github.com/JuliaPackaging/Yggdrasil). It makes cross platform installation robust and testable, and suuuper quick. Pkg really is the rolls royce of package managers.