5 ms·

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

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 12d 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 12d ago
  [deleted]
- Intralexical 12d 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".
  - jakobnissen 12d ago
    You can not be serious in suggesting these aren’t straight up Python correctness bugs. Exactly the same kind that Yuri brought up as damning evidence of Julia unseriousness, but for Python with easily 25x the user base.
    - Intralexical 12d ago
      Most (all?) aren't bugs by any stretch of the imagination, no. Let's go over the first 5. 1. random.choices(['a','b','c'], weights=[-1,5,1], k=10000) Negative weight on 'a' silently shifts Python docs say, "Weights are assumed to be non-negative and finite." Garbage in, garbage out. 2. random.choices(['a','b','c'], cum_weights=[5,2,7], k=10000) Non-monotone cum_weights makes 'b' unselectable. ...Those weights aren't cumulative, which the docs say they should be. Again, garbage in, garbage out. 3. statistics.fmean([1,2,3], weights=[-1,1,1]) “Mean” of three values in [1,3] returns 4 — outside the convex hull. This is just straight-up mathematically correct behavior. It preserves linearity. It fits the commonly accepted definition of weighted mean as `(w1*x1+w2*x2...)/(w1+w2...)`. The LLM fabricated a fake/idiosyncratic definition of weighted mean in order to claim it's a bug, because it was instructed to come up with bugs. 4. json.dumps({1: 'a', '1': 'b'}) Produces invalid JSON with duplicate keys; round-trip silently drops one entry. Again, documented behavior/GIGO. Docs say, "loads(dumps(x)) != x if x has non-string keys." 5. urlparse('http://example.com/?').geturl() Trailing ? (empty query) and # (empty fragment) silently stripped This is literally just what geturl() is supposed to do. It's the whole point. Docs say "empty parameters, queries, and fragment identifiers will be removed". The LLM is claiming that geturl()'s primary intended purpose is a bug. So all of these "eye watering correctness issues" so far seem to be either (1) straight-up correct, or (2) doing things Python explicitly tell you not to do. Same deal with the Numpy "bugs", AFAICT, as I touched on in my previous comment. In fact, I would venture that we all know those Python bugs are fake, but (unfortunately) the Julia ones aren't. Because the Julia bugs mentioned by Yuri were reported to the Julia bug tracker, and eventually fixed. Whereas if you really thought these are real bugs in Python, then (IMO) you should be reporting them to the Python tracker, not getting mad at me for doubting them. Moreover, even if they were real bugs in Python (which they aren't), bugs existing in Python still wouldn't change the situation for Julia. The Discourse user who posted it still admitted that they didn't even take the time to verify them. Surely you must realize how bad it makes Julia look, when its users fling LLM slop to attack Python in response to Julia's issues being brought up? A constructive project should instead talk about what's been done and planned to improve Julia's situation, not tell lies to drag Python down. I liked Julia when I tried it! The JIT plus multiple dispatch is so unique. But this so isn't the way.
- ModernMech 12d ago
  > in no way unique or even exaggerated in Julia I wouldn't say this is true really. Julia does have some unique properties which cause these issues other languages just sidestep. The dynamic dispatch system is really magical when it works, but it's the source of much of the consternation you see here in this thread, and the reason it persists despite individual bugs being fixed. The problem is the "bugs" in this case aren't really as such; they're not wrong code, they are violations of silent contracts. The whole magic of dynamic dispatch is you write Library A and Type B, and they "just work" together without having to know about one another. This is of course very powerful and so people have been very enthusiastic when wielding it. But with great power comes great responsibility; when using libraries and types that weren't meant to work together, one of those types might violate a silent contract in the library. This would be fine if the error could be caught at compile time, but it happens in the form of numerical correctness issues, so they don't even present as actual errors. The most obvious example of this is where Julia allows for arbitrary arrays and two things expecting different bases come into contact. This is something that's just not possible in other languages, so they're not exposed to this class of bugs. So maybe you can harden and make explicit some of these contracts, or put up warning signs, or add some lints, and thus "fix bugs"; but they keep coming back because the dynamic dispatch system assures it due to the combinatorial explosion of interactions it incurs. I'm very interested in how Julia will solve this issue going forward.

