6 ms·

I'm really rooting for Julia to improve its ML ecosystem. Julia is a JIT-compiled language that has the potential to become the all-encompassing solution for AI

I'm really rooting for Julia to improve its ML ecosystem. Julia is a JIT-compiled language that has the potential to become the all-encompassing solution for AI/ML/Data Science. I think their motto was "Walk like Python, Run like C." This could help to implement all their libraries in Julia instead of what is happening in Python (e.g., PyTorch is written in C++). I want to be clear; Python will be the go-to language for AI/ML for the foreseeable future. And It's a great language, but Julia is a breath of fresh air.

enriquto 5y ago
> I think their motto was "Walk like Python, Run like C." I was also seduced by the concept of "octave, but with fast loops". This is really all that was needed. But I'm a bit disenchanted by the "advanced" additional features of Julia that add (unnecessary, in my view) complexity to the language. All that multiple-dispatch stuff, all those arbitrary types. I would love a compilation option that forced everything to be of the same type (a multi-dimensional array of numbers), and then it could really run like C, including compilation time.
- jstx1 5y ago
  Multiple dispatch is the main feature that makes everything else possible, not some additional feature that spoils things.
  - enriquto 5y ago
    I disagree with the word "everything" in your sentence. If all you want to do is numeric computations, you just want a sort of "modern fortran" that compiles and runs fast. No need for multiple dispatch here. Julia almost is this language, if it wasn't for the multiple dispatch thing whose only effect is to slow the compilation (when all you have is the same numeric type).
    - deleted 5y ago
      [deleted]
    - jhgb 5y ago
      > you just want a sort of "modern fortran" that compiles and runs fast Well...if you want Fortran, you know where to find it? Fortran still compiles and runs fast. Just use Fortran, then? It's a perfectly fine language. > if it wasn't for the multiple dispatch thing whose only effect is to slow the compilation (when all you have is the same numeric type). How does multiple dispatch in Julia slow things down when in Julia (unlike, say, in CLOS) it's basically restricted to generating monomorphic functions on demand? If "all you have is the same numeric type" then only one version of a polymorphic function will get generated and that's as fast as generating code, say, for an equivalent monomorphic function in C.
      - sharikous 5y ago
        Exactly. Fortran is fine and it has many advantages over Julia. It's not only the legacy code. For one Julia needs an humongous runtime. I can see in the future a compiler from a Fortran number crunching routine to a webassembly SIMD-ready kernel. Julia in the browser is still a failure and not for a lack of effort. Fortran is much simpler to do. I tried to work in Julia and it has a whole lot of hidden annoying things, undocumented nuances, etc... I find myself wishing for a language between bare-bones Fortran and big-but-buggy Julia but I know it won't happen since the community is too small
        jhgb 5y ago
        > For one Julia needs an humongous runtime. To be fair, Julia needs that runtime precisely to generate compiled versions of polymorphic functions at run time, so as not to cause a combinatorial explosion of n-ary functions. Also, for interactivity, which includes adding new functions at run time. These are problems that Fortran isn't even trying to solve, so it's not quite fair to complain that Fortran doesn't require a runtime that solves them. But of course there seems to be a market for a way to generate a static binary for a Julia program under a closed world assumption that wouldn't require embedding a complete JIT compiler into the process.
- socialdemocrat 5y ago
  Huh? Multiple-dispatch is what makes the language really shine. I miss it in pretty much every other language I use. I am utterly puzzled by how you can see this killer feature as a downsides. Single dispatch is an arbitrary restriction which should not exist. It only exists in most languages as a performance optimization because until Julia came along nobody could do multiple dispatch fast.
  - enriquto 5y ago
    > I am utterly puzzled by how you can see this killer feature as a downsides. It depends on the usage that you make of the language. I don't use Julia as a general-purpose programming language, but only for doing numeric computations. For that usage, the multiple dispatch feature is not necessary (all my variables are matrices of the same numeric type), and indeed it has downsides. For example, the infamous "time to first plot" is so large in Julia precisely due to the need to support multiple dispatch. If this benchmark is becoming faster is only due to a huge and complex effort in optimization. I would prefer if this effort could be spent in improving support for sparse matrices, for example. I acknowledge that "time to first plot" may be a useless benchmark for many, even for most, people. But you can also acknowledge that multiple dispatch is a useless feature for a few graybeards like me, for whom multiple dispatch is the main reason why Julia feels slow. Indeed, when you use Julia as an interpreted language (e.g., write a Julia script), execution is very slow due to the complexities introduced by multiple dispatch, that force essentially to recompile all libraries upon each execution of my tiny script.
    - adgjlsfhk1 5y ago
      Multiple dispatch isn't useless for you. It's the reason the numerics are so good even when everything is the same type. Multiple dispatch makes it way easier to write generic code which means that all the libraries you use are about 10x easier to write.
      - ChrisRackauckas 5y ago
        Their point is that they're not trying to write generic code. In that case, Julia should act like an interactive Fortran, which would be nice, but then it needs to fix latency and binary building for the "this is pure Float64 and we know it" case. The only gain one really gets here is that type inference means you can write a bit simpler code, but that's not a huge win. That's a valid criticism that should hopefully be addressed soon, with https://github.com/JuliaLang/julia/pull/41936 https://github.com/JuliaLang/julia/pull/41936 being one of the biggest steps to getting there, along with the more precompilation stuff.
