4 ms·

Do you think the criticism in the article "Why I no longer recommend Julia" about correctness is still valid? * there are too many correctness and composability

Do you think the criticism in the article "Why I no longer recommend Julia" about correctness is still valid? * there are too many correctness and composability bugs throughout the ecosystem to justify using it in just about any context where correctness matters * https://yuri.is/not-julia/ https://yuri.is/not-julia/

postflopclarity 29d ago
I think that article has been discussed to death and there's not much value in resurrecting it on every single post that mentions Julia. ultimately if you think the language might be a fit for your use case, I'd recommend trying it out and see how you like it first-hand.
- lalalanananana 29d ago
  I strongly recommend listening to others experiences and not forwarding some conversion metric for the languages share holders. Maybe there's a lot of wisdom in smart people being vocal enough to say "yea no" about it. It's not like it's one person...
  - postflopclarity 29d ago
    I don't have any financial interest in Julia so I'm a bit confused about the reference to "share holders." I'm just a user. I'm sure there are lots of smart people who found that the language didn't suit their needs. there are also lots of smart people who love using Julia. both things can be true at the same time.
    - patagurbon 29d ago
      There are no language share holders, and note that this account was created an hour ago just to post vague nonspecific gripes about Julia. There are some real issues in the ecosystem. Specifically there is a high proportion of “gradware” because much like other scientific languages there is a high proportion of graduate students doing their projects and then moving on. The language also encourages relying on packages which can break. But juliaup makes this easy enough to solve by downgrading.
      - lalalanananana 29d ago
        There are vc investments and other corporate sponsors which heavily dictate the language and it's ecosystem.
        patagurbon 29d ago
        They dictate what their employees are paid to work on, there are no VC investments in The Julia Programming Language It’s true that MIT and a few other organizations have more influence than others simply because they employ more developers with time/scope to work on the language. Just like every programming language. But this becomes less true all the time. And most of the direction that is “paid for” is an unadulterated good: JuliaC ahead of time compilation has been requested for over a decade and has made enormous progress.
        lalalanananana 28d ago
        If you think this has no effect on core contributions or directionality for the language I have a crazy deal on a timeshare
        postflopclarity 28d ago
        I have submitted plenty of core contributions, none of which were directed or paid for by VC. the language contributions come from those sufficiently motivated to contribute. if you want to change the direction, you need to do some work.
        lalalanananana 28d ago
        I have core contributions to the language too. I think you misunderstood my sentiment. That's okay. In a few years you'll probably be where I am now. Setting a reminder for 2 years.
- deleted 29d ago
  [deleted]
- retsibsi 29d ago
  I'm one of today's lucky 10,000, so I'm glad it was linked here (and would happily read a defence of the language from one of those previous discussions, too). When the criticisms relate to correctness bugs, I don't think 'try it out and see how you like it' is sufficient. I might love the syntax and the design and so on, but that doesn't tell me whether I'm going to run into serious bugs some time in the future.
  - eigenspace 29d ago
    Here's a somewhat recent discussion sparked by someone who was concerned having read the blogpost: https://discourse.julialang.org/t/julia-stability-vs-rust-for-scientific-computing/ https://discourse.julialang.org/t/julia-stability-vs-rust-fo... It got a little long and meandered a bit, but I think there's some good, nuanced discussion there.
    - postflopclarity 29d ago
      in particular, https://discourse.julialang.org/t/julia-stability-vs-rust-for-scientific-computing/137094/30 https://discourse.julialang.org/t/julia-stability-vs-rust-fo... is a very visceral example of how bugs like these arise everywhere (including python) and are in no way unique or even exaggerated in Julia.
      - deleted 29d ago
        [deleted]
      - Intralexical 29d ago
        That reads to me more like a long-winded example of a Julia user refusing to take correctness issues seriously, and instead using an LLM to self-soothe by deflecting onto other projects: > I think there’s also a mindset split, some people just like to have things more strict and avoid bugs by having their compiler proof everything, and others like more freedom and are fine with occasional mishaps. > Just for the fun of it, I put claude on Python, and it also found some eye watering correctness issues (to be fair, I haven’t taken the time to verify and judge them, but it seems like that’s a similar situation for the Julia version) I say "self-soothe" because if the intention were to better understand the correctness situation, presumably one would at least want to evaluate the output before declaring it "eye watering". And then even if the output was real, it would be better to report it to the affected Python projects instead of using it as an excuse to downplay problems in Julia. But most of the supposed "bugs" seem like totally fine/reasonable behaviors to me, often for clearly nonsensical inputs. Seriously, `np.array([1, 'two', 3.0])`? That's not a bug, the behavior is clearly documented on numpy.org, but really no matter what Python does with that, it's not comparable to issues like `prod([Int8(100), Int8(100)]) != prod((Int8(100), Int8(100)))` from that post about Julia. Which again the linked Discourse post downplays as "freedom and occasional mishaps".
