6 ms·

Come on. It's not like Julia has a PyTorch / TF equivalent (Flux.jl doesn't even come close, sorry). Until then, you can't seriously say that Julia's ecosystem

Come on. It's not like Julia has a PyTorch / TF equivalent (Flux.jl doesn't even come close, sorry). Until then, you can't seriously say that Julia's ecosystem is rich. Once we start seeing DL/ML papers coming out with POC written in Julia we can call it a day.

eigenspace 6y ago
So you're disappointed that Mike Innes and a handful of other open source contributors haven't quite caught up yet with the efforts of Google and Facebook pouring billions of dollars into TensorFlow and PyTorch in pursuit of one of the most lucrative and hyped modern markets? Well, for that it depends on what you're into. For traditional, coding bootcamp machine learning, Flux.jl is still behind, but I'd point out that the only high performance, usable NeuralODE library is still built on Flux.jl and DifferentialEquations.jl as far as I understand and mostly consists of some import statements and a few function compositions / overloads. Someone already did deep learning on fully homomorphic encrypteded data using Flux.jl. Many 'niche', cutting edge things are still best done with Flux.jl because Flux is fundamentally more flexible than things like PyTorch and TensorFlow. It's using the entire programming language as a framework in a very generic way that PyTorch and Tensorflow can only ape by building ever more complex custom compilers and DSLs with ever diverging semantics from Python. If Flux.jl is an example of the Julia community's failures to compete I'd say we have very little to worry about, and I look forward to seeing what a well funded commercial entity could build in Julia with a few billion dollars.
- tastyminerals2 6y ago
  Consider me a curious client who trains and deploys production models on a weekly basis and considers Julia. Well even if I could rewrite our model in Julia how would I go with prod deployment and who would help me if I get stuck? For Tensorflow, I can use Java API and effortlessly plug in trained model into our Java stack. In case of PyTorch we can bring up a Python service with the same little effort just because Python has it all. When it comes to work, niche languages lose their ground once you start digging deeper and attempt to venture slightly outside their focus domain. They do not have dedicated teams or industrial money and will always lag behind. Look at DL4J, they have a whole company working on it for many years. Of course time will tell but considering the results so far I am not convinced that investing time into learning a new language will pay off. Especially considering Julia interop with C/C++.
  - dunefox 6y ago
    > Especially considering Julia interop with C/C++. Is the interop bad?
    - DNF2 6y ago
      As far as I'm aware, Julia interop with C/C++ is particularly excellent. So, maybe the poster can clarify?
    - deleted 6y ago
      [deleted]
    - tastyminerals2 6y ago
      Well, it's been 4 years so maybe it's better now: https://www.zverovich.net/2016/05/13/giving-up-on-julia.html https://www.zverovich.net/2016/05/13/giving-up-on-julia.html Well, running "Hello, World" still takes 0.3 ms :D
      - StefanKarpinski 6y ago
        That is truly the dumbest critique of Julia that's been published. So dumb I didn't bother refuting it at the time, but apparently people take it seriously? - Hello world is slow? Really? Yeah, it's not a hello-world-oriented programming language. - One-based indexing is questionable? Troll much? - Using `ccall` is unsafe? No kidding, there's no way to call a shared library that doesn't crash if you lie to it. - `@printf` sucks? Then don't use it. I never do. The `print` function works for 99% of cases. - Julia development is slowing down? Whiffed on that call. Regarding the C ffi point, you can use Clang.jl to generate correct bindings so that you don't have to read C header files. But note that if you want to call a function in C you need to look at and match its signature, so it's not all that onerous to have to do the same from Julia. Julia's C interop is so good that several other languages have copied it since it came out.
        tastyminerals2 6y ago
        Yeah, but how else would you judge about the language before spending months on learning it? Critique can be dumb like 1-based index for arrays or nitpicking on syntax. However, I tried Julia several years ago and start-up times was the reason I dropped it. Was it a dumb thing to do too? I was disappointed that a promise of being a dynamic language came with some "but"s. And if you have a lot of scripts that you need to run one-by-one, you don't notice the real speed of the language, all you notice is sluggishness.
