6 ms·

As someone who has never run into performance problems with R, and also knows how to use Python - is there a good reason to learn Julia?

simonbyrne 8y ago
Obviously that question depends on your motivation, but one good reason is that it is a great way to learn how software actually works. R makes it very easy to see the underlying R code (you just type the function name), until you get to a ".Call" or ".Primitive": from that point, it is effectively a black box. But as most of Julia is written in Julia, you can easily inspect and understand how functions work, all the way down. Moreover, by using the @code_* macros, you can also inspect the various stages by which the code is transformed from high level Julia code down to the actual machine code which is running on your computer.
shele 8y ago
Think about it a moment, which answer would you prefer?
- altairiumblue 8y ago
  Regardless of the answer, I have plans to learn it simply out of curiosity. I'm just not yet convinced that there are any practical benefits to using Julia over the other languages.
  - ethelward 8y ago
    As you said yourself, you have no performances problem with R and Python, so I do not think you need to learn Julia. However, in fields dealing with larger datasets (e.g. genetics, astrophysics, ...), Python and R are real bottlenecks in data processing pipelines, and are thus often replaced by programs in C/C++/Java/etc. Having a language with the expressiveness and dynamism of Julia on the one hand, and performances in the same order of magnitude than C++ in the other hand is a huge plus.
    - johnisgood 8y ago
      Do they use Fortran in those fields?
      - ethelward 8y ago
        In astrophysics yes (although I only follow the fields through friends), quite a lot of linear algebra/physics reference libraries are in Fortran, and new programs are still being developed in the more modern versions of it. In Bioinformatics, not at all. Or at least in no direct way that I'm aware of. Sure, R packages indirectly call upon Fortran libraries (LAPACK et al.), but user facing programs are mostly, from my experience, written in C, C++, Java, Python & Perl.
  - shele 8y ago
    Great, the answer is then: You should give it a try, to a certain extend "Why Julia is nice" is easier experienced than explained.
celrod 8y ago
Multiple dispatch and meta programming are both wonderful, irrespective of speed benefits. For example, compare linear algebra syntax in Julia with those in R and Python. Plus, the flexibility of multiple dispatch applying equally well to any of your own types really makes it feel like you can do anything in Julia. Metaprogramming, writing code that writes code, can take a while to get used to. But is extremely powerful. A final point I will make is comparability of Julia code. If you want to for a Bayesian model or solve a differential equation in Julia, you can mix your own types and code and any generically written library code at will, and it will often just work. In R, you're not likely to find that; your Stan code can't call R functions you've written or those from your favorite libraries.
- sametmax 8y ago
  Multiple dispach and meta programming are available in python as well. Although duck typing is usually a better solution and it's not really a killer feature to data analysts anyway. Compared to python, i'd say julia has the reputation for being generally faster for things you can't use numpy with, and you can more easily scale multiple cpu or machines.
  - srean 8y ago
    By metaprogramming in Python, do you mean using decorators ? If so that's a far cry from metaprogramming
    - sametmax 8y ago
      Import hooks with access to the ast, full object introspection and metaclass are not too shaby. They are not that used though, too much magic and implicit processing are not promoted in the community.
      - srean 8y ago
        Not to shabby indeed ! Now have to check whats up with Hy.
  - 8y ago
