Maybe the point got muddled, but you made a statement that " Pythran and xtensor arrays are more general than julia native ones with respect to layouts (support row-major, column-major, strided)". In a very strict interpretation this could be true, but in reality it’s false because the whole point of Julia is to not use Array, but instead have code use any AbstractArray type, and so row-major, column-major, strided, graphical, sparse, permuted, blocked, etc. are all just type information over a slab of memory presented as an array, and Julia code doesn’t care which one you give it. So for example, Transpose{T,Matrix{T}} is perfectly fine row-major array that’ll work wherever it’s needed, so there’s no reason to implement a row-major array as a primitive type and instead you let dispatch apply to this. So since the true sense of an array in Julia is any array type made by any package in Julia which subtypes AbstractArray, I can pull out a few thousand examples to show how “what’s built-in” (to the Julia ecosystem) is already more generic than Pythran/xtensor (and of course xtensor is probably generic enough that you can spend some time writing your own C++ code to implement some array type, but that’s quite different than having the choices already existing and in the language that you’re scripting with. We can argue that forever though: C++ is fine if you understand it.)
However, to use this to one’s advantage, you have to be using Julia’s type system. So if you then want to create a Numpy.jl, you’d hardcode to specific types and implement specific functions. But if you’re stuck at that point, you lose all of the genericness, so why use Julia? You’re essentially just writing C/Fortran code at that point, where maybe dispatch can help structure the code a bit more nicely but you wouldn’t expect performance gains and the user experience would be largely the same in the best case scenario.