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

Why We Use Julia, 10 Years Later

julialang.org

Post reply on HN
Print view View original

51–60 of 144 posts

Re: Why We Use Julia, 10 Years Later

#51

Post by elcritch »

sinab wrote: post #47
tkuraku wrote: post #46

I really like julia. For certain problems matlab and python are unworkable. People complain about time to first plot, but that doesn't matter too much to me. The problem is that plotting in general is just not as robust or user friendly as Matlab or matplotlib in python. You can call matplotlib, But it feels like a second class citizen. Plotting just needs to be better with a clear preferred method. There are tons of…

For which kinds of problems are matlab and python unworkable?

Statistical bootstrapping techniques are the ones I ran into.

Re: Why We Use Julia, 10 Years Later

#52

Post by CornCobs »

garyrob wrote: post #30
wiz21c wrote: post #5

I'm currently writing code with it. The language is really (really) nice to work with. - But the REPL lacks the ability to redefine structs on the go (which I can understand as it'd be tough to do, or simply not possible). But that, combined with the slow start up time makes life a bit harder than it should. Fortunately, one doesn't redefine its structs every day. - There are also lots of libraries but the quality of…

" I mean, faster than r or Python (for which I could write fast code but that'd mean I'd have to change the way it is written)" You might benefit from numba. I've used it to speed my Python up enormously and completely painlessly just by adding decorators to critical functions. It's why I'm not considering moving to Julia.

Is it actually completely painless?

YMMV, but for me I found that there were many unsupported parts of Numpy I had to work around which meant I was effectively doing a full rewrite.

Especially assignments using boolean masks and working with multi-dimensional arrays in general is really tough

Re: Why We Use Julia, 10 Years Later

#53

Post by LetThereBeLight »

tkuraku wrote: post #46

I really like julia. For certain problems matlab and python are unworkable. People complain about time to first plot, but that doesn't matter too much to me. The problem is that plotting in general is just not as robust or user friendly as Matlab or matplotlib in python. You can call matplotlib, But it feels like a second class citizen. Plotting just needs to be better with a clear preferred method. There are tons of…

I agree, there are a variety of plotting library options in Julia but they aren't nearly as developed/robust as matlab (e.g. quiver plots). There are a number of plotting functions that have completely changed how they work across versions and generally lack descriptive documentation. There have been several occasions where I had to give up and export my data into matlab to generate a plot. I also think the image analysis libraries are underdeveloped.

Re: Why We Use Julia, 10 Years Later

#54

Post by adgjlsfhk1 »

havermeyer wrote: post #50
wiz21c wrote: post #5

I'm currently writing code with it. The language is really (really) nice to work with. - But the REPL lacks the ability to redefine structs on the go (which I can understand as it'd be tough to do, or simply not possible). But that, combined with the slow start up time makes life a bit harder than it should. Fortunately, one doesn't redefine its structs every day. - There are also lots of libraries but the quality of…

The C API for Julia also has almost no documentation. There is a getting started guide, which is great, but if you want to do anything more advanced (e.g. creating structs like in your example), you'll end up reading the source code to try to puzzle through which functions to use in julia.h. There's also an apparent limitation that whichever thread initializes Julia is the only one that can later eval code, which was…

The good news is that you don't need the C api nearly as much because you don't have to call out to C whenever you want performance. Also, the extent to which the python C api is documented has actually been a major problem for them since it has effectively frozen a ton of python's implementation in majorly detrimental ways (eg the GIL)

Re: Why We Use Julia, 10 Years Later

#55

Post by baldfat »

garyrob wrote: post #30
wiz21c wrote: post #5

I'm currently writing code with it. The language is really (really) nice to work with. - But the REPL lacks the ability to redefine structs on the go (which I can understand as it'd be tough to do, or simply not possible). But that, combined with the slow start up time makes life a bit harder than it should. Fortunately, one doesn't redefine its structs every day. - There are also lots of libraries but the quality of…

" I mean, faster than r or Python (for which I could write fast code but that'd mean I'd have to change the way it is written)" You might benefit from numba. I've used it to speed my Python up enormously and completely painlessly just by adding decorators to critical functions. It's why I'm not considering moving to Julia.

