# Did Julia community do something to improve its correctness?

**URL:** <https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515>\
**Category:** General Usage\
**Created:** [August 5, 2023, 7:16am UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515 "2023-08-05T07:16:42Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![LarkyJulia](https://avatars.discourse-cdn.com/v4/letter/l/e9c0ed/32.png) [@LarkyJulia](https://discourse.julialang.org/u/LarkyJulia)\
**Post date:** [August 5, 2023, 7:16am UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/1 "2023-08-05T07:16:42Z")

</div>

I hope I can use it for control system simulation and deep learning. I want to introduce Julia to my students, but I heard many things about its correctness. I learned Julia but never use it to do any real job. I hope the community has began to solve them.  
How it is going with the correctness improvement? Does these include recoding some important library again by professional programmer instead of scholars. And if there is no measures to improve it, do es that mean the idea about using other scholar’s code will eventually fail?  
Thanks.

---

<div class="post-metadata">

**Author:** ![jar1](https://avatars.discourse-cdn.com/v4/letter/j/c0e974/32.png) [@jar1](https://discourse.julialang.org/u/jar1)\
**Post date:** [August 5, 2023, 8:13am UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/2 "2023-08-05T08:13:29Z")

</div>

I haven’t seen much change on correctness. There are a few developments that might be setting the groundwork for improvements, however.

- Julia 1.10 will use a Julia-based parser which will make syntax tooling easier.
- Julia 1.11 will have a way to declare public API which will help alert developers to what is expected, and help develop tooling to prevent out-of-API use.
- JET.jl is developing rapidly.
- @Sukera and @Keno have been developing interface specification tools like [GitHub - Seelengrab/PropCheck.jl: A package for simple property based testing in julia.](https://github.com/Seelengrab/PropCheck.jl) which should help if they are adopted but those tools are very new and not yet adopted.

Again though, those only create the opportunity for investing in correctness. Whether the devs and community will actually take that opportunity remains an open question.

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [August 5, 2023, 8:15am UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/3 "2023-08-05T08:15:41Z")

</div>

There is hardly any problem with the correctness of the solution of numerical problems with Julia. A problem that was discussed a lot, even though it has little relevance in practice was the use of zero based arrays with libraries that did not test this use case.

This issue is mitigated with warnings for code that iterates over 1:length(vector) by the linter, and many package authors updated their libraries.

In the end you will always have bugs in any program and you must always verify important results with other means, for example text book examples or code written in other languages.

So there is no Julia specific correctness problem other than that you have to be careful which packages you use and combine. You can get cutting edge algorithms as Julia packages. Before using them for serious work just ask in this forum which package is the best choice for a given problem.

I am using Julia and ModelingToolkit.jl for contol system development and the only bugs that the compiler did not find were my own bugs…

---

<div class="post-metadata">

**Author:** ![Eben60](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/eben60/32/13475_2.png) [@Eben60](https://discourse.julialang.org/u/Eben60)\
**Post date:** [August 5, 2023, 8:59am UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/4 "2023-08-05T08:59:46Z")

</div>

> [@LarkyJulia](#):
>
> but I heard many things about its correctness.

That is pretty unspecific, and thus is difficult to answer specifically.

As for reliability of Julia for numeric calculations: It is used for some quite demanding and probably mission critical tasks by a number of big players.

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [August 5, 2023, 9:03am UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/5 "2023-08-05T09:03:55Z")

</div>

Let me answer the correctness question first. Correctness requires testing and analysis. Besides built in testing facilities in the standard library there are also a number of important tools:

1. [GitHub - aviatesk/JET.jl: An experimental code analyzer for Julia. No need for additional type annotations.](https://github.com/aviatesk/JET.jl) for static analysis
2. [GitHub - JuliaTesting/Aqua.jl: Auto QUality Assurance for Julia packages](https://github.com/JuliaTesting/Aqua.jl) for package quality evaluation

Some misconstrue correctness to mean a language will prevent you or otherwise strongly warn you from doing something you should not be doing or that may result in undefined behavior. For example, some static languages will refuse to compile if they can detect such conditions. In Julia, the static analysis and execution steps are decoupled since Julia is a dynamic language. If you want to do this analysis, it must be done explicitly. Ultimately, if you want to ensure correctness the only real path is through extensive testing. Julia provides the tools to do so, but you have to use them.

The correctness issue is also relative. My sense is that well written Julia code has a greater chance of being correct than say the equivalent well written Python code. Julia has a built-in notion of types, including abstract and parametric types. If used well, this can greatly enhance the quality and correctness of Julia code. Type annotations in Python are a relati vely new concept and require non-standard tools to utilize. Versus statically compiled languages, we are at a potential disadvantage since we do not have a mandatory step to force staric analysis, but it still can be done as an optional step as described above. That said we also have the advantage of being relatively modern versus a languages like C and C++ in that we some known unsafe behaviors are clearly indicated.

Where some Julia correctness issues have arisen is when abstract interfaces were either not well defined or understood. The classic example is for `AbstractArray`. This is a highly abstract interface which provides a lot of flexibility. You may have heard Julia is a one-based language in that indexing of the `Array` type starts at `1`. This is not necessarily true for an `AbstractArray`. Some methods, sometimes from old code, have made some incorrect assumptions such as one-based indexing resulting in errors. To compensate, Julia has some nice tools to support arbitrary indexing such as the `begin` keyword or the `first` or `eachindex` methods. My recommendation is for Julia programmers to start conservatively with concrete types such as the one-based `Array` rather than trying overgeneralize too soon. Using abstract types requires significantly more testing than using concrete types.

In summary for correctness, Julia has the facilities to check for correctness, but you have to use them.

A significant part of Julia is being developed by professional developers. The companies JuliaHub, RelationalAI, and PumasAI have full time professional developers working on core Julia and packages. A number of companies are also applying Julia internally.

At the end of the day, what we are really talking about are software bugs. Julia has a wide variety of facilities to employ engineering controls to identify and correct them, but they must be used. Some facilities such as the enforcement of abstract interfaces are still being developed, but they do exist and are being thought about.

A more abstract concept is that much of Julia code is written in Julia itself, meaning that Julia developers have the ability to catch and evaluate issues and bugs directly.

---

<div class="post-metadata">

**Author:** ![greatpet](https://avatars.discourse-cdn.com/v4/letter/g/e495f1/32.png) [@greatpet](https://discourse.julialang.org/u/greatpet)\
**Post date:** [August 5, 2023, 9:48am UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/6 "2023-08-05T09:48:53Z")

</div>

> [@jar1](#):
>
> Julia 1.11 will have a way to declare public API

How is it done? Something like C++'s “public” and “private” keywords?

---

<div class="post-metadata">

**Author:** ![cormullion](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cormullion/32/49131_2.png) [@cormullion](https://discourse.julialang.org/u/cormullion)\
**Post date:** [August 5, 2023, 10:37am UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/7 "2023-08-05T10:37:41Z")

</div>

Looks like this open PR:

[https://github.com/JuliaLang/julia/pull/50105](https://github.com/JuliaLang/julia/pull/50105)

---

<div class="post-metadata">

**Author:** ![adienes](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/adienes/32/37459_2.png) [@adienes](https://discourse.julialang.org/u/adienes)\
**Post date:** [August 5, 2023, 12:36pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/8 "2023-08-05T12:36:13Z")

</div>

> [@ufechner7](#):
>
> So there is no Julia specific correctness problem

This has not been my experience. Sometimes quite fundamental things (in Base, not referring to packages) are broken in ways which makes me really scratch my head.

That being said, I share @jar1 's optimism. It seems like—especially very recently—there has been more attention towards defining and enforcing interfaces. And many of the issues/PRs tagged for 1.10 have been various bugs & regressions, some of which quite long-standing, which gives me the feeling that it will be a particularly “clean” release.

---

<div class="post-metadata">

**Author:** ![jishnub](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jishnub/32/33620_2.png) [@jishnub](https://discourse.julialang.org/u/jishnub)\
**Post date:** [August 5, 2023, 12:59pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/9 "2023-08-05T12:59:02Z")

</div>

There’s also a gulf between correctness of Julia, and that of packages. The former receives a lot of attention, whereas the latter is what users often interact with. Fixing the latter often requires active development, which may not always be the case.

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [August 5, 2023, 1:27pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/10 "2023-08-05T13:27:29Z")

</div>

Which packages? Some high schooler’s homework project or DataFrames? There’s \>7000 packages. Making a statement about “packages” makes no sense. The 7000+ packages are not similar. Please say what packages you’re talking about and what parts of them if you want to make any real statement. Otherwise my response is, I don’t think there’s any correctness issue in MuladdMacro.jl and I have never seen a single person open up an issue about its correctness.

---

<div class="post-metadata">

**Author:** ![jishnub](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jishnub/32/33620_2.png) [@jishnub](https://discourse.julialang.org/u/jishnub)\
**Post date:** [August 5, 2023, 2:01pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/11 "2023-08-05T14:01:25Z")

</div>

Well, of course. I’m not singling your package out. Yuri’s post at that time had talked about Distributions, StatsBase and OrderedCollections from what I recall. Those specific issues from the post have been addressed now. I’ve recently fixed a few issues with FillArrays. I’m guessing SciML packages would be of a higher standard because of a larger community involvement

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [August 5, 2023, 2:12pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/12 "2023-08-05T14:12:29Z")

</div>

I think it’s just a general thing that anytime someone says “packages” they should always specify which ones, because “packages” at this point is not a very helpful term. You can always find a package that’s bad, because there’s some packages that should basically be deleted. That’s true on pypi as well. So my point is that we shouldn’t say “Julia packages have these problems …”, any statement like that needs to be qualified better, i.e. “I found that these 3 statistics packages could use an improvement” or “these 2 SciML packages need to improve their type stability in …”. Not only is it more actionable, it’s also more correct.

But back to the main topic “did Julia community do something to improve its correctness?”, yes. The biggest thing is that in v1.8 a lot of code is faster by not including `@inbounds`, and by having the inbounds checks disabled from a lot of the package sphere we get better error checks on what was probably the biggest issue. I wouldn’t say it’s all removed, and it’s easy to check:

[https://github.com/search?q=org%3ASciML+inbounds&type=code&p=1](https://github.com/search?q=org%3ASciML+inbounds&type=code&p=1)

But if you look through the list, most of what’s left is either user-facing benchmark code (i.e. model code), `@inbounds for eachindex(u)` which has a safety by design, generated code (which proves the correctness by the size of the symbolics), or are used in functions which are explicit `Array` dispatches used to specialize for performance.

I presume many Julia packages have made similar updates because of the potential performance benefits.

---

<div class="post-metadata">

**Author:** ![jakobnissen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jakobnissen/32/13477_2.png) [@jakobnissen](https://discourse.julialang.org/u/jakobnissen)\
**Post date:** [August 5, 2023, 4:11pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/13 "2023-08-05T16:11:43Z")

</div>

My take is that no, Julia has not substantially addressed the growing concerns about correctness. At least if you define “correctness” as the relative ability to write bug-free code. As Yuri presciently stated in his blog post:

> systemic problems like this can rarely be solved from the bottom up, and my sense is that the project leadership does not agree that there is a serious correctness problem.

The problem is quite hard to fix, because Julia is not designed for with correctness as a priority. This means that it’s hard to add language-level fixes in a non-breaking manner, and so the only way this issue can be improved is through a combination of minor changes on the language level, a cultural shift, and improved tooling. The cultural shift may be happening, but I don’t really any impact of it yet.

---

<div class="post-metadata">

**Author:** ![Raf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/raf/32/3383_2.png) [@Raf](https://discourse.julialang.org/u/Raf)\
**Post date:** [August 5, 2023, 5:23pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/14 "2023-08-05T17:23:56Z")

</div>

Its so hard to define what this question really means. How do we measure “correctness” over a whole ecosystem and compare it to another ecosystem?

Do you mean compared to R? or to python? or to Rust or Ada? What are we aiming for here?

One key problem is that other languages avoid the majority of Julias correctness problems by _not being composable_. You just cant use packages together so you cant expose inconsistencies between them, like array indexing problems Julia has had. If we compare all of the combinatorial possibility of bugs in any language, Julia will loose mostly because the number of possible combinations of code is (much) larger.

We do absolutely have to work out how to do package composability with more correctness. But the base language is increasingly used by e.g. by ASML in machines that make most of the worlds microchips, so probably its relatively reliable.

---

<div class="post-metadata">

**Author:** ![adienes](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/adienes/32/37459_2.png) [@adienes](https://discourse.julialang.org/u/adienes)\
**Post date:** [August 5, 2023, 5:29pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/15 "2023-08-05T17:29:30Z")

</div>

> [@Raf](#):
>
> One key problem is that other languages avoid the majority of Julias correctness problems by _not being composable_. You just cant use packages together so you cant expose inconsistencies between them, like array indexing problems Julia has had.

It is not just packages and it is not just composability. I am sometimes quite surprised by correctness issues directly in Base.

as just a very recent example, take [1.9.2 Base.map!(|,a,a,b) yields wrong answer on BitVector · Issue #50780 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/50780) (do not mean to pick on anyone in particular here)

```julia

julia> a = BitVector([0, 1]);

julia> b = BitVector([1, 0]);

julia> map!(|, a, a, b)
2-element BitVector:
 1
 0

```

it’s great that this got fixed quickly, but also it is kind of wild to me that it happened in the first place. can you imagine if `std::transform` in C++ on primitive bitwise operations was just… wrong?

there are plenty more examples like this that have remained open for quite some time

---

<div class="post-metadata">

**Author:** ![Raf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/raf/32/3383_2.png) [@Raf](https://discourse.julialang.org/u/Raf)\
**Post date:** [August 5, 2023, 5:35pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/16 "2023-08-05T17:35:25Z")

</div>

So your comparision is with C++ then, not R or Python 😉

> there are plenty more examples like this that have remained open for quite some time

That bug was fixed within hours of the report… its bad this happened but lets keep things concrete

---

<div class="post-metadata">

**Author:** ![adienes](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/adienes/32/37459_2.png) [@adienes](https://discourse.julialang.org/u/adienes)\
**Post date:** [August 5, 2023, 5:51pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/17 "2023-08-05T17:51:20Z")

</div>

ok then, just with the same function family `map!`, `sum!`, etc.

one of Yuri’s issue which has been open for 2 years:  
[sum!, prod!, any!, and all! may silently return incorrect results · Issue #39385 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/39385);

Undefined behavior exposed to the user open for 3 years, which I had to basically beg to get on the 1.10 milestone and was later removed  
[`map!` resulting in undefined values · Issue #36235 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/36235);

similarly this issue was open for a year before I bumped it to get it on the milestone, where if you indexed with an unsigned int you could just get an undef value  
[Bug with range() and unsigned indices · Issue #44895 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/44895);

and one I personally ran into: `Iterators.reverse` is very often wrong for `Filter` and `Zip` types, yet neither of these issues are labeled `bug` let alone taken seriously  
[`reverse(Iterators.filter)` can be incorrect if predicate is impure · Issue #50440 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/50440);  
[Iterators.reverse gives unexpected results when zipping iterators of different lengths · Issue #25583 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/25583);

I think significantly more things should be parsing errors, instead there is just strange and error-prone behavior, like  
[`continue` and `break` should not be allowed on RHS of expression · Issue #50415 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/50415);  
[Infix operator definition syntax needs documentation · Issue #15483 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/15483);

and god help you if you try to put too much code inside optional or keyword arguments… it’s very unclear when those get evaluated, in what scope, in what order, etc.

I’m not trying to be too negative, but I must admit I feel frustration every time this discussion comes up because the response is always “pics or it didn’t happen, please give examples,” but there are so many examples! just go to the issue tracker

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [August 5, 2023, 5:52pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/18 "2023-08-05T17:52:12Z")

</div>

> [@jakobnissen](#):
>
> My take is that no, Julia has not substantially addressed the growing concerns about correctness.

I’m not aware of growing concerns, but what do you have in mind with “not substantially addressed”? I just went through Yuri’s famous post, every link, and vast majority has been fixed (almost all the issues he raised have been closed, and if so I assume no longer relevant).

Here’s the complete list of exceptions (unless I missed any):

> <https://github.com/JuliaLang/julia/issues/39385>
>
> I noticed that \`sum!\` and \`prod!\` do not check for aliasing, leading to incorrec…t results when the same array is passed in both arguments. The incorrect behavior under aliasing is not documented and the result is a silent unexpected wrong result.
> 
> \`\`\`julia
> julia\> a = \[1 2 3\];
> 
> julia\> sum!(copy(a), a)
> 1×3 Matrix{Int64}:
> 1 2 3
> 
> julia\> sum!(a, a)
> 1×3 Matrix{Int64}:
> 0 0 0
> 
> julia\> a = \[1 2 3\];
> 
> julia\> prod!(copy(a), a)
> 1×3 Matrix{Int64}:
> 1 2 3
> 
> julia\> prod!(a, a)
> 1×3 Matrix{Int64}:
> 1 1 1
> \`\`\`
> 
> Not all mutating functions have this problem and \`cumsum!\` can be used this way without error:
> 
> \`\`\`julia
> julia\> a = \[1, 2, 3\];
> 
> julia\> cumsum!(a, a)
> 3-element Vector{Int64}:
> 1
> 3
> 6
> \`\`\`
> 
> Other functions correctly flag the aliasing in the case of \`===\` arguments and throw an error:
> 
> \`\`\`julia
> julia\> using LinearAlgebra
> 
> julia\> a = rand(2, 2);
> 
> julia\> mul!(a, a, a)
> ERROR: ArgumentError: output matrix must not be aliased with input matrix
> \`\`\`
> 
> The examples above were generated on Julia \`1.6.0-beta1\` and I see the same behavior in version \`1.5.3\`.
> 
> Edit: I noticed this issue also applies to \`any!\` and \`all!\`:
> 
> \`\`\`julia
> julia\> let a = \[true, false\]
> any!(a, a)
> end
> 2-element Array{Bool,1}:
> 0
> 0
> 
> julia\> let a = \[true, false\]
> any!(copy(a), a)
> end
> 2-element Array{Bool,1}:
> 1
> 0
> 
> julia\> let a = \[true, false\]
> all!(a, a)
> end
> 2-element Array{Bool,1}:
> 1
> 1
> 
> julia\> let a = \[true, false\]
> all!(copy(a), a)
> end
> 2-element Array{Bool,1}:
> 1
> 0
> \`\`\`

[This one seems alarming, but I’ve never used e.g. sum!, I and I think most would use sum, and not be affected?]

> <https://github.com/JuliaLang/julia/issues/39460>
>
> The generic \`copyto!(::AbstractArray, ::AbstractArray)\` checks for aliasing, but… \`copyto!(A::T, B::T) where T\<:Union{UnitUpperTriangular, UpperTriangular}\` and \`copyto!(A::T, B::T) where T\<:Union{LowerTriangular, UnitLowerTriangular}\` do not, which can lead to wrong results. It might happen with other methods as well, I didn’t check yet.
> \`\`\`julia
> julia\> M = Matrix(reshape(1:36, 6, 6))
> 6×6 Matrix{Int64}:
> 1 7 13 19 25 31
> 2 8 14 20 26 32
> 3 9 15 21 27 33
> 4 10 16 22 28 34
> 5 11 17 23 29 35
> 6 12 18 24 30 36
> 
> julia\> A = UpperTriangular(view(M, 1:5, 1:5))
> 5×5 UpperTriangular{Int64, SubArray{Int64, 2, Matrix{Int64}, Tuple{UnitRange{Int64}, UnitRange{Int64}}, false}}:
> 1 7 13 19 25
> ⋅ 8 14 20 26
> ⋅ ⋅ 15 21 27
> ⋅ ⋅ ⋅ 22 28
> ⋅ ⋅ ⋅ ⋅ 29
> 
> julia\> B = UpperTriangular(view(M, 2:6, 2:6))
> 5×5 UpperTriangular{Int64, SubArray{Int64, 2, Matrix{Int64}, Tuple{UnitRange{Int64}, UnitRange{Int64}}, false}}:
> 8 14 20 26 32
> ⋅ 15 21 27 33
> ⋅ ⋅ 22 28 34
> ⋅ ⋅ ⋅ 29 35
> ⋅ ⋅ ⋅ ⋅ 36
> 
> julia\> copyto!(B,A)
> 5×5 UpperTriangular{Int64, SubArray{Int64, 2, Matrix{Int64}, Tuple{UnitRange{Int64}, UnitRange{Int64}}, false}}:
> 1 7 13 19 25
> ⋅ 1 7 13 19
> ⋅ ⋅ 1 7 13
> ⋅ ⋅ ⋅ 1 7
> ⋅ ⋅ ⋅ ⋅ 1
> \`\`\`

[That’s another aliasing issue, and if you avoid that, then both ok?]

> <https://github.com/JuliaLang/julia/issues/36069>
>
> Consider the following:
> 
> \`\`\`julia
> julia\> open("test.txt", "w") do file
> … write(file, "line1\\n")
> run(pipeline(\`echo line2\`, file))
> write(file, "line3\\n")
> end;
> 
> shell\> cat test.txt
> line2
> line1
> line3
> \`\`\`
> 
> Since all writes are made with synchronous methods in the same task, it seems reasonable to expect they will happen in program order.
> 
> Discussion on Discourse: https://discourse.julialang.org/t/pipeline-writes-out-of-order/40351
> 
> \`\`\`
> julia\> versioninfo()
> Julia Version 1.4.1
> Commit 381693d3df\* (2020-04-14 17:20 UTC)
> Platform Info:
> OS: Linux (x86\_64-pc-linux-gnu)
> CPU: Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz
> WORD\_SIZE: 64
> LIBM: libopenlibm
> LLVM: libLLVM-8.0.1 (ORCJIT, skylake)
> \`\`\`

This one is rather obscure, and claimed:

> Is this really a bug? File IO is buffered by default, which I believe is a very reasonable choice. We could add a line-buffering option, but I’m not sure that should be the default.

> <https://github.com/JuliaStats/Distributions.jl/issues/1265>
>
> There are many incorrect uses of \`@inbounds\` in this package, leading to incorre…ct results when fitting distributions and doing other calculations on arrays with offset axes. 
> 
> I came across this issue \[previously\](https://github.com/JuliaStats/Distributions.jl/issues/1253) with \`DiscreteUniform\` but did not realize how widespread the problem was until I ran a \[search\](https://github.com/JuliaStats/Distributions.jl/search?q=inbounds) for \`@inbounds\` across the code in this package. 
> 
> Many uses of \`@inbounds\` in this package are in functions that accept arbitrary abstract vectors, matrices, or arrays, then disable bounds checks and index into the array with unsafe one-based indices.
> 
> One example is fitting a Normal distribution:
> 
> \`\`\`julia
> julia\> using Distributions, OffsetArrays
> 
> julia\> a = collect(-5:5);
> 
> julia\> b = OffsetArray(a, -5:5);
> 
> julia\> suffstats(Normal, a)
> Distributions.NormalStats(0.0, 0.0, 110.0, 11.0)
> 
> julia\> fit(Normal, a)
> Normal{Float64}(μ=0.0, σ=3.1622776601683795)
> 
> julia\> suffstats(Normal, b)
> Distributions.NormalStats(7.39673056934e11, 6.7243005175818184e10, 1.5901446116594743e23, 11.0)
> 
> julia\> fit(Normal, b)
> Normal{Float64}(μ=6.7243005175818184e10, σ=1.2023252515852448e11)
> \`\`\`
> 
> https://github.com/JuliaStats/Distributions.jl/blob/863844c88e4153af13996f571fcc612d159de542/src/univariate/continuous/normal.jl#L254-L271
> 
> \`\`\`
> julia\> versioninfo()
> Julia Version 1.5.3
> Commit 788b2c77c1 (2020-11-09 13:37 UTC)
> Platform Info:
> OS: macOS (x86\_64-apple-darwin18.7.0)
> CPU: Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
> WORD\_SIZE: 64
> LIBM: libopenlibm
> LLVM: libLLVM-9.0.1 (ORCJIT, skylake)
> \`\`\`

This package is very much used, so I doubt this is a huge issue for most users, is this only about if used with `OffsetArray`s or similar? I.e. avoidable, and avoided by most users?

> <https://github.com/JuliaStats/StatsBase.jl/issues/643>
>
> \`\`\`julia
> julia\> a = OffsetArray(ones(11), -5:5)
> 11-element OffsetArray(::Array…{Float64,1}, -5:5) with eltype Float64 with indices -5:5:
> 1.0
> 1.0
> 1.0
> 1.0
> 1.0
> 1.0
> 1.0
> 1.0
> 1.0
> 1.0
> 1.0
> 
> julia\> w = Weights(a)
> 11-element Weights{Float64,Float64,OffsetArray{Float64,1,Array{Float64,1}}}:
> 1.0
> 1.0
> 1.0
> 1.0
> 1.0
> 2.251490357e-314
> 0.0
> 6.52171459e-315
> 1.88857625414e-312
> 7.8513844288e-313
> 9.54898106473e-313
> 
> julia\> versioninfo()
> Julia Version 1.5.3
> Commit 788b2c77c1 (2020-11-09 13:37 UTC)
> Platform Info:
> OS: macOS (x86\_64-apple-darwin18.7.0)
> CPU: Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
> WORD\_SIZE: 64
> LIBM: libopenlibm
> LLVM: libLLVM-9.0.1 (ORCJIT, skylake)
> \`\`\`

This one is still open, but is it already fixed, I see at least:

> <https://github.com/JuliaStats/StatsBase.jl/pull/867/files>
>
> \- Addresses #638
> \- Added tests

Yuri still seems to care about Julia since he reported a new bug in April (an obscure one only relevant if you use Float16), and one in 2022, full list of the 4 open bug issues here:

> **[Issues · JuliaLang/julia](https://github.com/JuliaLang/julia/issues?q=author%3Ayurivish%2Bis%3Aopen%2Blabel%3Abug)**
>
> The Julia Programming Language. Contribute to JuliaLang/julia development by creating an account on GitHub.

> [@jar1](#):
>
> Julia 1.11 will have a way to declare public API

I think it’s too soon to state that (here’s what already merged, and I believe it documents staus quo, and should apply to all older version of Julia):

> <https://github.com/JuliaLang/julia/pull/50324/files>
>
> @ViralBShah asked for this in https://github.com/JuliaLang/julia/pull/50103#disc…ussion\_r1222064404.

Here’s what’s proposed, but it’s under discussion, and not yet on 1.11 milestone, and I believe not all agree, and there are counter-proposal(s):

> <https://github.com/JuliaLang/julia/pull/50105>
>
> NOTE: This PR is not a complete solution to the "public interfaces are typically… not well specified in Julia" problem. We would need to implement much than this to get to that point. Work on that problem is ongoing in Base and packages and contributions are welcome.
> 
> \- \[x\] https://github.com/JuliaLang/JuliaSyntax.jl/pull/320 is a key part of this PR (implements the syntax change) and must be merged first.
> 
> ~This PR is extended by https://github.com/JuliaLang/Pkg.jl/pull/3511 which defines the semantic interpretation of scoped export and should be merged or closed simultaneously.~
> 
> This adds a mechanism for "scoped export", which marks a symbol as part of the public API without loading it into the global namespace on \`using\`.
> 
> Goals
> 
> \- "API markers" that show up in docstrings
> \- The ability to query if something is an "API marked" thing
> \- The ability to discover "API marked" things
> \- Unambiguous definition of public API accessible from the REPL
> \- Little to no effort required by package authors to adopt this slightly more formal API specification
> 
> \_first three goals originally posted by @dalum in https://github.com/JuliaLang/julia/issues/49973#issuecomment-1579073814\_
> 
> 
> Changes this PR makes to achieve those goals
> 
> \- Add \`public, list, of, names\`
> \- \`names(Module)\` reports all public names (including exports)
> \- \`Base.isinternal(::Module, ::Symbol)\` is an internal method which determines if a symbol is internal.
> \- \`?my\_symbol\` flags the docstrings of unexported symbols as internal.
> \- The public API of Base becomes "behavior described in docstrings of public symbols (exported symbols are automatically public)"
> 
> Adoption
> 
> \- Internal unexported methods require no action. Internal exported methods shouldn't exist. Public exported methods require no action. Public unexported methods need to be "scoped export"ed to adopt this feature.
> \- Until folks scoped export their public but unexported symbols, they will be flagged as internal in \`help?\>\` mode.
> \- Compat.jl should be able to provide \`@public\` so folks can adopt this without dropping support for earlier versions of Julia.
> 
> TODO
> 
> \- \[x\] The current scoped export syntax is horrible \`export (scoped-true), list, of, names\`. This should be bikeshed and then implemented using JuliaSyntax.jl because @c42f says it's landing soon and I'd rather work with that than the scheme parser. \[current syntax: \`public list, of, names\`\]
> \- \[x\] Check that this doesn't lead to bad parsing error messages \[none that I could find\]
> \- \[x\] Need to mark as public all symbols in Base that are mentioned in the documentation
> \- ~Need to mark as public all symbols in Stdlib that are mentioned in the documentation~ \[this can be deferred to another PR before 1.11 lands because the docstring note is milder now\].
> \- \[x\] The warning in internal docstrings is ugly—it was the first place I could put a warning, not how I think it should look. Again: bikeshed first, then implement the specifics.
> \- \[x\] ~Only tab-complete to public methods. (@mcabbott's suggestions)~ moved to #50717
> \- \[x\] Update documentation to reflect \`public\` rather than \`export scoped=true\`.
> \- ~Move the changes in https://github.com/JuliaLang/Pkg.jl/pull/3511 to here.~
> 
> This implements #38162. See also:
> \- #42117
> \- #30204
> \- #48819
> \- #49973
> \- JuliaLang/Pkg.jl#3512

> [@adienes](#):
>
> one I personally ran into: `Iterators.reverse` is very often wrong for `Filter` and `Zip` types, yet neither of these issues are labeled `bug` let alone taken seriously  
> [`reverse(Iterators.filter)` can be incorrect if predicate is impure · Issue #50440 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/50440);  
> [Iterators.reverse gives unexpected results when zipping iterators of different lengths · Issue #25583 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/25583)

The latter was marked bug, then disagreed with, and thanks for making the PR for this. Though I’m not sure will be accepted.

Jeff likes supporting different lengths and recently merged this one (@elrod should this be reverted before it gets into stable Julia, and the rest of Julia go in the other direction? It’s in 1.10-beta1, and when it will get stable, it will be a breaking change to undo):

> <https://github.com/JuliaLang/julia/pull/49336>
>
> fix #49299, fix #42216

since different lengths are not considered bad, thus this closed:

> <https://github.com/JuliaLang/julia/issues/20499>
>
> Like Python, Julia's \`zip(a, b)\` ignores the tail end of its input sequences whe…n they are of unequal length (but see #17928). I've yet to encounter a problem where I wanted that behavior, and I would much prefer seeing an error when the inputs are of unequal length. Are there applications where truncation is very convenient?

conforming e.g. with Python (and Lisp), but Python discovered in 2020, and I pointed it out there in the end:

> [PEP 618 – Add Optional Length-Checking To zip | peps.python.org](https://www.python.org/dev/peps/pep-0618/)

> These bugs are not only difficult to diagnose, but difficult to even detect at all.

Would you like truncation for map, zip (and iterators)? And 2.0 because of it? See:

> <https://github.com/JuliaLang/julia/issues/42216#issuecomment-1073936787>
>
> Instead of stopping early like \`zip\`, this is an error:
> \`\`\`julia
> julia\> map(+,… (1,2,3), (4,5))
> ERROR: BoundsError: attempt to access Tuple{} at index \[1\]
> Stacktrace:
> \[1\] getindex(t::Tuple, i::Int64)
> @ Base ./tuple.jl:29
> \[2\] map (repeats 3 times)
> @ ./tuple.jl:250 \[inlined\]
> \[3\] top-level scope
> @ REPL\[32\]:1
> 
> julia\> map(+, (1,2,3), \[4,5\]) # what I expected
> 2-element Vector{Int64}:
> 5
> 7
> \`\`\`
> Is this a bug? It seems to be present at least since 1.0. The docstring for \`map\` says
> 
> \> For multiple collection arguments, apply \`f\` elementwise, and stop when when any of them is exhausted.
> 
> but I'm not sure I can quote it as authoratative, since I think I wrote it.

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [August 5, 2023, 6:04pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/19 "2023-08-05T18:04:14Z")

</div>

Correctness can have many different meanings. I am running simulations of dynamic systems, thus numerically solving differential equations. I did that with Simulink, Python, C++ and Julia.

When I use Simulink with my current model none of the variable step size solvers is delivering correct results, most of them seam to work, but the results have an error of 100% or more.  
The fixed step solvers work, but even with very small time steps which makes them 1000 times slower than Julia the error is 100 times larger than the error of the Julia solvers.

When linearizing non-trivial dynamic systems with Simulink I get results that are completely wrong, but no warning or error message. ModelingToolkit just works.

Shall I conclude that Matlab/ Simulink should not be used for serious work?

I would not do that. It has advantages and disadvantages, and you must always double check your results and choose a tool that meets your needs.

The main difference between Matlab and Julia with respect to correctness is that Matlab does not have a public issue tracker…

And I agree, I would put [sum!, prod!, any!, and all! may silently return incorrect results · Issue #39385 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/39385) as blocker on the 1.10 milestone…

UPDATE: Was just added to the 1.10 milestone… 🙂

---

<div class="post-metadata">

**Author:** ![adienes](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/adienes/32/37459_2.png) [@adienes](https://discourse.julialang.org/u/adienes)\
**Post date:** [August 5, 2023, 6:19pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/20 "2023-08-05T18:19:53Z")

</div>

I cannot speak to the correctness of Simulink/MATLAB as I have little experience with either.

I can conclude, though, that ModelingToolkit must not be depending on the correctness of reverse iterators or aliasing `map!`-like functions!

To be fair to Julia, it is a more comprehensive language than Python (the language, not the ecosystem), and there is a larger surface for error. Also, I think the Python or C++ code I write is indeed more likely to have a bug in it than the Julia code I write.

BUT, of the bugs in my Python or C++ code, the chance that it is an issue with the language itself is usually negligible, and it is almost always user-error. This is something that can be caught via peer review (or just self-review). When the language itself has a bug, reviews are not as effective a safeguard, as both sets of eyes might expect the same (correct) behavior, and it can take a very long time to realize what has actually gone wrong.

[Next page](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515.md?page=2)