amkkma 6y ago
You aren't making a fair comparison here. Flux is more generic, flexible and thus harder to build. Julia could have been there already if the small ML team w was working with TF type design goals. But they aren't, and therefore are ahead of TF/pytorch in many respects. Also not as much effort has gone into making this polished for standard deep learning stuff, but you can see the fruit in things like reusing the same code for ML on holomophically encrypted data, faster than pytorch/tf deep learning on graphs and 3d inputs, faster, easier composability with ODEs and prob programming etc.
- eigenspace 6y ago
  A more fair comparison is KNet.jl which is a very worthy competitor to things like TensorFlow or PyTorch with comparable speed and roughly equivalent flexibility. It's just not talked about as much by Julia people because what most Julia people really care about is the flexibility and composability of Flux, so they're willing to forgive it lagging a bit in raw performance (as long as they believe it'll catch up eventually).
pjmlp 6y ago
Neither does Python, PyTorch / TF equivalents are available to any language with FFI to C and C++ libraries, which are the languages they are actually written on.
- tastyminerals2 6y ago
  Interfacing with C++ is a lot of work and there is no language in existence that can do that effortlessly. Nim and D are the ones that come close. Julia's interoperability with C/C++ is quite poor according to feedback from more experienced Julia users.
  - pjmlp 6y ago
    .NET does it relativity easy given C++/CLI, and on the native side there is COM, UWP, C++/CX and C++/WinRT. So any language on Windows able to use COM/UWP, gets those Python libraries, sorry, C++ libraries. The effort to use Julia FFI to interoperate with them is hardly any different than using Python FFI, with the big difference that in what concerns Julia it would be possible to re-implement them in pure Julia, while the Python community keeps wondering about to write more FFI code to native libraries or finally start adopting PyPy.

eigenspace 6y ago

So you're disappointed that Mike Innes and a handful of other open source contributors haven't quite caught up yet with the efforts of Google and Facebook pouring billions of dollars into TensorFlow and PyTorch in pursuit of one of the most lucrative and hyped modern markets? Well, for that it depends on what you're into. For traditional, coding bootcamp machine learning, Flux.jl is still behind, but I'd point out that the only high performance, usable NeuralODE library is still built on Flux.jl and DifferentialEquations.jl as far as I understand and mostly consists of some import statements and a few function compositions / overloads. Someone already did deep learning on fully homomorphic encrypteded data using Flux.jl. Many 'niche', cutting edge things are still best done with Flux.jl because Flux is fundamentally more flexible than things like PyTorch and TensorFlow. It's using the entire programming language as a framework in a very generic way that PyTorch and Tensorflow can only ape by building ever more complex custom compilers and DSLs with ever diverging semantics from Python. If Flux.jl is an example of the Julia community's failures to compete I'd say we have very little to worry about, and I look forward to seeing what a well funded commercial entity could build in Julia with a few billion dollars.

tastyminerals2 6y ago
Consider me a curious client who trains and deploys production models on a weekly basis and considers Julia. Well even if I could rewrite our model in Julia how would I go with prod deployment and who would help me if I get stuck? For Tensorflow, I can use Java API and effortlessly plug in trained model into our Java stack. In case of PyTorch we can bring up a Python service with the same little effort just because Python has it all. When it comes to work, niche languages lose their ground once you start digging deeper and attempt to venture slightly outside their focus domain. They do not have dedicated teams or industrial money and will always lag behind. Look at DL4J, they have a whole company working on it for many years. Of course time will tell but considering the results so far I am not convinced that investing time into learning a new language will pay off. Especially considering Julia interop with C/C++.
- dunefox 6y ago
  > Especially considering Julia interop with C/C++. Is the interop bad?
  - DNF2 6y ago
    As far as I'm aware, Julia interop with C/C++ is particularly excellent. So, maybe the poster can clarify?
  - deleted 6y ago
    [deleted]
  - tastyminerals2 6y ago
    Well, it's been 4 years so maybe it's better now: https://www.zverovich.net/2016/05/13/giving-up-on-julia.html https://www.zverovich.net/2016/05/13/giving-up-on-julia.html Well, running "Hello, World" still takes 0.3 ms :D
    - StefanKarpinski 6y ago
      That is truly the dumbest critique of Julia that's been published. So dumb I didn't bother refuting it at the time, but apparently people take it seriously? - Hello world is slow? Really? Yeah, it's not a hello-world-oriented programming language. - One-based indexing is questionable? Troll much? - Using `ccall` is unsafe? No kidding, there's no way to call a shared library that doesn't crash if you lie to it. - `@printf` sucks? Then don't use it. I never do. The `print` function works for 99% of cases. - Julia development is slowing down? Whiffed on that call. Regarding the C ffi point, you can use Clang.jl to generate correct bindings so that you don't have to read C header files. But note that if you want to call a function in C you need to look at and match its signature, so it's not all that onerous to have to do the same from Julia. Julia's C interop is so good that several other languages have copied it since it came out.
      - tastyminerals2 6y ago
        Yeah, but how else would you judge about the language before spending months on learning it? Critique can be dumb like 1-based index for arrays or nitpicking on syntax. However, I tried Julia several years ago and start-up times was the reason I dropped it. Was it a dumb thing to do too? I was disappointed that a promise of being a dynamic language came with some "but"s. And if you have a lot of scripts that you need to run one-by-one, you don't notice the real speed of the language, all you notice is sluggishness.

amkkma 6y ago

You aren't making a fair comparison here. Flux is more generic, flexible and thus harder to build. Julia could have been there already if the small ML team w was working with TF type design goals. But they aren't, and therefore are ahead of TF/pytorch in many respects. Also not as much effort has gone into making this polished for standard deep learning stuff, but you can see the fruit in things like reusing the same code for ML on holomophically encrypted data, faster than pytorch/tf deep learning on graphs and 3d inputs, faster, easier composability with ODEs and prob programming etc.

eigenspace 6y ago
A more fair comparison is KNet.jl which is a very worthy competitor to things like TensorFlow or PyTorch with comparable speed and roughly equivalent flexibility. It's just not talked about as much by Julia people because what most Julia people really care about is the flexibility and composability of Flux, so they're willing to forgive it lagging a bit in raw performance (as long as they believe it'll catch up eventually).

pjmlp 6y ago

Neither does Python, PyTorch / TF equivalents are available to any language with FFI to C and C++ libraries, which are the languages they are actually written on.

tastyminerals2 6y ago
Interfacing with C++ is a lot of work and there is no language in existence that can do that effortlessly. Nim and D are the ones that come close. Julia's interoperability with C/C++ is quite poor according to feedback from more experienced Julia users.
- pjmlp 6y ago
  .NET does it relativity easy given C++/CLI, and on the native side there is COM, UWP, C++/CX and C++/WinRT. So any language on Windows able to use COM/UWP, gets those Python libraries, sorry, C++ libraries. The effort to use Julia FFI to interoperate with them is hardly any different than using Python FFI, with the big difference that in what concerns Julia it would be possible to re-implement them in pure Julia, while the Python community keeps wondering about to write more FFI code to native libraries or finally start adopting PyPy.