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

Why Julia

ucidatascienceinitiative.github.io

Post reply on HN
Print view View original

21–30 of 257 posts

Re: Why Julia

#21

Post by ritoune »

The main issue I encountered as a Julia user is that multiple dispatch doesn't scale very well.

When you start building out a project, it's easy to keep track and debug if multiple dispatch starts failing (i.e. type starts spreading everywhere and Julia slows to Python like speeds).

In medium-to-large projects, it becomes extremely cumbersome to manage this. It's doable, but adds a layer of complexity management to projects that simply doesn't exist in strictly typed or pure scripting languages.

Of course, you can just decide to explicitly type everything - but the issue here again is the lack of enforcement.

In a nutshell: Julia is great when you're a grad student working mostly by yourself on small scale projects! But not so great in prod.

And there's really no problem with that; that's who the language was designed for!

Re: Why Julia

#22

Post by ddragon »

alanfranzoni wrote: post #9

So... The answer is fundamentally "statically typed", right?

I think the answer is fundamentally: giving the compiler a lot of information at compile time so it can optimize the generated code for the runtime, be it explicitly by type annotations or implicitly by type inference. If the compiler is sure a variable will be a 32 bits int, it can translate to the same instructions that any language that is not dynamic could.

What Julia language does is give programmers powerful tools to encode types, behaviors and even code manipulation/generation tools that can be fully resolved in compile time, while still having a fully dynamic runtime.

Re: Why Julia

#23

Post by Datenstrom »

agumonkey wrote: post #16
Datenstrom wrote: post #8

I recently began learning Julia and initially everything was amazing, except for 1 based indexing but with everything else I could overlook that. Then I attempted building something medium sized and it all fell apart. I feel like it needs some serious work on tooling, the module system, packages, etc. Has anyone built something medium-large sized in Julia? Maybe I'm missing something. When I was trying to use modules…

out of curiosity, could you give more details about modules problems ?

I do not recall the exact issue anymore unfortunately, I abandoned the project because of it, but the general sentiment on the Julia discourse seemed to be just avoid them. This blog post seems to sum up my issues with modules and namespaces pretty well though:

http://luthaf.fr/julia-some-criticism.html

I think that these issues are generally acknowledged although I don't know if they will be addressed. Seems like major pain points for library development should have been addressed before 1.0.

Re: Why Julia

#24

Post by agumonkey »

enriquto wrote: post #19
agumonkey wrote: post #14

Earlier quoted context omitted.

I didn't find it slow, but: $ time julia -e 'print(1)' 1 real 0m0.438s user 0m0.300s sys 0m0.118s $ time python -c 'print(1)' 1 real 0m0.040s user 0m0.036s sys 0m0.003s it is slower.. That said, instanciating julia every step of a bash loop.. I think it requires a jvm mindset, warmup once and iterate inside rather than outside.

> I think it requires a jvm mindset, warmup once and iterate inside rather than outside. I do not have this mindset then. I prefer tools who are mindset oblivious. They are really useful! For example, imagine I have a collection of a few hundred images with their projection matrices (in text files). I want to crop them and apply a simple imagemagick operation (which is not available from inside julia). The elementary…

I guessed that it wasn't your habits but if you step outside that box a bit you'll realize that lifting up or down things inside loops is the most natural thing to do. And for you example (which may not be your real use or workflow) you could have two loops, independent or coupled through a queue so that the julia process is only started once.

Re: Why Julia

#25

Post by ChrisRackauckas »

Datenstrom wrote: post #23
agumonkey wrote: post #16

Earlier quoted context omitted.

out of curiosity, could you give more details about modules problems ?

I do not recall the exact issue anymore unfortunately, I abandoned the project because of it, but the general sentiment on the Julia discourse seemed to be just avoid them. This blog post seems to sum up my issues with modules and namespaces pretty well though: http://luthaf.fr/julia-some-criticism.html I think that these issues are generally acknowledged although I don't know if they will be addressed. Seems like ma…

A lot of this blog post is addressed by just using `import` instead of `using`... so it was actually just an issue of not reading the manual. It's like using `from package import *` and then complaining Python doesn't namespace properly.

Re: Why Julia

#26

Post by enriquto »

agumonkey wrote: post #24
enriquto wrote: post #19