yurivish 29d ago
I do. It pairs nicely with this quote from the article: > “With Dyad 3.0, you can upload data and design documents and the system will design an entire aircraft for you,” Shah says
- deleted 29d ago
  [deleted]
- deleted 29d ago
  [deleted]
ainch 29d ago
As someone who could be tempted by Julia but isn't involved in the community this was a very helpful read, thank you for sharing.
- dunefox 29d ago
  It really isn't very helpful, as many of the issues are either obsolete or exaggerated.
eigenspace 29d ago
Programming languages have bugs. These things happen, and this tired article blows them totally out of proportion. Some languages are less permissive, and have a culture of searching harder for corner cases and dealing with them than others, that is true. I would expect to find less cases like this in Rust, but more cases like this in Python. Julia is an extremely flexible and permissive language, which means that generic code needs to be written carefully and contracts between interfaces need to be thought through. When you combine funky package types like OffsetArrays with functions from a package where the authors didn't think about OffsetArrays, bad things can happen. Those things were then reported and the community has learned a lot about how to deal with those sorts of things. I'm sure an AI agent can crawl through and find a new big list of weird bugs in julia, but that's true even of a language like Rust.
- penteract 29d ago
  > Some languages are less permissive, and have a culture of searching harder for corner cases and dealing with them than others, that is true. I would expect to find less cases like this in Rust, but more cases like this in Python. My expectation is that when I think I've found a bug in the programming language implementation I'm using, it's actually me that's mistaken (or at least that language lawyers consider me to be mistaken). Hearing about someone who has encountered multiple bugs (in regular use, rather than running a fuzzer or being directly involved in implementing the language) makes me very wary.
  - Intralexical 29d ago
    Yeah, this is crazy. It's literally a cliché for most programming languages that it's never the compiler's fault. Granted a lot of the Julia bugs seem to be in the standard/core libraries, but still. Even if the bugs are overstated, this cavalier attitude towards correctness in a numerical language is super disconcerting to me.
- Intralexical 29d ago
  Corner cases like `prod([Int8(100), Int8(100)]) != prod((Int8(100), Int8(100)))`? Both returned integers, but the left was 10000 while the right was 16. [0] Which, apparently, sat in the standard library for almost four years after it was introduced before it was fixed. [1] Even if there was some merit to your argument, I would still find the attitude disqualifying. While it may be technically true that all programming languages have bugs, software and software communities for numerical computing should take responsibility and treat those bugs seriously, not downplay them by pointing to the fact that other software probably has bugs too. FWIW I don't have a horse in this race. I've used both before, and I currently make money using neither. I liked Julia. I find that article concerning. And I find the attempts by Julia users to discredit that article in this thread, without addressing its substance, even more concerning and disappointing. Well, bugs can be fixed. But ideally not by a culture that dismisses them as inevitable or unimportant. [0] https://github.com/JuliaLang/julia/issues/39183 https://github.com/JuliaLang/julia/issues/39183 [1] https://github.com/JuliaLang/julia/blob/26f2333686ce90331548035d47ec707227efb417/base/tuple.jl#L311-L317 https://github.com/JuliaLang/julia/blob/26f2333686ce90331548...

