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

Correctness and composability bugs in the Julia ecosystem (2022)

yuri.is

Post reply on HN
Print view View original

41–50 of 83 posts

Re: Correctness and composability bugs in the Julia ecosystem (2022)

#41

Post by hatmatrix »

leephillips wrote: post #39
ForceBru wrote: post #35

Has anything changed since then? What are y'all's thoughts about correctness in Julia in 2025?

This is a reasonable article, but way out of date now. Almost all issues raised were solved a while ago.

I say this as a huge Julia fan, but the point is not the specific bugs in the article, but the culture of not prioritizing correctness in computation. The initial response by many (not all) in the community was look, those specific bugs are fixed; all languages have bugs; more importantly - look at the benchmark speeds of these computations! Which only reinforced this negative perception.

My understanding is that it's a difficult problem to solve, and there are people working on traits/interfaces - but these are still peripheral projects and not part of the core mission to my knowledge. In practice, composability problems arise seldomly, but there is no formal way to guard against it yet. I believe there was some work done at Northeastern U. [1] toward this goal but it's still up to the user to "be careful", essentially.

[1] https://repository.library.northeastern.edu/files/neu:4f20cn...

Re: Correctness and composability bugs in the Julia ecosystem (2022)

#42

Post by Grikbdl »

leephillips wrote: post #39
ForceBru wrote: post #35

Has anything changed since then? What are y'all's thoughts about correctness in Julia in 2025?

This is a reasonable article, but way out of date now. Almost all issues raised were solved a while ago.

When I look, an issue such as "the base `sum!` is wrong" is still an open issue. Which, I think, is a bit ridiculous.

Re: Correctness and composability bugs in the Julia ecosystem (2022)

#43

Post by hatmatrix »

postflopclarity wrote: post #38
ForceBru wrote: post #35

Has anything changed since then? What are y'all's thoughts about correctness in Julia in 2025?

improving, still not perfect. it was true then, and is even more true now, that a large fraction of "correctness bugs" (maybe even the majority) arise from `OffsetArrays.jl`, so a simple solution besides "avoid Julia" is "avoid that package"

The greater issue that there is still no way to prevent those types of composability bugs.

Re: Correctness and composability bugs in the Julia ecosystem (2022)

#44

Post by hatmatrix »

jacobolus wrote: post #36
mgkuhn wrote: post #27

Julia is a very powerful and flexible language. With very powerful tools you can get a lot done quickly, including shooting yourself into the foot. Julia's type-system allows you to easily compose different elements of Julia's vast package ecosystem in ways that possibly were never tested or even intended or foreseen by the authors of these packages to be used that way. If you don't do that, you may have a much bette…

One of the basic marketing claims of the language developers is that one author's algorithm can be composed with another author's custom data type. If that's not really true in general, even for some of the most popular libraries and data types, maybe the claims should be moderated a bit.

> one author's algorithm can be composed with another author's custom data type

This is true, and it's a powerful part of the language - but you can implement it incorrectly when you compose elements together that expect some attributes from the custom data type. There is no way to formally enforce that, so you can end up with correctness bugs.

Re: Correctness and composability bugs in the Julia ecosystem (2022)

#45

Post by postflopclarity »

hatmatrix wrote: post #43
postflopclarity wrote: post #38

Earlier quoted context omitted.

improving, still not perfect. it was true then, and is even more true now, that a large fraction of "correctness bugs" (maybe even the majority) arise from `OffsetArrays.jl`, so a simple solution besides "avoid Julia" is "avoid that package"

The greater issue that there is still no way to prevent those types of composability bugs.

sure there are ways. they're just not employed as diligently as they should be. that's more of a social problem than a technical problem.

Re: Correctness and composability bugs in the Julia ecosystem (2022)

#46

Post by Grikbdl »

TimorousBestie wrote: post #29
taikahessu wrote: post #7

Earlier quoted context omitted.

Hinted as Python not having these issues.

Python also suffers from such problems. For example, here’s scipy’s issue tracker, filtered for bugs only: https://github.com/scipy/scipy/issues?q=is%3Aissue%20state%3... Scrolling through this list, it’s clear that many are “correctness issues.” I do not link this to argue that scipy bugs are more serious or more frequent. I don’t think that kind of statistical comparison is meaningful. However, I think a motivated…

