4 ms·

Julia always seems to rank #1 or close to it when compared to other interpreted languages but I only ever see it used for research and math. Why doesn’t anyone

Julia always seems to rank #1 or close to it when compared to other interpreted languages but I only ever see it used for research and math. Why doesn’t anyone use it for anything else?

Narishma 5y ago
Its ridiculously large memory usage might be a reason.
- dunefox 5y ago
  Memory is cheap. Between large memory usage and slow code, I'd rather have the first. Also, that has never stopped Java from being used.
- fault1 5y ago
  a lot of it is stuff its runtime loads by default, like huge BLAS buffers, the llvm orc and such. I think there have been steps recently to make those optional recently. Julia was really optimized for "big iron"-styles of workloads, but that's less than ideal when you are not trying to just do linear algebra all day.
_dain_ 5y ago
I think founder effects. It started in the math and science community so that's where most of the library-writing energy has gone into.
ludamad 5y ago
I think it competes with R, which has a similar usage profile
g42gregory 5y ago
Lack of integration with other massive libraries that Python, Java and C++ have. Lack of books, tutorials and extensive knowledge bases that Python, Java and C++ have.
- NeutralForest 5y ago
  There's a big effort to make that happen though, with Julia interop https://github.com/JuliaInterop https://github.com/JuliaInterop
- adgjlsfhk1 5y ago
  Java doesn't integrate well with Julia, but Julia's interop with C++ and python are both pretty painless. pycall in particular is about as easy as you could imagine.
  - dunefox 5y ago
    Also there's https://github.com/JuliaInterop/RCall.jl https://github.com/JuliaInterop/RCall.jl for R interop.
harles 5y ago
Julia is incredibly slow to compile. Far worse than C++ last time I tried. For interactive notebooks, I found it’s common to have a single line take a couple minutes to compile - it’s simply not interactive in the way Python is, despite having good runtime performance once compiled. The deal breaker for me is that its compiler is JIT based whether you want it or not. Code will hang at runtime for multiple minutes as it compiles all the library dependencies and specializes them to the given data types.
- adgjlsfhk1 5y ago
  Do you have an example for minutes of compile time for a single line? Especially since 1.6 (march 2021), I haven't run into that (and I'm using Julia pretty much full-time).
  - hutzlibu 5y ago
    So the compile times gotten better, but still are quite slow in comparison?
    - adgjlsfhk1 5y ago
      In comparison to what? I've found that it's very responsive in a repl/notebook for interactive work (especially with Revise). It's not good for running short scripts, but if you have something that's doing some real work, the compilation often isn't a big deal.
    - fault1 5y ago
      Personally, I think interactive usage has improved quite a bit. I don't "feel" it that badly in 1.7. It was bad enough earlier in the 1.0 series that I stopped using it for a while (I used it before <1.0 as well). I think the problems were from: 1) llvm itself getting dramatically slower over time, before more focus upstream on compiler speed more recently: https://www.npopov.com/2020/05/10/Make-LLVM-fast-again.html https://www.npopov.com/2020/05/10/Make-LLVM-fast-again.html 2) different types of invalidations 3) less than ideal precompilation of packages I think all of it has been improved, and can certainly be improved further. That also includes improving the speed of its interpreter (vs the JIT), which exists but was never optimized for speed afaik.
Hasnep 5y ago
In addition to the other replies, the comparatively long startup time makes it unsuitable for short scripts, and with a few dependencies it becomes unsuitable for even medium length programs. The startup time is always coming down and there are ways to compile dependencies ahead of time though. The JIT compilation can be annoying for real-time applications too.
- dunefox 5y ago
  There's https://github.com/dmolina/DaemonMode.jl https://github.com/dmolina/DaemonMode.jl.
fault1 5y ago
These are what i'd say, as someone who has tinkered with it a lot but uses python/C++ for $day_job: - immature web/network services stack. For better or worse the lang seemed to focus on more number crunching throughput early than reliable distributed data processing, but the latter is a much larger market and what most enterprises care about. It's the difference between a lang only having Matlab or R ceiling vs python-like ceiling. - poor static compilation or static analysis story. this is what a lot of people needing to put code in production need. It's also standard expectation now with a lot of dynamic language code (python or js) that aims to be in production. - for certain types of realtime uses, more direct control of memory is doable, but you have to jump through hoops. Again, determinism is very important. - historically, compile times were quite horrid. part of this was llvm, part of it was julia. It's gotten way better in 1.6 and 1.7, but compilation results need to be cached more than just precompilation. however, all being said, I love the lang! There is a lot going for it especially how the package ecosystem works. There is also a lot of innovative projects.
- 77pt77 5y ago
  > poor static compilation or static analysis You're comparing it with python.
  - fault1 5y ago
    yes, and python has a large amount of analyzers: https://github.com/typeddjango/awesome-python-typing https://github.com/typeddjango/awesome-python-typing https://github.com/ethanhs/python-typecheckers https://github.com/ethanhs/python-typecheckers though i'd say they are worse than similar tooling in typescript/javascript. julia's tooling is relatively nascent.
    - adgjlsfhk1 5y ago
      Julia has @code_warntype for type checking and Jet.jl for static analysis (and snoopcompile/cthulu for the really advanced stuff). Is there anything those are missing?
    - 5y ago
open-source-ux 5y ago
During it's development Julia was heavily promoted as a language for scientific computing. Nowadays, the language is promoted as a general purpose language suitable for any task or domain. However, the perception that Julia is primarily for scientific computing remains strong among many developers. Only time will tell if that perception changes.

