4 ms·

Is Julia a JIT compiler? How is Julia different than Pypy or even the JVM? There is also the new GraalVM in the landscape. I don't see the plus value in Julia

by antpls 8y ago

Is Julia a JIT compiler? How is Julia different than Pypy or even the JVM? There is also the new GraalVM in the landscape. I don't see the plus value in Julia compared to Python or Java. It will still be slower than C/C++, probably less portable, and all the legacy libraries have to be rewritten in Julia. If Julia is only a new syntax, to me Python is already very simple. If Julia is a JIT compiler, why not participate to already available compilers? Julia is still there, so I guess it adds value, but I don't know where to place that effort in the grand scheme of things.

myopicgoat 8y ago
Thsee questions pop up every time Julia comes on HN and have been answered time and again for example by Chris Rackauckas [1], at the end of the day there will always be pros and cons and people unwilling to change from languages they’re proficient at. Personally I’ve been using Julia for scientific computing for 4 years and I’m hooked. [1] https://thewinnower.com/papers/9323-i-like-julia-because-it-scales-and-is-productive-some-insights-from-a-julia-developer https://thewinnower.com/papers/9323-i-like-julia-because-it-...
ethelward 8y ago
> How is Julia different than Pypy Well, no GIL for a start, which is a pretty strong selling point when running on several dozen of cores at once. > I don't see the plus value in Julia compared to Python or Java I don't see how you can put Python and Java in the same bag. > It will still be slower than C/C++ Not that much https://news.ycombinator.com/item?id=17204750 https://news.ycombinator.com/item?id=17204750 > probably less portable Who cares? 99.99% of HPC are Linux clusters anyway. And Julia runs on macOS and Linux, that cover the overwhelming majority of the concerned users. > and all the legacy libraries have to be rewritten in Julia. https://docs.julialang.org/en/v0.6.0/manual/calling-c-and-fortran-code/ https://docs.julialang.org/en/v0.6.0/manual/calling-c-and-fo... > I don't know where to place that effort in the grand scheme of things. According to you interrogations, browsing their website would be a good start. https://julialang.org https://julialang.org
- antpls 8y ago
  Thank you for the detailed answer. Here's my feedback on some of the points : > I don't see how you can put Python and Java in the same bag. What I meant is that the trio Python/Java/C is ubiquitous for many people in both entreprises and scientific fields, from embedded to web servers. It allows for great reusability of codes and people's skills. > Who cares? 99.99% of HPC are Linux clusters anyway. And Julia runs on macOS and Linux, that cover the overwhelming majority of the concerned users. But will Julia be able to output the necessary instructions for the future hardware accelerators, which could be totally different architectures? I'm thinking of all the new neural networks cores, the DSP, fpgas, and heterogeneous computing from different rival vendors. It seems Julia is deeply dependant of LLVM. > and all the legacy libraries have to be rewritten in Julia. > https://docs.julialang.org/en/v0.6.0/manual/calling-c-and-fo.. https://docs.julialang.org/en/v0.6.0/manual/calling-c-and-fo.... If you have to reuse C and Fortran libraries, why not just use Python which can do the same, or even Lua, or Lisp. Python is already the defacto language to glue libraries together onto a higher level algorithm.
  - KenoFischer 8y ago
    > But will Julia be able to output the necessary instructions for the future hardware accelerators, which could be totally different architectures? I'm thinking of all the new neural networks cores, the DSP, fpgas, and heterogeneous computing from different rival vendors. It seems Julia is deeply dependant of LLVM. Yes. Watch HN in the next week or two for an announcement that may interest you ;).
    - ethelward 8y ago
      Oh gosh, you're making me impatient now :)
  - ethelward 8y ago
    > What I meant is that the trio Python/Java/C is ubiquitous for many people in both entreprises and scientific fields, from embedded to web servers. It allows for great reusability of codes and people's skills. That's true. But it's also Academia's role to try (and fail or succeed) at developing and evaluating new solutions; and in the case of Julia, I have to concede I'm pretty excited to see where they will be going. The solution of mixing the ‶glue″ and the ‶high performances″ languages in a single one while still letting people call upon older C ABI libs is a little revolution in this context. > If you have to reuse C and Fortran libraries, why not just use Python which can do the same, or even Lua, or Lisp. Python is already the defacto language to glue libraries together onto a higher level algorithm. Because Julia is far faster, and because no GIL. Of course, like in every other tech, what floats my boat doesn't necessarily floats your, so maybe for your usecase Python/Lisp/Lua/Ruby/... is better.
StefanKarpinski 8y ago
This question implicitly presumes that language design doesn't matter—that you can just hook a JIT up to any language syntax and semantics and presto... it’s as fast as C. But it doesn't work like that. You can't just take an arbitrary language and "rub some LLVM on it" and make if fast. The dozens of failed efforts to speed up Python and R with LLVM and other JITs over the decades proves that the source language matters. (PyPy is the only one with any real success, and they had to give up on CPython ecosystem compatibility.) It's Python and R semantics that are the problem and this can't be fixed with a JIT. Java is much better in terms of performance, of course, but still has issues. (The lack of value types is a big one, for example; being forced to go through a VM runtime is another problem at the highest levels of performance demands.) Julia can be seen as an experiment which proves that if you design a high-level dynamic language from the start to be compiled and run efficiently, then you can do much better than you can by bolting a JIT onto an existing slow dynamic language after the fact.

