Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My Journey from R to Julia

drtomasaragon.github.io

Post reply on HN
Print view View original

101–110 of 120 posts

Re: My Journey from R to Julia

#101

Post by markkitti »

BrandonS113 wrote: post #90
derbOac wrote: post #78

Earlier quoted context omitted.

Yes, I use R, Julia, and Python from time to time depending on the case and my mood and they all have their advantages and disadvantages. R is more than fast enough for straightforward prototypical analyses where a lot of the code is calling C or something lower level and you're not introducing something "new" to the interpreter system. But if you want to do some unusual optimization there's going to be something tha…

I have been thinking the same and had similar timing experiences. As Julia is lower level than R/Python, there is a lot of annoying things to take care of that are not needed in R/Python. And then why not use, say Rust? Or just Rcpp in R. We just did a small test program in Rust that is called very often on the command line and takes a couple of seconds to run. Very happy with the experience. Same run speed as Julia,…

Julia 1.9, now in beta, implements native code caching. Precompiling a Julia package now creates a native shared library, a ".so", ".dylib", or ".dll" file. For some packages, this lowers load time considerably. It may some time before many packages take full advantage of this.

The promise of Julia is that you can have the high-level interface and the low-level code in the same language. The alternative would be coding the low level code in Rust or C and then creating bindings for Python or R.

For a while Julia made the most sense for long-running code that is that is executed almost as often as it is modified (e.g. scientific computing). In this situation Rust or C static compilation times become a hinderance. As ahead-of-time and static compilation features get added to Juliaz this scope will expand.

Re: My Journey from R to Julia

#102

Post by BrandonS113 »

markkitti wrote: post #101
BrandonS113 wrote: post #90

Earlier quoted context omitted.

I have been thinking the same and had similar timing experiences. As Julia is lower level than R/Python, there is a lot of annoying things to take care of that are not needed in R/Python. And then why not use, say Rust? Or just Rcpp in R. We just did a small test program in Rust that is called very often on the command line and takes a couple of seconds to run. Very happy with the experience. Same run speed as Julia,…

Julia 1.9, now in beta, implements native code caching. Precompiling a Julia package now creates a native shared library, a ".so", ".dylib", or ".dll" file. For some packages, this lowers load time considerably. It may some time before many packages take full advantage of this. The promise of Julia is that you can have the high-level interface and the low-level code in the same language. The alternative would be codi…

Yes I follow this. The load time keeps getting better. And am looking forward to 1.9.

I really don't want to come across as negative, Julia is a fantastic language, and my hope is that that it will continue its impressive improvement path.

But to follow form the thread's sentiment, I have the feeling Julia lives in an unstable equilibrium. It is lower level than R/Python but doesn't quite deliver the benefits of rust/c/fortran/c++. I find my colleagues gravitate to one of the 2 equilibria.

Maybe your last paragraph crystallizes it. If one lives in the REPL, Julia is wonderful. Not how I work. I prefer the command line. Have new data, run code on it. Data changes in real time, code not. My code may run millions of times on different operating systems and only infrequently change.

Re: My Journey from R to Julia

#103

Post by BrandonS113 »

DNF2 wrote: post #99
BrandonS113 wrote: post #73

Earlier quoted context omitted.

