7 ms·

Going all in is precisely the point. The biggest selling point of Julia is that it's as easy to write as python if you don't care about performance, and if you

Going all in is precisely the point. The biggest selling point of Julia is that it's as easy to write as python if you don't care about performance, and if you do care about performance it's as fast as C++ if you can just follow some simple principles. This actually works in practice. For my day job I write the slow path exactly as I would python, and that's a really fast way to write code. If you want a slow language that can call fast code, you already have python.

jampekka 3y ago
Biggest selling point of Julia is that you're locked in to Julia if you use it? For me this is the biggest point for giving up on Julia. Julia has a lot going for it in the basic design and I was really excited about it in the beginning. But even after all these years the environment is sadly almost unusable if you want to do something saner than REPL/notebook. The TTFP is too damn high and I don't think it will ever be fixed.
- sertbdfgbnfgsd 3y ago
  > environment is sadly almost unusable if you want to do something saner than REPL/notebook I work in "one of those industries" where failure can easily cost millions in the space of minutes, and we use Julia almost exclusively. Unfortunately I can't give you details because of reasons, other than tell you you're very poorly informed. > you're locked in to Julia You're not "locked in" to Julia any more you're locked in to Python. Arguably less, as Julia can call C natively, Python can't. My point isn't that you can't interop, and it seems you're intentionally (?) equivocating on this point. Surely you didn't misinterpret what I wrote as "you can't iterop"? My point is that you can more benefits if you don't. Like I said, if you want a slow language that can call fast routines, why not just use Python.
  - jampekka 3y ago
    Python can call C natively. Also Python programs can be used as CLI tools interacting with practically any language. Julia programs in practice can't. But I know from experience that this debate will not go anywhere. It's is the same old refusal to see the problem: "you're using it wrong". Julia is dying and this is why it will die.
    - th0ma5 3y ago
      Yes, this is so true. There is a lot of wild attacking of the questioners of Julia.
  - ykonstant 3y ago
    >I work in "one of those industries" where failure can easily cost millions in the space of minutes, and we use Julia almost exclusively. Unfortunately I can't give you details because of reasons, other than tell you you're very poorly informed. I vaguely recall a post from an ex Julia dev who had raised some issues regarding correctness of computations in Julia; I am not very familiar with the situation, have these concerns been addressed? Edit: now that I recall better, I think the correctness concerns had to do with ambiguous composition of disparate components due to vague interfaces. I think this has to do with multiple dispatch in Julia, but I don't know details. I would love any info about this.
    - leephillips 3y ago
      Yes.
    - sertbdfgbnfgsd 3y ago
      > I think the correctness concerns had to do with ambiguous composition of disparate components due to vague interfaces. I think this has to do with multiple dispatch in Julia You'd have to be more specific. Currently ambiguous dispatch throws an exception. I don't think this is a recent change either.
    - lukego 3y ago
      My impression is that this comes down to expectations. You might have a function: foo(x,y) = x + y and multiple dispatch means you can call that with integers, or floats, or arrays, or GPU-resident arrays, or automatically-differentiating numbers, or symbolic algebra terms, or... Just because you can, does that mean you should? It depends...
      - kelipso 3y ago
        I think it was more like you have a function over an abstract type like: foo(x::Number) = x+1 And then someone else creates a new type thats a subtype of Number. And they run foo(x) and get errors or unexpected output. Problem is the new type they created doesn't follow the assumptions that foo expects. Throw multiple dispatch into the mix and it gets even harder.
  - amj7e 3y ago
    HFT? :D Which country are you in?
