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

**URL:** <https://discourse.julialang.org/t/how-hard-would-it-be-to-implement-numpy-jl-i-e-numpy-in-julia/22080>\
**Category:** Numerics\
**Tags:** faq, python\
**Created:** [March 19, 2019, 10:48pm UTC](https://discourse.julialang.org/t/how-hard-would-it-be-to-implement-numpy-jl-i-e-numpy-in-julia/22080 "2019-03-19T22:48:54Z")\
**Posts on this page:** 1\
**Showing post:** 58

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [March 22, 2019, 2:43pm UTC](https://discourse.julialang.org/t/how-hard-would-it-be-to-implement-numpy-jl-i-e-numpy-in-julia/22080/58 "2019-03-22T14:43:51Z")

</div>

> [@Pierre\_Augier](#):
>
> I’m sorry, but it is what is useful in my work for the numerical kernels.

If the restricted kind of code that Numba/Pythran can optimize is fine for your application, then lucky for you! We use Julia because we want more flexibility and composability than that, not because Julia is magically faster at simple `a[i] = 2*a[i] + 1` style loops over arrays of `Float64` scalars ( **it isn’t** ). There was a long thread about this that we don’t want to repeat: [Julia motivation: why weren't Numpy, Scipy, Numba, good enough?](https://discourse.julialang.org/t/julia-motivation-why-werent-numpy-scipy-numba-good-enough/2236?filter=summary)

---

_[View the full topic](https://discourse.julialang.org/t/how-hard-would-it-be-to-implement-numpy-jl-i-e-numpy-in-julia/22080)._