- simonbyrne 5y ago
  If that's seriously what you're looking for, you should really consider Fortran. There is a reason it is still very widely used in scientific domains.
xaxaxb 5y ago
Add me to the club. I'm rooting for Julia for ML as well.
hiptobecubic 5y ago
Why is it a problem that python calls out to other languages as needed? It's not like it's obvious while you're using the library and the result can be, in fact, very fast. The main benefit I can think of is that Julia could theoretically do whole-program optimization, but it doesn't and it doesn't model side effects so even if it wanted to it would be quite limited.
- amkkma 5y ago
  There are innumerable benefits that the compiler gets from being able to see into functions. Codegen, AD, fusion, inlining, user defined arrays and element types being first class etc
- socialdemocrat 5y ago
  It matters to package developers. If you can develop packages in Julia rather than in C++ you can move much faster. Also in Julia users of a package can much more easily contribute. A Python programmer cannot easily jump in an fix or add things to a package mostly written in C++. Also writing packages in C++ creates a fair amount of friction. Combining packages becomes easier. The ML world in Julia allows a lot more code sharing while in Python PyTorch and TensorFlow are large monoliths. E.g. different ML packages in Julia can use the same library of activation functions. Each ML library is not a completely different island of functionality.
- snicker7 5y ago
  There a lot of cases in scientific computing where using "glue code" of any sort can kill performance. You miss compile-time optimizations that can perform whole-program analysis. As a result, despite Julia being very FFI-friendly, the Julia community is trying to move towards a "pure Julia" ecosystem. Sometimes this attitude makes sense (Julia-native BLAS), other times not (Julia has no HTTP/2 packages).
- sundarurfriend 5y ago
  One benefit from the user's side that I've experienced is that, when debugging, I can go as far into the call stack as I want or need, using the same tools I use to inspect my own Julia code and read things in the same language throughout - no jarring context switch. This helps significantly with building a complete mental model of what you're debugging, and with ruling out a whole class of potential issues at or beyond the language border.

enriquto 5y ago

> I think their motto was "Walk like Python, Run like C." I was also seduced by the concept of "octave, but with fast loops". This is really all that was needed. But I'm a bit disenchanted by the "advanced" additional features of Julia that add (unnecessary, in my view) complexity to the language. All that multiple-dispatch stuff, all those arbitrary types. I would love a compilation option that forced everything to be of the same type (a multi-dimensional array of numbers), and then it could really run like C, including compilation time.

jstx1 5y ago
Multiple dispatch is the main feature that makes everything else possible, not some additional feature that spoils things.
- enriquto 5y ago
  I disagree with the word "everything" in your sentence. If all you want to do is numeric computations, you just want a sort of "modern fortran" that compiles and runs fast. No need for multiple dispatch here. Julia almost is this language, if it wasn't for the multiple dispatch thing whose only effect is to slow the compilation (when all you have is the same numeric type).
  - deleted 5y ago
    [deleted]
  - jhgb 5y ago
    > you just want a sort of "modern fortran" that compiles and runs fast Well...if you want Fortran, you know where to find it? Fortran still compiles and runs fast. Just use Fortran, then? It's a perfectly fine language. > if it wasn't for the multiple dispatch thing whose only effect is to slow the compilation (when all you have is the same numeric type). How does multiple dispatch in Julia slow things down when in Julia (unlike, say, in CLOS) it's basically restricted to generating monomorphic functions on demand? If "all you have is the same numeric type" then only one version of a polymorphic function will get generated and that's as fast as generating code, say, for an equivalent monomorphic function in C.
    - sharikous 5y ago
      Exactly. Fortran is fine and it has many advantages over Julia. It's not only the legacy code. For one Julia needs an humongous runtime. I can see in the future a compiler from a Fortran number crunching routine to a webassembly SIMD-ready kernel. Julia in the browser is still a failure and not for a lack of effort. Fortran is much simpler to do. I tried to work in Julia and it has a whole lot of hidden annoying things, undocumented nuances, etc... I find myself wishing for a language between bare-bones Fortran and big-but-buggy Julia but I know it won't happen since the community is too small
      - jhgb 5y ago
        > For one Julia needs an humongous runtime. To be fair, Julia needs that runtime precisely to generate compiled versions of polymorphic functions at run time, so as not to cause a combinatorial explosion of n-ary functions. Also, for interactivity, which includes adding new functions at run time. These are problems that Fortran isn't even trying to solve, so it's not quite fair to complain that Fortran doesn't require a runtime that solves them. But of course there seems to be a market for a way to generate a static binary for a Julia program under a closed world assumption that wouldn't require embedding a complete JIT compiler into the process.