Julia always seems to rank #1 or close to it when compared to other interpreted languages but I only ever see it used for research and math. Why doesn’t anyone use it for anything else?

Narishma 5y ago

Its ridiculously large memory usage might be a reason.

dunefox 5y ago
Memory is cheap. Between large memory usage and slow code, I'd rather have the first. Also, that has never stopped Java from being used.
fault1 5y ago
a lot of it is stuff its runtime loads by default, like huge BLAS buffers, the llvm orc and such. I think there have been steps recently to make those optional recently. Julia was really optimized for "big iron"-styles of workloads, but that's less than ideal when you are not trying to just do linear algebra all day.

_dain_ 5y ago

I think founder effects. It started in the math and science community so that's where most of the library-writing energy has gone into.

ludamad 5y ago

I think it competes with R, which has a similar usage profile

g42gregory 5y ago

Lack of integration with other massive libraries that Python, Java and C++ have. Lack of books, tutorials and extensive knowledge bases that Python, Java and C++ have.

NeutralForest 5y ago
There's a big effort to make that happen though, with Julia interop https://github.com/JuliaInterop https://github.com/JuliaInterop
adgjlsfhk1 5y ago
Java doesn't integrate well with Julia, but Julia's interop with C++ and python are both pretty painless. pycall in particular is about as easy as you could imagine.
- dunefox 5y ago
  Also there's https://github.com/JuliaInterop/RCall.jl https://github.com/JuliaInterop/RCall.jl for R interop.

harles 5y ago

Julia is incredibly slow to compile. Far worse than C++ last time I tried. For interactive notebooks, I found it’s common to have a single line take a couple minutes to compile - it’s simply not interactive in the way Python is, despite having good runtime performance once compiled. The deal breaker for me is that its compiler is JIT based whether you want it or not. Code will hang at runtime for multiple minutes as it compiles all the library dependencies and specializes them to the given data types.

adgjlsfhk1 5y ago
Do you have an example for minutes of compile time for a single line? Especially since 1.6 (march 2021), I haven't run into that (and I'm using Julia pretty much full-time).
- hutzlibu 5y ago
  So the compile times gotten better, but still are quite slow in comparison?
  - adgjlsfhk1 5y ago
    In comparison to what? I've found that it's very responsive in a repl/notebook for interactive work (especially with Revise). It's not good for running short scripts, but if you have something that's doing some real work, the compilation often isn't a big deal.
  - fault1 5y ago
    Personally, I think interactive usage has improved quite a bit. I don't "feel" it that badly in 1.7. It was bad enough earlier in the 1.0 series that I stopped using it for a while (I used it before <1.0 as well). I think the problems were from: 1) llvm itself getting dramatically slower over time, before more focus upstream on compiler speed more recently: https://www.npopov.com/2020/05/10/Make-LLVM-fast-again.html https://www.npopov.com/2020/05/10/Make-LLVM-fast-again.html 2) different types of invalidations 3) less than ideal precompilation of packages I think all of it has been improved, and can certainly be improved further. That also includes improving the speed of its interpreter (vs the JIT), which exists but was never optimized for speed afaik.

Hasnep 5y ago

In addition to the other replies, the comparatively long startup time makes it unsuitable for short scripts, and with a few dependencies it becomes unsuitable for even medium length programs. The startup time is always coming down and there are ways to compile dependencies ahead of time though. The JIT compilation can be annoying for real-time applications too.

dunefox 5y ago
There's https://github.com/dmolina/DaemonMode.jl https://github.com/dmolina/DaemonMode.jl.

fault1 5y ago

These are what i'd say, as someone who has tinkered with it a lot but uses python/C++ for $day_job: - immature web/network services stack. For better or worse the lang seemed to focus on more number crunching throughput early than reliable distributed data processing, but the latter is a much larger market and what most enterprises care about. It's the difference between a lang only having Matlab or R ceiling vs python-like ceiling. - poor static compilation or static analysis story. this is what a lot of people needing to put code in production need. It's also standard expectation now with a lot of dynamic language code (python or js) that aims to be in production. - for certain types of realtime uses, more direct control of memory is doable, but you have to jump through hoops. Again, determinism is very important. - historically, compile times were quite horrid. part of this was llvm, part of it was julia. It's gotten way better in 1.6 and 1.7, but compilation results need to be cached more than just precompilation. however, all being said, I love the lang! There is a lot going for it especially how the package ecosystem works. There is also a lot of innovative projects.

77pt77 5y ago
> poor static compilation or static analysis You're comparing it with python.
- fault1 5y ago
  yes, and python has a large amount of analyzers: https://github.com/typeddjango/awesome-python-typing https://github.com/typeddjango/awesome-python-typing https://github.com/ethanhs/python-typecheckers https://github.com/ethanhs/python-typecheckers though i'd say they are worse than similar tooling in typescript/javascript. julia's tooling is relatively nascent.
  - adgjlsfhk1 5y ago
    Julia has @code_warntype for type checking and Jet.jl for static analysis (and snoopcompile/cthulu for the really advanced stuff). Is there anything those are missing?
  - 5y ago

open-source-ux 5y ago

During it's development Julia was heavily promoted as a language for scientific computing. Nowadays, the language is promoted as a general purpose language suitable for any task or domain. However, the perception that Julia is primarily for scientific computing remains strong among many developers. Only time will tell if that perception changes.