by antpls 8y ago

myopicgoat 8y ago

Thsee questions pop up every time Julia comes on HN and have been answered time and again for example by Chris Rackauckas [1], at the end of the day there will always be pros and cons and people unwilling to change from languages they’re proficient at. Personally I’ve been using Julia for scientific computing for 4 years and I’m hooked. [1] https://thewinnower.com/papers/9323-i-like-julia-because-it-scales-and-is-productive-some-insights-from-a-julia-developer https://thewinnower.com/papers/9323-i-like-julia-because-it-...

ethelward 8y ago

> How is Julia different than Pypy Well, no GIL for a start, which is a pretty strong selling point when running on several dozen of cores at once. > I don't see the plus value in Julia compared to Python or Java I don't see how you can put Python and Java in the same bag. > It will still be slower than C/C++ Not that much https://news.ycombinator.com/item?id=17204750 https://news.ycombinator.com/item?id=17204750 > probably less portable Who cares? 99.99% of HPC are Linux clusters anyway. And Julia runs on macOS and Linux, that cover the overwhelming majority of the concerned users. > and all the legacy libraries have to be rewritten in Julia. https://docs.julialang.org/en/v0.6.0/manual/calling-c-and-fortran-code/ https://docs.julialang.org/en/v0.6.0/manual/calling-c-and-fo... > I don't know where to place that effort in the grand scheme of things. According to you interrogations, browsing their website would be a good start. https://julialang.org https://julialang.org

antpls 8y ago
Thank you for the detailed answer. Here's my feedback on some of the points : > I don't see how you can put Python and Java in the same bag. What I meant is that the trio Python/Java/C is ubiquitous for many people in both entreprises and scientific fields, from embedded to web servers. It allows for great reusability of codes and people's skills. > Who cares? 99.99% of HPC are Linux clusters anyway. And Julia runs on macOS and Linux, that cover the overwhelming majority of the concerned users. But will Julia be able to output the necessary instructions for the future hardware accelerators, which could be totally different architectures? I'm thinking of all the new neural networks cores, the DSP, fpgas, and heterogeneous computing from different rival vendors. It seems Julia is deeply dependant of LLVM. > and all the legacy libraries have to be rewritten in Julia. > https://docs.julialang.org/en/v0.6.0/manual/calling-c-and-fo.. https://docs.julialang.org/en/v0.6.0/manual/calling-c-and-fo.... If you have to reuse C and Fortran libraries, why not just use Python which can do the same, or even Lua, or Lisp. Python is already the defacto language to glue libraries together onto a higher level algorithm.
- KenoFischer 8y ago
  > But will Julia be able to output the necessary instructions for the future hardware accelerators, which could be totally different architectures? I'm thinking of all the new neural networks cores, the DSP, fpgas, and heterogeneous computing from different rival vendors. It seems Julia is deeply dependant of LLVM. Yes. Watch HN in the next week or two for an announcement that may interest you ;).
  - ethelward 8y ago
    Oh gosh, you're making me impatient now :)
- ethelward 8y ago
  > What I meant is that the trio Python/Java/C is ubiquitous for many people in both entreprises and scientific fields, from embedded to web servers. It allows for great reusability of codes and people's skills. That's true. But it's also Academia's role to try (and fail or succeed) at developing and evaluating new solutions; and in the case of Julia, I have to concede I'm pretty excited to see where they will be going. The solution of mixing the ‶glue″ and the ‶high performances″ languages in a single one while still letting people call upon older C ABI libs is a little revolution in this context. > If you have to reuse C and Fortran libraries, why not just use Python which can do the same, or even Lua, or Lisp. Python is already the defacto language to glue libraries together onto a higher level algorithm. Because Julia is far faster, and because no GIL. Of course, like in every other tech, what floats my boat doesn't necessarily floats your, so maybe for your usecase Python/Lisp/Lua/Ruby/... is better.

StefanKarpinski 8y ago

This question implicitly presumes that language design doesn't matter—that you can just hook a JIT up to any language syntax and semantics and presto... it’s as fast as C. But it doesn't work like that. You can't just take an arbitrary language and "rub some LLVM on it" and make if fast. The dozens of failed efforts to speed up Python and R with LLVM and other JITs over the decades proves that the source language matters. (PyPy is the only one with any real success, and they had to give up on CPython ecosystem compatibility.) It's Python and R semantics that are the problem and this can't be fixed with a JIT. Java is much better in terms of performance, of course, but still has issues. (The lack of value types is a big one, for example; being forced to go through a VM runtime is another problem at the highest levels of performance demands.) Julia can be seen as an experiment which proves that if you design a high-level dynamic language from the start to be compiled and run efficiently, then you can do much better than you can by bolting a JIT onto an existing slow dynamic language after the fact.