sure, for parameters par (what is optimized for), data vector x (typical length from 10 to 20), constants n and n2, a typical function is if((1 - par[3]^2)

I'm not that good at reading R. But if the Julia code is similar, then this code is type unstable, sometimes returning an Int, sometimes a Float. That harms performance. Generally, it looks like a function where Julia could have a significant performance advantage.

R looks pretty much the same as Julia here. Don't think its unstable. Its all float. Nlopt passes parameters as float, data is float. Can't see how it could return int.

But I'll take a second look at the julia version of it. We optimised R as much as possible. might have missed a julia trick. simd perhaps. Except we also run it on ARM

Re: My Journey from R to Julia

#104

Post by adenozine »

adgjlsfhk1 wrote: post #82
jpfr wrote: post #79

Earlier quoted context omitted.

I'm surpised. At JuliaCon ~6 months ago the message was that no 2.0 is in the works [1]. I.e. no backwards-incompatible changes to the language. I checked the usual places and did not find any information on 2.0 and an interface mechanism. Do you have a pointer? [1] https://youtu.be/N4h46_TCmGc?t=1656

No, he's just making stuff up.

Oh, well here's a post by Jeff Bezanson, since you've decided to just talk out of your ass...

https://discourse.julialang.org/t/what-dont-you-like-about-j...

Hope the uh... co-creator warrants enough merit as a source.

Re: My Journey from R to Julia

#105

Post by adgjlsfhk1 »

adenozine wrote: post #104
adgjlsfhk1 wrote: post #82

Earlier quoted context omitted.

No, he's just making stuff up.

Oh, well here's a post by Jeff Bezanson, since you've decided to just talk out of your ass... https://discourse.julialang.org/t/what-dont-you-like-about-j... Hope the uh... co-creator warrants enough merit as a source.

You misread (although it wasn't especially clearly phrased.

"Interfaces are a really common topic of discussion and I think at this point we’re determined to do something about it in julia 2.0 (if it requires breaking changes)."

This means we really want a solution for interfaces and if we had a good enough design for interfaces that would require 2.0, they are important enough that it could be worth breaking existing code (and releasing a 2.0 with interfaces). However there still isn't a plan for interfaces (breaking or non-breaking).

Re: My Journey from R to Julia

#106

Post by adenozine »

adgjlsfhk1 wrote: post #105
adenozine wrote: post #104

Earlier quoted context omitted.

Oh, well here's a post by Jeff Bezanson, since you've decided to just talk out of your ass... https://discourse.julialang.org/t/what-dont-you-like-about-j... Hope the uh... co-creator warrants enough merit as a source.

You misread (although it wasn't especially clearly phrased. "Interfaces are a really common topic of discussion and I think at this point we’re determined to do something about it in julia 2.0 (if it requires breaking changes)." This means we really want a solution for interfaces and if we had a good enough design for interfaces that would require 2.0, they are important enough that it could be worth breaking existin…

If we are to continue this conversation, I need it to be addressed that you falsely characterized my top level comment with “he’s making stuff up.”

Otherwise, further correction would be wasting my time.

Re: My Journey from R to Julia

#107

Post by DNF2 »

BrandonS113 wrote: post #103
DNF2 wrote: post #99

Earlier quoted context omitted.

I'm not that good at reading R. But if the Julia code is similar, then this code is type unstable, sometimes returning an Int, sometimes a Float. That harms performance. Generally, it looks like a function where Julia could have a significant performance advantage.

R looks pretty much the same as Julia here. Don't think its unstable. Its all float. Nlopt passes parameters as float, data is float. Can't see how it could return int. But I'll take a second look at the julia version of it. We optimised R as much as possible. might have missed a julia trick. simd perhaps. Except we also run it on ARM

Maybe it's all floats in R, but in Julia, `return 500` means an Int is returned. But it's really hard to determine whether the Julia code is unstable based only on the R code.

Re: My Journey from R to Julia

#108

Post by DNF2 »

BrandonS113 wrote: post #102
markkitti wrote: post #101

Earlier quoted context omitted.

Julia 1.9, now in beta, implements native code caching. Precompiling a Julia package now creates a native shared library, a ".so", ".dylib", or ".dll" file. For some packages, this lowers load time considerably. It may some time before many packages take full advantage of this. The promise of Julia is that you can have the high-level interface and the low-level code in the same language. The alternative would be codi…

Yes I follow this. The load time keeps getting better. And am looking forward to 1.9. I really don't want to come across as negative, Julia is a fantastic language, and my hope is that that it will continue its impressive improvement path. But to follow form the thread's sentiment, I have the feeling Julia lives in an unstable equilibrium. It is lower level than R/Python but doesn't quite deliver the benefits of rust…

In Julia you can go low-level, but there is no requirement. You can write purely high-level, generic, untyped code, with good performance. So I'm a bit reluctant to accept the claim that it's lower level.

What are the things where low-level code is required in Julia, but not in Python/R?

Re: My Journey from R to Julia

#109

Post by markkitti »

BrandonS113 wrote: post #102
markkitti wrote: post #101

Earlier quoted context omitted.

Julia 1.9, now in beta, implements native code caching. Precompiling a Julia package now creates a native shared library, a ".so", ".dylib", or ".dll" file. For some packages, this lowers load time considerably. It may some time before many packages take full advantage of this. The promise of Julia is that you can have the high-level interface and the low-level code in the same language. The alternative would be codi…

Yes I follow this. The load time keeps getting better. And am looking forward to 1.9. I really don't want to come across as negative, Julia is a fantastic language, and my hope is that that it will continue its impressive improvement path. But to follow form the thread's sentiment, I have the feeling Julia lives in an unstable equilibrium. It is lower level than R/Python but doesn't quite deliver the benefits of rust…

We already have some forward prototypes of being able to run Julia ahead-of-time compiled native code from the command line.

https://github.com/brenhinkeller/StaticTools.jl

I think what we'll end up with is a language that can be used in both a fully static mode and in a dynamic mode along with some possible mixing. We may yet get the benefits of a statically compiled language as the tooling continues to develop. I do not see anything inherent in the language that would prevent that from happening.

Re: My Journey from R to Julia

#110

Post by jpfr »

adenozine wrote: post #104
adgjlsfhk1 wrote: post #82

Earlier quoted context omitted.

No, he's just making stuff up.

Oh, well here's a post by Jeff Bezanson, since you've decided to just talk out of your ass... https://discourse.julialang.org/t/what-dont-you-like-about-j... Hope the uh... co-creator warrants enough merit as a source.

So the 2 year old post by Jeff on discourse says that breaking changes would have to go into an eventual 2.0.

Whereas in the 6 month old keynote the same Jeff says there is no plan for breaking changes and hence no 2.0 is planned.

So Julia will remain stable. And maybe we get interfaces (or rather traits) at some point in the 1.x release family.

Post reply on HN