postflopclarity 29d ago

I think that article has been discussed to death and there's not much value in resurrecting it on every single post that mentions Julia. ultimately if you think the language might be a fit for your use case, I'd recommend trying it out and see how you like it first-hand.

lalalanananana 29d ago
I strongly recommend listening to others experiences and not forwarding some conversion metric for the languages share holders. Maybe there's a lot of wisdom in smart people being vocal enough to say "yea no" about it. It's not like it's one person...
- postflopclarity 29d ago
  I don't have any financial interest in Julia so I'm a bit confused about the reference to "share holders." I'm just a user. I'm sure there are lots of smart people who found that the language didn't suit their needs. there are also lots of smart people who love using Julia. both things can be true at the same time.
  - patagurbon 29d ago
    There are no language share holders, and note that this account was created an hour ago just to post vague nonspecific gripes about Julia. There are some real issues in the ecosystem. Specifically there is a high proportion of “gradware” because much like other scientific languages there is a high proportion of graduate students doing their projects and then moving on. The language also encourages relying on packages which can break. But juliaup makes this easy enough to solve by downgrading.
    - lalalanananana 29d ago
      There are vc investments and other corporate sponsors which heavily dictate the language and it's ecosystem.
      - patagurbon 29d ago
        They dictate what their employees are paid to work on, there are no VC investments in The Julia Programming Language It’s true that MIT and a few other organizations have more influence than others simply because they employ more developers with time/scope to work on the language. Just like every programming language. But this becomes less true all the time. And most of the direction that is “paid for” is an unadulterated good: JuliaC ahead of time compilation has been requested for over a decade and has made enormous progress.
        lalalanananana 28d ago
        If you think this has no effect on core contributions or directionality for the language I have a crazy deal on a timeshare
        postflopclarity 28d ago
        I have submitted plenty of core contributions, none of which were directed or paid for by VC. the language contributions come from those sufficiently motivated to contribute. if you want to change the direction, you need to do some work.
        lalalanananana 28d ago
        I have core contributions to the language too. I think you misunderstood my sentiment. That's okay. In a few years you'll probably be where I am now. Setting a reminder for 2 years.
deleted 29d ago
[deleted]
retsibsi 29d ago
I'm one of today's lucky 10,000, so I'm glad it was linked here (and would happily read a defence of the language from one of those previous discussions, too). When the criticisms relate to correctness bugs, I don't think 'try it out and see how you like it' is sufficient. I might love the syntax and the design and so on, but that doesn't tell me whether I'm going to run into serious bugs some time in the future.
- eigenspace 29d ago
  Here's a somewhat recent discussion sparked by someone who was concerned having read the blogpost: https://discourse.julialang.org/t/julia-stability-vs-rust-for-scientific-computing/ https://discourse.julialang.org/t/julia-stability-vs-rust-fo... It got a little long and meandered a bit, but I think there's some good, nuanced discussion there.
  - postflopclarity 29d ago
    in particular, https://discourse.julialang.org/t/julia-stability-vs-rust-for-scientific-computing/137094/30 https://discourse.julialang.org/t/julia-stability-vs-rust-fo... is a very visceral example of how bugs like these arise everywhere (including python) and are in no way unique or even exaggerated in Julia.
    - deleted 29d ago
      [deleted]
    - Intralexical 29d ago
      That reads to me more like a long-winded example of a Julia user refusing to take correctness issues seriously, and instead using an LLM to self-soothe by deflecting onto other projects: > I think there’s also a mindset split, some people just like to have things more strict and avoid bugs by having their compiler proof everything, and others like more freedom and are fine with occasional mishaps. > Just for the fun of it, I put claude on Python, and it also found some eye watering correctness issues (to be fair, I haven’t taken the time to verify and judge them, but it seems like that’s a similar situation for the Julia version) I say "self-soothe" because if the intention were to better understand the correctness situation, presumably one would at least want to evaluate the output before declaring it "eye watering". And then even if the output was real, it would be better to report it to the affected Python projects instead of using it as an excuse to downplay problems in Julia. But most of the supposed "bugs" seem like totally fine/reasonable behaviors to me, often for clearly nonsensical inputs. Seriously, `np.array([1, 'two', 3.0])`? That's not a bug, the behavior is clearly documented on numpy.org, but really no matter what Python does with that, it's not comparable to issues like `prod([Int8(100), Int8(100)]) != prod((Int8(100), Int8(100)))` from that post about Julia. Which again the linked Discourse post downplays as "freedom and occasional mishaps".