socialdemocrat 5y ago
Huh? Multiple-dispatch is what makes the language really shine. I miss it in pretty much every other language I use. I am utterly puzzled by how you can see this killer feature as a downsides. Single dispatch is an arbitrary restriction which should not exist. It only exists in most languages as a performance optimization because until Julia came along nobody could do multiple dispatch fast.
- enriquto 5y ago
  > I am utterly puzzled by how you can see this killer feature as a downsides. It depends on the usage that you make of the language. I don't use Julia as a general-purpose programming language, but only for doing numeric computations. For that usage, the multiple dispatch feature is not necessary (all my variables are matrices of the same numeric type), and indeed it has downsides. For example, the infamous "time to first plot" is so large in Julia precisely due to the need to support multiple dispatch. If this benchmark is becoming faster is only due to a huge and complex effort in optimization. I would prefer if this effort could be spent in improving support for sparse matrices, for example. I acknowledge that "time to first plot" may be a useless benchmark for many, even for most, people. But you can also acknowledge that multiple dispatch is a useless feature for a few graybeards like me, for whom multiple dispatch is the main reason why Julia feels slow. Indeed, when you use Julia as an interpreted language (e.g., write a Julia script), execution is very slow due to the complexities introduced by multiple dispatch, that force essentially to recompile all libraries upon each execution of my tiny script.
  - adgjlsfhk1 5y ago
    Multiple dispatch isn't useless for you. It's the reason the numerics are so good even when everything is the same type. Multiple dispatch makes it way easier to write generic code which means that all the libraries you use are about 10x easier to write.
    - ChrisRackauckas 5y ago
      Their point is that they're not trying to write generic code. In that case, Julia should act like an interactive Fortran, which would be nice, but then it needs to fix latency and binary building for the "this is pure Float64 and we know it" case. The only gain one really gets here is that type inference means you can write a bit simpler code, but that's not a huge win. That's a valid criticism that should hopefully be addressed soon, with https://github.com/JuliaLang/julia/pull/41936 https://github.com/JuliaLang/julia/pull/41936 being one of the biggest steps to getting there, along with the more precompilation stuff.
simonbyrne 5y ago
If that's seriously what you're looking for, you should really consider Fortran. There is a reason it is still very widely used in scientific domains.

xaxaxb 5y ago

Add me to the club. I'm rooting for Julia for ML as well.

hiptobecubic 5y ago

Why is it a problem that python calls out to other languages as needed? It's not like it's obvious while you're using the library and the result can be, in fact, very fast. The main benefit I can think of is that Julia could theoretically do whole-program optimization, but it doesn't and it doesn't model side effects so even if it wanted to it would be quite limited.

amkkma 5y ago
There are innumerable benefits that the compiler gets from being able to see into functions. Codegen, AD, fusion, inlining, user defined arrays and element types being first class etc
socialdemocrat 5y ago
It matters to package developers. If you can develop packages in Julia rather than in C++ you can move much faster. Also in Julia users of a package can much more easily contribute. A Python programmer cannot easily jump in an fix or add things to a package mostly written in C++. Also writing packages in C++ creates a fair amount of friction. Combining packages becomes easier. The ML world in Julia allows a lot more code sharing while in Python PyTorch and TensorFlow are large monoliths. E.g. different ML packages in Julia can use the same library of activation functions. Each ML library is not a completely different island of functionality.
snicker7 5y ago
There a lot of cases in scientific computing where using "glue code" of any sort can kill performance. You miss compile-time optimizations that can perform whole-program analysis. As a result, despite Julia being very FFI-friendly, the Julia community is trying to move towards a "pure Julia" ecosystem. Sometimes this attitude makes sense (Julia-native BLAS), other times not (Julia has no HTTP/2 packages).
sundarurfriend 5y ago
One benefit from the user's side that I've experienced is that, when debugging, I can go as far into the call stack as I want or need, using the same tools I use to inspect my own Julia code and read things in the same language throughout - no jarring context switch. This helps significantly with building a complete mental model of what you're debugging, and with ruling out a whole class of potential issues at or beyond the language border.