3 ms·

> 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 m

> 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.
    - deleted 3y ago
      [deleted]
    - sertbdfgbnfgsd 3y ago
      > foo(x::Number) = x+1 > Problem is the new type they created doesn't follow the assumptions that foo expects. If you define that function and someone else (i.e. a user of your lib) defines a subtype of Number and calls your function on it, and it fails, then they haven't respected the interface to Number. There's nothing wrong with that function or type specialization in that case. In that case it's all about defining useful interfaces and respecting, as much of programming is. E.g. if someone defines a subtype of Number because he has something that's kind of like a number in some respects but not others, maybe that shouldn't be an subtype of Number. You also shouldn't define functions that have obscure conditions for being properly useable - at least if you expect your code to be useful more broadly. Nothing here is specific to Julia though. If you have other specific examples we could discuss more.
amj7e 3y ago
HFT? :D Which country are you in?

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.
  - deleted 3y ago
    [deleted]
  - sertbdfgbnfgsd 3y ago
    > foo(x::Number) = x+1 > Problem is the new type they created doesn't follow the assumptions that foo expects. If you define that function and someone else (i.e. a user of your lib) defines a subtype of Number and calls your function on it, and it fails, then they haven't respected the interface to Number. There's nothing wrong with that function or type specialization in that case. In that case it's all about defining useful interfaces and respecting, as much of programming is. E.g. if someone defines a subtype of Number because he has something that's kind of like a number in some respects but not others, maybe that shouldn't be an subtype of Number. You also shouldn't define functions that have obscure conditions for being properly useable - at least if you expect your code to be useful more broadly. Nothing here is specific to Julia though. If you have other specific examples we could discuss more.

amj7e 3y ago

HFT? :D Which country are you in?