3 ms·

You can use Python, C and Fortran code from Julia. More importantly package development is much faster in Julia than in Python. Which means the speed of which p

You can use Python, C and Fortran code from Julia. More importantly package development is much faster in Julia than in Python. Which means the speed of which packages get added to Julia is much faster than Python. And here is the kicker: Packages is Julia are far more interoperable than in any other eco system I have seen. Than means 10 packages in Julia can quickly do more than 50 packages in other language. Say somebody makes a GPU processing package and somebody else makes a Machine learning package. They don't know about it each other. Yet with Julia we frequently see that these guy can use each others package. The ML package can with little effort run on a GPU by including a GPU package even if it was never designed for it. Julia just moves way faster than the competition and that is why Julia is NOT doomed.

coldtea 7y ago
>You can use Python, C and Fortran code from Julia. More importantly package development is much faster in Julia than in Python. Which means the speed of which packages get added to Julia is much faster than Python. That's because Python already has tons, while Julia lacks tons. Are the new ones added to Julia as good or better though? >That means 10 packages in Julia can quickly do more than 50 packages in other language. Say somebody makes a GPU processing package and somebody else makes a Machine learning package. They don't know about it each other. Yet with Julia we frequently see that these guy can use each others package. The ML package can with little effort run on a GPU by including a GPU package even if it was never designed for it. This sounds like magic bullet / handwaving. Perhaps Julia's multiple dispatch helps here (?), but why would the above be the case and wouldn't be achievable in other existing languages as is?
- StefanKarpinski 7y ago
  > Perhaps Julia's multiple dispatch helps here (?), but why would the above be the case and wouldn't be achievable in other existing languages as is? Yes, ubiquitous, zero-overhead multiple dispatch is the reason, as explained in depth here: https://youtu.be/kc9HwsxE1OY https://youtu.be/kc9HwsxE1OY
  - coldtea 7y ago
    Thanks, checking!
- ChrisRackauckas 7y ago
  >This sounds like magic bullet / handwaving. It's not handwaving when it already exists. CUDAnative.jl gives native compilation of Julia code to GPUs, which allows CuArrays.jl to do efficient loop fusion among other tricks. This is then enough for DifferentialEquations.jl, Flux.jl (the big neural net library, think PyTorch), CLIMA (a MIT-CalTech next-gen climate model), etc. (too many packages to list) to all utilize the same underlying GPU framework. It's as if someone got rid of the GPU functionality of Numba, PyTorch, TensorFlow, etc. and just made one good enough Python library for everyone to share. As you can imagine, that reduces the amount of work to do package development but gets the same functionality in the end with a lot less maintenance issues. You can also say the same for how many JITs and transpilers to C there are in Python libraries vs the single Julia JIT. The real danger of the Python monoliths is that when something as simple as a neural network package starts to include a JIT, a GPU compiler, and automatic differentiation library, and it's all written in C++, it gets really hard to attract developers because the code base is so hard to understand. This means that instead of getting new developers and more maintenance, people just spawn new libraries all of the time in Python, starting from scratch to write a new JIT, new GPU kernels, etc. I just cannot see how that's a good thing.
outnmbout 7y ago
>> Not being 100% interoperable with python make Julia doomed. > Than means 10 packages in Julia can quickly do more than 50 packages in other language. Maybe you guys would like to compare your text editors now?

coldtea 7y ago

>You can use Python, C and Fortran code from Julia. More importantly package development is much faster in Julia than in Python. Which means the speed of which packages get added to Julia is much faster than Python. That's because Python already has tons, while Julia lacks tons. Are the new ones added to Julia as good or better though? >That means 10 packages in Julia can quickly do more than 50 packages in other language. Say somebody makes a GPU processing package and somebody else makes a Machine learning package. They don't know about it each other. Yet with Julia we frequently see that these guy can use each others package. The ML package can with little effort run on a GPU by including a GPU package even if it was never designed for it. This sounds like magic bullet / handwaving. Perhaps Julia's multiple dispatch helps here (?), but why would the above be the case and wouldn't be achievable in other existing languages as is?

StefanKarpinski 7y ago
> Perhaps Julia's multiple dispatch helps here (?), but why would the above be the case and wouldn't be achievable in other existing languages as is? Yes, ubiquitous, zero-overhead multiple dispatch is the reason, as explained in depth here: https://youtu.be/kc9HwsxE1OY https://youtu.be/kc9HwsxE1OY
- coldtea 7y ago
  Thanks, checking!
ChrisRackauckas 7y ago
>This sounds like magic bullet / handwaving. It's not handwaving when it already exists. CUDAnative.jl gives native compilation of Julia code to GPUs, which allows CuArrays.jl to do efficient loop fusion among other tricks. This is then enough for DifferentialEquations.jl, Flux.jl (the big neural net library, think PyTorch), CLIMA (a MIT-CalTech next-gen climate model), etc. (too many packages to list) to all utilize the same underlying GPU framework. It's as if someone got rid of the GPU functionality of Numba, PyTorch, TensorFlow, etc. and just made one good enough Python library for everyone to share. As you can imagine, that reduces the amount of work to do package development but gets the same functionality in the end with a lot less maintenance issues. You can also say the same for how many JITs and transpilers to C there are in Python libraries vs the single Julia JIT. The real danger of the Python monoliths is that when something as simple as a neural network package starts to include a JIT, a GPU compiler, and automatic differentiation library, and it's all written in C++, it gets really hard to attract developers because the code base is so hard to understand. This means that instead of getting new developers and more maintenance, people just spawn new libraries all of the time in Python, starting from scratch to write a new JIT, new GPU kernels, etc. I just cannot see how that's a good thing.

outnmbout 7y ago

>> Not being 100% interoperable with python make Julia doomed. > Than means 10 packages in Julia can quickly do more than 50 packages in other language. Maybe you guys would like to compare your text editors now?