Hacker News Reader

Comment by Fishysoup | Hacker News Reader

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.

View on HN

> 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.

Well that could have been said (and was said) about Numpy/Scipy when it started, "oh R has so many more packages, what numpy can do I can do in MATLAB ...", yet here we are.

You probably don't realize it, you are agreeing with me :-)

It depends on the definition of 'people'. There were many who adopted numpy much before the ecosystem had had time to catchup. But I would readily concede that Dr. Jones @national_lab didnt at that time, in fact he probably hasnt even now.

I do disagree strongly with the opinion that Numpy is no better than MATLAB :). MATLAB has adopted some Numpy features after Numpy came out (broadcasting for example) but Numpy offered some genuine and unique advantages, both technical (broadcasting, no need for a MEX compiler that I have to pay through my nose for, not restricted to weird naming conventions, nature of parameter passing, ...) and legal.

I just don't like the BASIC derived syntax of Julia (and Ruby.) I wish there was a language that was typed, had python like classes, subroutines and lambdas but JS like anonymous functions that was fast like Julia or at least close to numpy in number crunching without needing a module written in C.

Have a look at Nim, I was presently surprised when I recently tried it out. Now if there was just a better way of integrating with numpy it would be my goto language for writing computation intensive modules for python.

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.

I also like that package environments are integrated in Julia and thus there is only one way handle environments.

I think Numpy made it easier for people to integrate with a ton of open source libraries. Since everything is proprietary and the users are in a few specific niches, Matlab can't be as versatile. Also, each of the Matlab add-ons are another expensive license people are reluctant to pay. Sure, there are a bunch of contributed libraries for specific tasks, but comparatively the community is pretty poor.

> That's not a small issue.

In fact, it's not an issue at all since Julias ecosystem is a superset of that of Python: with PyCall you can use Python libraries and Julia libraries in one program without issues.

Julia interop with Python is insanely easy.

using PyCall

np = pyimport("numpy")

res = np.fft.fft(rand(ComplexF64, 10))

You just called numpy fft from Julia.

Yes, and the interface is pretty fast and without any noticeable overhead:

julia> data = rand(ComplexF64, 1024^2);

# python fft from julia:

julia> res = @btime np.fft.fft(data);

  78.613 ms (39 allocations: 16.00 MiB)

# python fft in ipython:

In [11]: %timeit res = np.fft.fft(data)

89.3 ms ± 1.65 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)

As expected, julia has its own fft package (based on FFTW):

julia> res = @btime fft(data);

  61.540 ms (33 allocations: 16.00 MiB)

> its package ecosystem isn't as mature as Python's.

Python packages are either interfacing external libraries (something that is much easier to do in Julia) or if they are pure python, badly designed and buggy.

(and package management in python is broken beyond repair)

Reply on news.ycombinator.com