There are so many ways to write R that can actually be very fast. R is a very different language as a whole and it has addressed a lot of problems these last 10 years. I might be biased but I really do like the functional side of R and how logical the libraries from Hadley Wickham have been designed.

Python still doesn't feel like a natural fix for data science work. I am guessing it is more bias opinion but why based on 0 for this domain????

Re: Why We Use Julia, 10 Years Later

#56

Post by pbohun »

Julia is a very pleasant language to work with. The type system, multiple dispatch, and package system all make it into top 10 of design.

The only change I would recommend is to have a way to distinguish between creating and setting a variable. Without this distinction it is very easy (especially for someone with dyslexia) to misspell a variable and accidentally create a new one instead of assigning a value. Something like this would be nice:

var x = 5

or even something like Go:

x := 5

Re: Why We Use Julia, 10 Years Later

#57

Post by silverlyra »

zem wrote: post #39
socialdemocrat wrote: post #7

I cannot remember exactly when I discovered Julia or where. But I remember I got intrigued early on and wrote a blogpost about 9 years ago on Tumblr, which is still there comparing Julia to Ruby of all things: https://assoc.tumblr.com/post/70484963303/getting-comfortabl... The normal thing today is comparing Julia to R, Matlab and Python. But my intro to Julia was actually trying to convert code examples in the O'Rei…

why ruby "of all things"? i've only dabbled a little in julia, but it definitely has a lot of the things i like about ruby, mixed in with a lot of the things i like about racket.

Not OP but I read the next sentence as explaining that sentiment:

> The normal thing today is comparing Julia to R, Matlab and Python.

I'm on the same page as you, though. I've never written R or any Matlab, but when Julia was still new, I remember seeing an example that it was a language that didn't use S-expressions, yet had as potent of macro and meta-programming abilities as if it did. Seemed like it'd be wonderful to work in.

Re: Why We Use Julia, 10 Years Later

#58

Post by tkuraku »

sinab wrote: post #47
tkuraku wrote: post #46

I really like julia. For certain problems matlab and python are unworkable. People complain about time to first plot, but that doesn't matter too much to me. The problem is that plotting in general is just not as robust or user friendly as Matlab or matplotlib in python. You can call matplotlib, But it feels like a second class citizen. Plotting just needs to be better with a clear preferred method. There are tons of…

For which kinds of problems are matlab and python unworkable?

Optimization type problems. Also anything with loops that isn't easily vectorizable.

Re: Why We Use Julia, 10 Years Later

#59

Post by tkuraku »

garyrob wrote: post #30
wiz21c wrote: post #5

I'm currently writing code with it. The language is really (really) nice to work with. - But the REPL lacks the ability to redefine structs on the go (which I can understand as it'd be tough to do, or simply not possible). But that, combined with the slow start up time makes life a bit harder than it should. Fortunately, one doesn't redefine its structs every day. - There are also lots of libraries but the quality of…

" I mean, faster than r or Python (for which I could write fast code but that'd mean I'd have to change the way it is written)" You might benefit from numba. I've used it to speed my Python up enormously and completely painlessly just by adding decorators to critical functions. It's why I'm not considering moving to Julia.

Numba is awesome. It solves a lot of problems. Julia is like numba but you are able to use any libraries inside the loops. Think FFT, scipy, etc

Re: Why We Use Julia, 10 Years Later

#60

Post by garyrob »

CornCobs wrote: post #52
garyrob wrote: post #30

Earlier quoted context omitted.

" I mean, faster than r or Python (for which I could write fast code but that'd mean I'd have to change the way it is written)" You might benefit from numba. I've used it to speed my Python up enormously and completely painlessly just by adding decorators to critical functions. It's why I'm not considering moving to Julia.

Is it actually completely painless? YMMV, but for me I found that there were many unsupported parts of Numpy I had to work around which meant I was effectively doing a full rewrite. Especially assignments using boolean masks and working with multi-dimensional arrays in general is really tough

It just happened wasn't using Numpy except in the most basic possible ways. I had hand-written algorithms in python. That's where it shines. So, yes YMMV! It worked really well for me.
Post reply on HN