How hard would it be to implement Numpy.jl, i.e. Numpy in Julia?

There are a couple of independent questions here.

Should we implement NumPy functionality in Julia? Definitely yes, and in fact this is mostly done — nearly all of NumPy (and much of SciPy) functionality, including zero-based arrays, is already available in the Julia standard library or packages.

Should we implement a Julia backend/transpiler for Pythran/Cython/Numba? There seems to be essentially no benefit to this because:

  • It wouldn’t be any faster — the semantics of Python/Pythran/etc would limit such a transpiler to generating code pretty much equivalent to what Pythran etc. generate now, and for NumPy-like operations on NumPy data types the C implementations in NumPy are basically as good as anything we can do.

  • It wouldn’t gain you any advantages of Julia, and in particular you wouldn’t be able to write efficient fully type-generic code, because again you are limited to Python/Pythran/etc semantics.

  • It wouldn’t make it any easier to call innovative Julia libraries (i.e. ones that don’t simply duplicate NumPy operations) compared to work on further developing pyjulia.

In cases where Julia programmers develop innovative new functionality or greater performance that is not available in Python, it is definitely nice to expose this programmers in Python and other languages where possible, and in general I’m a big fan of inter-language bridges! But transpilers are an overcomplicated way to do this compared to simple glue code like pyjulia (e.g. as used by diffeqpy) to let you call Julia libraries from Python.

I feel like there should be a Julia FAQ about this somewhere, because it’s pretty common for people’s first reaction to Julia to be Lots of people are used to language X, why can’t you just compile this to Julia? (Update: there is now a FAQ.)

35 Likes