postflopclarity 12d 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 12d ago
[deleted]
Intralexical 12d 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".
- jakobnissen 12d ago
  You can not be serious in suggesting these aren’t straight up Python correctness bugs. Exactly the same kind that Yuri brought up as damning evidence of Julia unseriousness, but for Python with easily 25x the user base.
  - Intralexical 12d ago
    Most (all?) aren't bugs by any stretch of the imagination, no. Let's go over the first 5. 1. random.choices(['a','b','c'], weights=[-1,5,1], k=10000) Negative weight on 'a' silently shifts Python docs say, "Weights are assumed to be non-negative and finite." Garbage in, garbage out. 2. random.choices(['a','b','c'], cum_weights=[5,2,7], k=10000) Non-monotone cum_weights makes 'b' unselectable. ...Those weights aren't cumulative, which the docs say they should be. Again, garbage in, garbage out. 3. statistics.fmean([1,2,3], weights=[-1,1,1]) “Mean” of three values in [1,3] returns 4 — outside the convex hull. This is just straight-up mathematically correct behavior. It preserves linearity. It fits the commonly accepted definition of weighted mean as `(w1*x1+w2*x2...)/(w1+w2...)`. The LLM fabricated a fake/idiosyncratic definition of weighted mean in order to claim it's a bug, because it was instructed to come up with bugs. 4. json.dumps({1: 'a', '1': 'b'}) Produces invalid JSON with duplicate keys; round-trip silently drops one entry. Again, documented behavior/GIGO. Docs say, "loads(dumps(x)) != x if x has non-string keys." 5. urlparse('http://example.com/?').geturl() Trailing ? (empty query) and # (empty fragment) silently stripped This is literally just what geturl() is supposed to do. It's the whole point. Docs say "empty parameters, queries, and fragment identifiers will be removed". The LLM is claiming that geturl()'s primary intended purpose is a bug. So all of these "eye watering correctness issues" so far seem to be either (1) straight-up correct, or (2) doing things Python explicitly tell you not to do. Same deal with the Numpy "bugs", AFAICT, as I touched on in my previous comment. In fact, I would venture that we all know those Python bugs are fake, but (unfortunately) the Julia ones aren't. Because the Julia bugs mentioned by Yuri were reported to the Julia bug tracker, and eventually fixed. Whereas if you really thought these are real bugs in Python, then (IMO) you should be reporting them to the Python tracker, not getting mad at me for doubting them. Moreover, even if they were real bugs in Python (which they aren't), bugs existing in Python still wouldn't change the situation for Julia. The Discourse user who posted it still admitted that they didn't even take the time to verify them. Surely you must realize how bad it makes Julia look, when its users fling LLM slop to attack Python in response to Julia's issues being brought up? A constructive project should instead talk about what's been done and planned to improve Julia's situation, not tell lies to drag Python down. I liked Julia when I tried it! The JIT plus multiple dispatch is so unique. But this so isn't the way.
ModernMech 12d ago
> in no way unique or even exaggerated in Julia I wouldn't say this is true really. Julia does have some unique properties which cause these issues other languages just sidestep. The dynamic dispatch system is really magical when it works, but it's the source of much of the consternation you see here in this thread, and the reason it persists despite individual bugs being fixed. The problem is the "bugs" in this case aren't really as such; they're not wrong code, they are violations of silent contracts. The whole magic of dynamic dispatch is you write Library A and Type B, and they "just work" together without having to know about one another. This is of course very powerful and so people have been very enthusiastic when wielding it. But with great power comes great responsibility; when using libraries and types that weren't meant to work together, one of those types might violate a silent contract in the library. This would be fine if the error could be caught at compile time, but it happens in the form of numerical correctness issues, so they don't even present as actual errors. The most obvious example of this is where Julia allows for arbitrary arrays and two things expecting different bases come into contact. This is something that's just not possible in other languages, so they're not exposed to this class of bugs. So maybe you can harden and make explicit some of these contracts, or put up warning signs, or add some lints, and thus "fix bugs"; but they keep coming back because the dynamic dispatch system assures it due to the combinatorial explosion of interactions it incurs. I'm very interested in how Julia will solve this issue going forward.