- sanderjd 3y ago
  What do you mean by TTFP? Is this like "time to first byte"? If so, what is the "P"? In any case, if the complaint is startup time, I do agree that this has been a bit of a thorn in the side. It also interacts poorly with a (in my view) pretty immature ecosystem for running services (for instance, the grpc library doesn't seem to be widely used or heavily maintained) or interacting with it via IPC. So it's great if you can spin up a notebook or repl and leave it running all day doing your work, or if you have a long-running batch process, but I agree that I've found it a bit tricky to interact with it from the outside world in the "usual" ways. Having said that, it does work - for instance, a system I work on spins up a long-lived julia thread from within a python service using the very nice shared library, and calls into julia functionality through that thread - I've just found it to be tricky; but IMO still very much worth it.
  - jampekka 3y ago
    Time to first plot (this is the time you have to wait for any plot if you don't do REPL/notebook in analyses). It's a commonly used term in Julia discussions. Nowadays also called TTFX where X can refer to variety of things.
    - sanderjd 3y ago
      Ah thanks! I'm relatively new to Julia and don't frequent discussion forums (yet?) and didn't have much luck searching for it. I figured out that it was an X in TTFX, but thought maybe, "print"? In any case, yep, makes sense, thanks! I guess for the typical scientific experimentation with plotting use case, why not just use the repl / notebook approach that (I think?) doesn't really suffer from this issue, as it's already up and running? My experience with startup time being problematic is when trying to "productionize" things that are not within a scientific / plotting loop. But my impression has been that it works well when doing things that are. Am I missing it?
      - jampekka 3y ago
        The main problem with REPL/notebook approach is that it has an "invisible state". E.g. running the cells in different order or running the same line in REPL twice can cause different behavior. This leads to major issues in e.g. reproducibility, easily introduces bugs that even leave no trace and generally it's very much against very core software development principles. Pluto.jl reportedly solves this, gotta try it out. My scientific/plotting loop runs from Bash (something not solved by Pluto.jl). This allows me to interoperate with a lot of software that's not in Python. I can version the code with e.g. git and the analysis pipeline tends to get refactored into libraries and CLI tools in the process. With Julia this is in practice impossible.
- sgt101 3y ago
  >The TTFP is too damn high and I don't think it will ever be fixed. I just installed and ran on my macbook - took me 7 minutes to get it installed and run through to a first plot, most of that was installing and compiling the Plots library. Once it's installed and available I can run it in about 1 second and then execute using Plots function test_plot() x = range(0, 10, length=100) y = sin.(x) plot(x, y) end @time test_plot() which gives me a result of 0.048700s and a nice plot. I don't think this is the defining issue with Julia now - it definitely used to be 10 years ago - but now it's more than competitive with Python in this regard. The issue is really support and buy in for all the new cool libraries that folks make available to use.
  - jampekka 3y ago
    That's not TTFP. TTFP is putting that code into a file (e.g. ttfp.jl) and running: $ time ./julia-1.9.4/bin/julia ttfp.jl 0.325806 seconds (202.80 k allocations: 13.208 MiB, 84.23% compilation time) real 0m2.401s user 0m2.357s sys 0m0.553s I.e. the TTFP is 2.4 seconds, not 0.33 seconds. That said, 2.4s is huge progress (e.g. with Julia 1.6.0 it's 10 seconds for me) and acceptable for most simple plotting. But just adding e.g. "using DynamicalSystems" brings this to 14 seconds, which is not acceptable for iterative editing. And it makes any Julia program using "DynamicalSystems" wildly impractical to use in a pipeline with other programs.
    - adgjlsfhk1 3y ago
      Also for the record, 1.10 rc1 brings the time down to 1.1 seconds (from 1.9 seconds in version 1.9 on my laptop). There's still more work to do, but there's been a ton of progress on this in the last year or so.
      - sertbdfgbnfgsd 3y ago
        No point having this conversation. These people are still repeating memes from 5 years ago. I've met one of them in the wild, it was quite eye opening.
cozzyd 3y ago
Nobody is going to implement an important library in Julia that other things rely on if everything that relies on it must be reimplemented in Julia too.

jampekka 3y ago

Biggest selling point of Julia is that you're locked in to Julia if you use it? For me this is the biggest point for giving up on Julia. Julia has a lot going for it in the basic design and I was really excited about it in the beginning. But even after all these years the environment is sadly almost unusable if you want to do something saner than REPL/notebook. The TTFP is too damn high and I don't think it will ever be fixed.

sertbdfgbnfgsd 3y ago
> environment is sadly almost unusable if you want to do something saner than REPL/notebook I work in "one of those industries" where failure can easily cost millions in the space of minutes, and we use Julia almost exclusively. Unfortunately I can't give you details because of reasons, other than tell you you're very poorly informed. > you're locked in to Julia You're not "locked in" to Julia any more you're locked in to Python. Arguably less, as Julia can call C natively, Python can't. My point isn't that you can't interop, and it seems you're intentionally (?) equivocating on this point. Surely you didn't misinterpret what I wrote as "you can't iterop"? My point is that you can more benefits if you don't. Like I said, if you want a slow language that can call fast routines, why not just use Python.
- jampekka 3y ago
  Python can call C natively. Also Python programs can be used as CLI tools interacting with practically any language. Julia programs in practice can't. But I know from experience that this debate will not go anywhere. It's is the same old refusal to see the problem: "you're using it wrong". Julia is dying and this is why it will die.
  - th0ma5 3y ago
    Yes, this is so true. There is a lot of wild attacking of the questioners of Julia.
- ykonstant 3y ago
  >I work in "one of those industries" where failure can easily cost millions in the space of minutes, and we use Julia almost exclusively. Unfortunately I can't give you details because of reasons, other than tell you you're very poorly informed. I vaguely recall a post from an ex Julia dev who had raised some issues regarding correctness of computations in Julia; I am not very familiar with the situation, have these concerns been addressed? Edit: now that I recall better, I think the correctness concerns had to do with ambiguous composition of disparate components due to vague interfaces. I think this has to do with multiple dispatch in Julia, but I don't know details. I would love any info about this.
  - leephillips 3y ago
    Yes.
  - sertbdfgbnfgsd 3y ago
    > I think the correctness concerns had to do with ambiguous composition of disparate components due to vague interfaces. I think this has to do with multiple dispatch in Julia You'd have to be more specific. Currently ambiguous dispatch throws an exception. I don't think this is a recent change either.
  - lukego 3y ago
    My impression is that this comes down to expectations. You might have a function: foo(x,y) = x + y and multiple dispatch means you can call that with integers, or floats, or arrays, or GPU-resident arrays, or automatically-differentiating numbers, or symbolic algebra terms, or... Just because you can, does that mean you should? It depends...
    - kelipso 3y ago
      I think it was more like you have a function over an abstract type like: foo(x::Number) = x+1 And then someone else creates a new type thats a subtype of Number. And they run foo(x) and get errors or unexpected output. Problem is the new type they created doesn't follow the assumptions that foo expects. Throw multiple dispatch into the mix and it gets even harder.
- amj7e 3y ago
  HFT? :D Which country are you in?
sanderjd 3y ago
What do you mean by TTFP? Is this like "time to first byte"? If so, what is the "P"? In any case, if the complaint is startup time, I do agree that this has been a bit of a thorn in the side. It also interacts poorly with a (in my view) pretty immature ecosystem for running services (for instance, the grpc library doesn't seem to be widely used or heavily maintained) or interacting with it via IPC. So it's great if you can spin up a notebook or repl and leave it running all day doing your work, or if you have a long-running batch process, but I agree that I've found it a bit tricky to interact with it from the outside world in the "usual" ways. Having said that, it does work - for instance, a system I work on spins up a long-lived julia thread from within a python service using the very nice shared library, and calls into julia functionality through that thread - I've just found it to be tricky; but IMO still very much worth it.
- jampekka 3y ago
  Time to first plot (this is the time you have to wait for any plot if you don't do REPL/notebook in analyses). It's a commonly used term in Julia discussions. Nowadays also called TTFX where X can refer to variety of things.
  - sanderjd 3y ago
    Ah thanks! I'm relatively new to Julia and don't frequent discussion forums (yet?) and didn't have much luck searching for it. I figured out that it was an X in TTFX, but thought maybe, "print"? In any case, yep, makes sense, thanks! I guess for the typical scientific experimentation with plotting use case, why not just use the repl / notebook approach that (I think?) doesn't really suffer from this issue, as it's already up and running? My experience with startup time being problematic is when trying to "productionize" things that are not within a scientific / plotting loop. But my impression has been that it works well when doing things that are. Am I missing it?
    - jampekka 3y ago
      The main problem with REPL/notebook approach is that it has an "invisible state". E.g. running the cells in different order or running the same line in REPL twice can cause different behavior. This leads to major issues in e.g. reproducibility, easily introduces bugs that even leave no trace and generally it's very much against very core software development principles. Pluto.jl reportedly solves this, gotta try it out. My scientific/plotting loop runs from Bash (something not solved by Pluto.jl). This allows me to interoperate with a lot of software that's not in Python. I can version the code with e.g. git and the analysis pipeline tends to get refactored into libraries and CLI tools in the process. With Julia this is in practice impossible.
sgt101 3y ago
>The TTFP is too damn high and I don't think it will ever be fixed. I just installed and ran on my macbook - took me 7 minutes to get it installed and run through to a first plot, most of that was installing and compiling the Plots library. Once it's installed and available I can run it in about 1 second and then execute using Plots function test_plot() x = range(0, 10, length=100) y = sin.(x) plot(x, y) end @time test_plot() which gives me a result of 0.048700s and a nice plot. I don't think this is the defining issue with Julia now - it definitely used to be 10 years ago - but now it's more than competitive with Python in this regard. The issue is really support and buy in for all the new cool libraries that folks make available to use.
- jampekka 3y ago
  That's not TTFP. TTFP is putting that code into a file (e.g. ttfp.jl) and running: $ time ./julia-1.9.4/bin/julia ttfp.jl 0.325806 seconds (202.80 k allocations: 13.208 MiB, 84.23% compilation time) real 0m2.401s user 0m2.357s sys 0m0.553s I.e. the TTFP is 2.4 seconds, not 0.33 seconds. That said, 2.4s is huge progress (e.g. with Julia 1.6.0 it's 10 seconds for me) and acceptable for most simple plotting. But just adding e.g. "using DynamicalSystems" brings this to 14 seconds, which is not acceptable for iterative editing. And it makes any Julia program using "DynamicalSystems" wildly impractical to use in a pipeline with other programs.
  - adgjlsfhk1 3y ago
    Also for the record, 1.10 rc1 brings the time down to 1.1 seconds (from 1.9 seconds in version 1.9 on my laptop). There's still more work to do, but there's been a ton of progress on this in the last year or so.
    - sertbdfgbnfgsd 3y ago
      No point having this conversation. These people are still repeating memes from 5 years ago. I've met one of them in the wild, it was quite eye opening.

cozzyd 3y ago

Nobody is going to implement an important library in Julia that other things rely on if everything that relies on it must be reimplemented in Julia too.