e12e 8y ago
Ideally, Julia should give you the best of R (good, integrated data-types, -structures and functionality for statistics etc) and python (a sane, real programming language) - with the benefit of speed - and no/hardly any need to drop to/link to C libraries - "everything" is in Julia, and you can inspect the code "all the way down" (well, to a point - there's of course llvm at the bottom). Whether Julia is that for you right now probably depends a bit on your needs/use cases. Until Julia gains some form of aot compiler for static binaries - it's not quite an alternative to python imnho - you can't expect to run Julia scripts everywhere you can run python. Though this is similar to R. And there are of course much bigger ecosystems for python and R code/libraries than currently for Julia. Personally I think they've done a great job on the design/syntax of Julia - it's a fun language - and that might be the best reason to play with it?
- Cosi1125 8y ago
  > and python (a sane, real programming language) So... R is an unreal language then?
  - deleted 8y ago
    [deleted]
  - disgruntledphd2 8y ago
    Nah, it's just a re-implementation of S, which was really, really old and different from what people expect. R is wonderful (and has multiple dispatch, thank you very much), but it's definitely not as familiar to developer types as Python is. R has lots of weird quirks (a[1] vs a[[1]] vs a[1,]) and uses function based generic programming rather than object based generic programming. Because of the re-implementation of S, it has lots of odd quirks and multiple ways to do things, which Python tends to avoid. Python is definitely more consistent from a programming point of view, but R is a more cohesive system from an analytics point of view. But yeah, lots of people are hateRs (unfortunately).
    - kgwgk 8y ago
      > Nah, it's just a re-implementation of S, which was really, really old and different from what people expect. Was S "really, really old" when it was re-implemented in R? Gentleman and Ihaka first announced R in 1993 (26 years ago!). The development of S started in 1976 (i.e. 17 years before R was first released). R was a implementation of S3, "the New S language", which was a major rewrite done in 1988 (it was just five years old when R was announced!).
zzleeper 8y ago
Last week I compared a standard regression command across several statistical programs (R, Py, Stata, Matlab, Julia, etc) on a stupidly simple 10x5 matrix, and Julia took ages to run (this is on windows). Even loading the CSV file took seconds in Julia, hundreds of times slower than all of the other packages put together. I'm not sure if they just suck at Windows, but I was extremely dissapointed... :/
- krull10 8y ago
  The first time you run code in a REPL Julia will have to compile it. So starting a new REPL, and trying to solve a very small problem one time will currently be a terrible workflow for Julia (unless you don’t care that it may take a few seconds). If you had run your code again within the same REPL you’d see it runs substantially faster the second time. Likewise, if you had tried to process a large enough matrix or CSV that compilation time should be a minimal subset of the total computing time, and probably not noticeable. It isn’t a language limitation, just a tooling limitation. The startup times have been getting better as Julia develops, but there is still noticeable overhead the first time code gets run in a new REPL...
- jpfr 8y ago
  Probably it took ages for the first invocation. Because that is when the compiler has to produce native code. The compiled codes then is super fast. Just invoke it a second time (in the REPL) to see the difference.

simonbyrne 8y ago

Obviously that question depends on your motivation, but one good reason is that it is a great way to learn how software actually works. R makes it very easy to see the underlying R code (you just type the function name), until you get to a ".Call" or ".Primitive": from that point, it is effectively a black box. But as most of Julia is written in Julia, you can easily inspect and understand how functions work, all the way down. Moreover, by using the @code_* macros, you can also inspect the various stages by which the code is transformed from high level Julia code down to the actual machine code which is running on your computer.

shele 8y ago

Think about it a moment, which answer would you prefer?

altairiumblue 8y ago
Regardless of the answer, I have plans to learn it simply out of curiosity. I'm just not yet convinced that there are any practical benefits to using Julia over the other languages.
- ethelward 8y ago
  As you said yourself, you have no performances problem with R and Python, so I do not think you need to learn Julia. However, in fields dealing with larger datasets (e.g. genetics, astrophysics, ...), Python and R are real bottlenecks in data processing pipelines, and are thus often replaced by programs in C/C++/Java/etc. Having a language with the expressiveness and dynamism of Julia on the one hand, and performances in the same order of magnitude than C++ in the other hand is a huge plus.
  - johnisgood 8y ago
    Do they use Fortran in those fields?
    - ethelward 8y ago
      In astrophysics yes (although I only follow the fields through friends), quite a lot of linear algebra/physics reference libraries are in Fortran, and new programs are still being developed in the more modern versions of it. In Bioinformatics, not at all. Or at least in no direct way that I'm aware of. Sure, R packages indirectly call upon Fortran libraries (LAPACK et al.), but user facing programs are mostly, from my experience, written in C, C++, Java, Python & Perl.
- shele 8y ago
  Great, the answer is then: You should give it a try, to a certain extend "Why Julia is nice" is easier experienced than explained.

celrod 8y ago

Multiple dispatch and meta programming are both wonderful, irrespective of speed benefits. For example, compare linear algebra syntax in Julia with those in R and Python. Plus, the flexibility of multiple dispatch applying equally well to any of your own types really makes it feel like you can do anything in Julia. Metaprogramming, writing code that writes code, can take a while to get used to. But is extremely powerful. A final point I will make is comparability of Julia code. If you want to for a Bayesian model or solve a differential equation in Julia, you can mix your own types and code and any generically written library code at will, and it will often just work. In R, you're not likely to find that; your Stan code can't call R functions you've written or those from your favorite libraries.

sametmax 8y ago
Multiple dispach and meta programming are available in python as well. Although duck typing is usually a better solution and it's not really a killer feature to data analysts anyway. Compared to python, i'd say julia has the reputation for being generally faster for things you can't use numpy with, and you can more easily scale multiple cpu or machines.
- srean 8y ago
  By metaprogramming in Python, do you mean using decorators ? If so that's a far cry from metaprogramming
  - sametmax 8y ago
    Import hooks with access to the ast, full object introspection and metaclass are not too shaby. They are not that used though, too much magic and implicit processing are not promoted in the community.
    - srean 8y ago
      Not to shabby indeed ! Now have to check whats up with Hy.
- 8y ago

e12e 8y ago

Ideally, Julia should give you the best of R (good, integrated data-types, -structures and functionality for statistics etc) and python (a sane, real programming language) - with the benefit of speed - and no/hardly any need to drop to/link to C libraries - "everything" is in Julia, and you can inspect the code "all the way down" (well, to a point - there's of course llvm at the bottom). Whether Julia is that for you right now probably depends a bit on your needs/use cases. Until Julia gains some form of aot compiler for static binaries - it's not quite an alternative to python imnho - you can't expect to run Julia scripts everywhere you can run python. Though this is similar to R. And there are of course much bigger ecosystems for python and R code/libraries than currently for Julia. Personally I think they've done a great job on the design/syntax of Julia - it's a fun language - and that might be the best reason to play with it?

Cosi1125 8y ago
> and python (a sane, real programming language) So... R is an unreal language then?
- deleted 8y ago
  [deleted]
- disgruntledphd2 8y ago
  Nah, it's just a re-implementation of S, which was really, really old and different from what people expect. R is wonderful (and has multiple dispatch, thank you very much), but it's definitely not as familiar to developer types as Python is. R has lots of weird quirks (a[1] vs a[[1]] vs a[1,]) and uses function based generic programming rather than object based generic programming. Because of the re-implementation of S, it has lots of odd quirks and multiple ways to do things, which Python tends to avoid. Python is definitely more consistent from a programming point of view, but R is a more cohesive system from an analytics point of view. But yeah, lots of people are hateRs (unfortunately).
  - kgwgk 8y ago
    > Nah, it's just a re-implementation of S, which was really, really old and different from what people expect. Was S "really, really old" when it was re-implemented in R? Gentleman and Ihaka first announced R in 1993 (26 years ago!). The development of S started in 1976 (i.e. 17 years before R was first released). R was a implementation of S3, "the New S language", which was a major rewrite done in 1988 (it was just five years old when R was announced!).

zzleeper 8y ago

Last week I compared a standard regression command across several statistical programs (R, Py, Stata, Matlab, Julia, etc) on a stupidly simple 10x5 matrix, and Julia took ages to run (this is on windows). Even loading the CSV file took seconds in Julia, hundreds of times slower than all of the other packages put together. I'm not sure if they just suck at Windows, but I was extremely dissapointed... :/

krull10 8y ago
The first time you run code in a REPL Julia will have to compile it. So starting a new REPL, and trying to solve a very small problem one time will currently be a terrible workflow for Julia (unless you don’t care that it may take a few seconds). If you had run your code again within the same REPL you’d see it runs substantially faster the second time. Likewise, if you had tried to process a large enough matrix or CSV that compilation time should be a minimal subset of the total computing time, and probably not noticeable. It isn’t a language limitation, just a tooling limitation. The startup times have been getting better as Julia develops, but there is still noticeable overhead the first time code gets run in a new REPL...
jpfr 8y ago
Probably it took ages for the first invocation. Because that is when the compiler has to produce native code. The compiled codes then is super fast. Just invoke it a second time (in the REPL) to see the difference.