yurivish 29d ago

I do. It pairs nicely with this quote from the article: > “With Dyad 3.0, you can upload data and design documents and the system will design an entire aircraft for you,” Shah says

deleted 29d ago
[deleted]
deleted 29d ago
[deleted]

ainch 29d ago

As someone who could be tempted by Julia but isn't involved in the community this was a very helpful read, thank you for sharing.

dunefox 29d ago
It really isn't very helpful, as many of the issues are either obsolete or exaggerated.

eigenspace 29d ago

Programming languages have bugs. These things happen, and this tired article blows them totally out of proportion. Some languages are less permissive, and have a culture of searching harder for corner cases and dealing with them than others, that is true. I would expect to find less cases like this in Rust, but more cases like this in Python. Julia is an extremely flexible and permissive language, which means that generic code needs to be written carefully and contracts between interfaces need to be thought through. When you combine funky package types like OffsetArrays with functions from a package where the authors didn't think about OffsetArrays, bad things can happen. Those things were then reported and the community has learned a lot about how to deal with those sorts of things. I'm sure an AI agent can crawl through and find a new big list of weird bugs in julia, but that's true even of a language like Rust.

penteract 29d ago
> Some languages are less permissive, and have a culture of searching harder for corner cases and dealing with them than others, that is true. I would expect to find less cases like this in Rust, but more cases like this in Python. My expectation is that when I think I've found a bug in the programming language implementation I'm using, it's actually me that's mistaken (or at least that language lawyers consider me to be mistaken). Hearing about someone who has encountered multiple bugs (in regular use, rather than running a fuzzer or being directly involved in implementing the language) makes me very wary.
- Intralexical 29d ago
  Yeah, this is crazy. It's literally a cliché for most programming languages that it's never the compiler's fault. Granted a lot of the Julia bugs seem to be in the standard/core libraries, but still. Even if the bugs are overstated, this cavalier attitude towards correctness in a numerical language is super disconcerting to me.
Intralexical 29d ago
Corner cases like `prod([Int8(100), Int8(100)]) != prod((Int8(100), Int8(100)))`? Both returned integers, but the left was 10000 while the right was 16. [0] Which, apparently, sat in the standard library for almost four years after it was introduced before it was fixed. [1] Even if there was some merit to your argument, I would still find the attitude disqualifying. While it may be technically true that all programming languages have bugs, software and software communities for numerical computing should take responsibility and treat those bugs seriously, not downplay them by pointing to the fact that other software probably has bugs too. FWIW I don't have a horse in this race. I've used both before, and I currently make money using neither. I liked Julia. I find that article concerning. And I find the attempts by Julia users to discredit that article in this thread, without addressing its substance, even more concerning and disappointing. Well, bugs can be fixed. But ideally not by a culture that dismisses them as inevitable or unimportant. [0] https://github.com/JuliaLang/julia/issues/39183 https://github.com/JuliaLang/julia/issues/39183 [1] https://github.com/JuliaLang/julia/blob/26f2333686ce90331548035d47ec707227efb417/base/tuple.jl#L311-L317 https://github.com/JuliaLang/julia/blob/26f2333686ce90331548...