Explicit errors are not correctness issues. Some numerical instability issues in certain algorithms in certain corner cases might be considered as such though.

Regardless, overall, these are grossly of another complexity and seriousness than the base sum function being just wrong, or cultural issues among developers with not verifying inputs "for performance", or things of that nature. The scientific Python community has, in my experience, a much higher adherence to good standards than that.

Re: Correctness and composability bugs in the Julia ecosystem (2022)

#47

Post by leephillips »

Grikbdl wrote: post #42
leephillips wrote: post #39

Earlier quoted context omitted.

This is a reasonable article, but way out of date now. Almost all issues raised were solved a while ago.

When I look, an issue such as "the base `sum!` is wrong" is still an open issue. Which, I think, is a bit ridiculous.

This is a typical example:

• The documentation (currently) of the function warns not to use it this way;

• This is a rather perverse use of the function(s) that would be unlikely unless you’re trying to break things;

• The discussion on the issue page demonstrates the exact opposite of a culture not caring about correctness;

• This kind of stuff doesn’t matter to all the scientists who are actually using Julia to do real work.

Nevertheless, sum!() and friends should be, somehow, made to avoid this problem, certainly.

Re: Correctness and composability bugs in the Julia ecosystem (2022)

#48

Post by CyberDildonics »

mgkuhn wrote: post #32
CyberDildonics wrote: post #10

I like the design of the language, but I eventually went through too many cycles of "fast compilation and/or module caching is coming in the next release" and "ahead of time compilation is coming soon" and got burned out. I remember believing the same stuff from java for years until forgetting about it.

The pre-compilation speed/caching performance ("time to first plot") has practically been solved since 2024, when Julia 1.10 became the current LTS version. The current focus is on improving the generation of reasonably-sized stand-alone binaries.

I heard it for 10 years, I gave it too many chances. Each time it was solved, then it was going to be solved in a new release right around the corner, again and again. Maybe it is now, I don't care anymore.

Re: Correctness and composability bugs in the Julia ecosystem (2022)

#49

Post by munificent »

hatmatrix wrote: post #41
leephillips wrote: post #39

Earlier quoted context omitted.

This is a reasonable article, but way out of date now. Almost all issues raised were solved a while ago.

I say this as a huge Julia fan, but the point is not the specific bugs in the article, but the culture of not prioritizing correctness in computation. The initial response by many (not all) in the community was look, those specific bugs are fixed; all languages have bugs; more importantly - look at the benchmark speeds of these computations! Which only reinforced this negative perception. My understanding is that it'…

> the culture of not prioritizing correctness in computation.

In a language with pervasive use of generic methods, I don't know what actually means. If I write a function like:

    function add3(x, y, z)
      x + y + z
    end
Is it correct or not? What does "correct" even mean here? If you call it with values where `+` is defined on them and does what you expect, then my function probably does what you expect too. But if you pass values where `+` does something weird, then `add3()` does something weird too.

Is that correct? What expectations should someone have about a function whose behavior is defined in terms of calls to other open-ended generic functions?

Re: Correctness and composability bugs in the Julia ecosystem (2022)

#50

Post by TimorousBestie »

Grikbdl wrote: post #46
TimorousBestie wrote: post #29

Earlier quoted context omitted.

Python also suffers from such problems. For example, here’s scipy’s issue tracker, filtered for bugs only: https://github.com/scipy/scipy/issues?q=is%3Aissue%20state%3... Scrolling through this list, it’s clear that many are “correctness issues.” I do not link this to argue that scipy bugs are more serious or more frequent. I don’t think that kind of statistical comparison is meaningful. However, I think a motivated…

Explicit errors are not correctness issues. Some numerical instability issues in certain algorithms in certain corner cases might be considered as such though. Regardless, overall, these are grossly of another complexity and seriousness than the base sum function being just wrong, or cultural issues among developers with not verifying inputs "for performance", or things of that nature. The scientific Python community…

> Explicit errors are not correctness issues.

Yes, of course. I am not conflating the two.

> The scientific Python community has, in my experience, a much higher adherence to good standards than that.

Not in my experience. Nor am I defending Julia.

Post reply on HN