Earlier quoted context omitted.

> I think it requires a jvm mindset, warmup once and iterate inside rather than outside. I do not have this mindset then. I prefer tools who are mindset oblivious. They are really useful! For example, imagine I have a collection of a few hundred images with their projection matrices (in text files). I want to crop them and apply a simple imagemagick operation (which is not available from inside julia). The elementary…

I guessed that it wasn't your habits but if you step outside that box a bit you'll realize that lifting up or down things inside loops is the most natural thing to do. And for you example (which may not be your real use or workflow) you could have two loops, independent or coupled through a queue so that the julia process is only started once.

Of course! Once I realize that after a few seconds only a dozen images have been processed I cut the loop, remember that the julia repl is dog slow, and then, rewrite the task in a different way. But I would prefer not to have to do that. Moreover, for more complicated examples, there may be data dependencies that make the loop commutation non trivial.

The slow startup time may be a minor inconvenience, I agree. But nonetheless it seems to be a case of sloppy engineering, as other scripting languages do not have this egregious problem. It sets a bad tone, and makes me wonder if there are other hidden monsters inside the interpreter, that may be solved by "you are holding it wrong" like this one.

Re: Why Julia

#27

Post by agumonkey »

Datenstrom wrote: post #23
agumonkey wrote: post #16

Earlier quoted context omitted.

out of curiosity, could you give more details about modules problems ?

I do not recall the exact issue anymore unfortunately, I abandoned the project because of it, but the general sentiment on the Julia discourse seemed to be just avoid them. This blog post seems to sum up my issues with modules and namespaces pretty well though: http://luthaf.fr/julia-some-criticism.html I think that these issues are generally acknowledged although I don't know if they will be addressed. Seems like ma…

fair enough, the article is from 2015 though; these weren't open research problems, I'd hope they've been fixed since.

Re: Why Julia

#28

Post by ethelward »

ritoune wrote: post #21

The main issue I encountered as a Julia user is that multiple dispatch doesn't scale very well. When you start building out a project, it's easy to keep track and debug if multiple dispatch starts failing (i.e. type starts spreading everywhere and Julia slows to Python like speeds). In medium-to-large projects, it becomes extremely cumbersome to manage this. It's doable, but adds a layer of complexity management to p…

> In a nutshell: Julia is great when you're a grad student working mostly by yourself on small scale projects! But not so great in prod.

Some people would disagree with that

https://juliacomputing.com/case-studies/celeste.html

Re: Why Julia

#29

Post by agumonkey »

enriquto wrote: post #26
agumonkey wrote: post #24

Earlier quoted context omitted.

I guessed that it wasn't your habits but if you step outside that box a bit you'll realize that lifting up or down things inside loops is the most natural thing to do. And for you example (which may not be your real use or workflow) you could have two loops, independent or coupled through a queue so that the julia process is only started once.

Of course! Once I realize that after a few seconds only a dozen images have been processed I cut the loop, remember that the julia repl is dog slow, and then, rewrite the task in a different way. But I would prefer not to have to do that. Moreover, for more complicated examples, there may be data dependencies that make the loop commutation non trivial. The slow startup time may be a minor inconvenience, I agree. But…

Yeah I get it, it's inconvenient. But I taking the jvm thing again, I think julia's value is outside of this way of doing things.

Out of curiosity I timed ocaml

    $ time echo 'let x = "1" in print_endline(x)' |  ocaml -stdin - 
    1
    
    real    0m0.045s
    user    0m0.039s
    sys     0m0.007s
I thought julia init time was due to type checking phase but ocaml seems to have no issue, even with non zero code:

     $ time echo 'let l = [1;2;3;4] in let m = List.map (fun x -> x*x) l in print_int(List.length(m))' |  ocaml -stdin - 
     4
     real    0m0.050s
     user    0m0.040s
     sys     0m0.011s
Sad, I liked a lot of Julia features..

ps: this hints at the init time being constant recompilation of its core https://www.reddit.com/r/Julia/comments/4c09m1/julia_045_sta... and they were thinking (2 years ago) of caching..

Re: Why Julia

#30

Post by objektif »

I tried to like Julia but after a while I realized there was absolutely no use case for me to choose Julia over other languages. It might be useful for new grads looking to learn a language though.
Post reply on HN