5 ms·

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 an

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.

BeetleB 6y ago
> 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.
- srean 6y ago
  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.
  - BeetleB 6y ago
    You probably don't realize it, you are agreeing with me :-)
    - srean 6y ago
      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.
  - edgyquant 6y ago
    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.
    - throrthaway 6y ago
      OCaml?
    - cycomanic 6y ago
      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.
- unishark 6y ago
  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.
  - g0wda 6y ago
    In Julia, there is one package manager and it gets things right. https://docs.julialang.org/en/v1/stdlib/Pkg/ 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 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.
    - kwertzzz 6y ago
      I also like that package environments are integrated in Julia and thus there is only one way handle environments.
- Fishysoup 6y ago
  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.
- dunefox 6y ago
  > 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.
adamnemecek 6y ago
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.
- kwertzzz 6y ago
  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)
Mikhail_K 6y ago
> 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)

BeetleB 6y ago

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

srean 6y ago
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.
- BeetleB 6y ago
  You probably don't realize it, you are agreeing with me :-)
  - srean 6y ago
    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.
- edgyquant 6y ago
  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.
  - throrthaway 6y ago
    OCaml?
  - cycomanic 6y ago
    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.
unishark 6y ago
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.
- g0wda 6y ago
  In Julia, there is one package manager and it gets things right. https://docs.julialang.org/en/v1/stdlib/Pkg/ 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 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.
  - kwertzzz 6y ago
    I also like that package environments are integrated in Julia and thus there is only one way handle environments.
Fishysoup 6y ago
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.
dunefox 6y ago
> 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.

adamnemecek 6y ago

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.

kwertzzz 6y ago
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)

Mikhail_K 6y ago

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