# 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:** 4

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [August 7, 2023, 10:12pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/106 "2023-08-07T22:12:26Z")

</div>

> [@ufechner7](#):
>
> I see as a sign of ignorance of leading team members for correctness issues…

No matter how established a language, there’s always more issues than there are people who can work on and review them. It’s not a great feeling when issues relevant to you are not as prioritized, but that doesn’t imply neglect. We got typed globals and `const` fields in mutable types in 1.8, we got native code caching and an interactive thread pool in 1.9, we’re scheduled to get multithreaded GC in 1.10. It made sense these big things had priority.

We can mitigate this with more contributors and trusted reviewers, which I think could be taught or at least set some guidelines beyond “open an issue.” For example, despite how often I chime in on issues, I am not confident enough in my testing practices to do more than spotting problems, and I wouldn’t even know what a proper documentation edit would look like. It’s legitimately more intimidating because incorrect changes to the source material can cause more widespread problems than incorrect opinions on a discourse thread.

That said, there’s never going to be enough people to cover all the issues. Look up a language of any note on Github, there are thousands of open issues, some over a decade old, and a good chunk of them are bugs and incorrect results. Always a struggle to get enough people to fix one small piece of the world, software isn’t any different.

---

<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 7, 2023, 11:14pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/107 "2023-08-07T23:14:31Z")

</div>

> [@Benny](#):
>
> Look up a language of any note on Github, there are thousands of open issues, some over a decade old, and a good chunk of them are bugs and incorrect results.

I might be naive, but I don’t think most popular languages would let something like the [reverse-zip bug](https://github.com/JuliaLang/julia/issues/25583) go past multiple releases. That is,

- incorrect results
- with no warning or error
- for documented behavior
- in generic built-in functions
- in multiple releases after being reported

Are other languages full of these? What do you have in mind?

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [August 7, 2023, 11:33pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/108 "2023-08-07T23:33:58Z")

</div>

For one, I don’t think Julia is popular and AFAIK most agree. For another, that’s really something you have to see and judge for yourself. CPython is pretty popular, you can start reading issues [here](https://github.com/python/cpython/issues?q=is%3Aopen+label%3Atype-bug+sort%3Acreated-asc), which is only one label in the open issues, but one that’ll skew closer to bugs and weird behaviors.

---

<div class="post-metadata">

**Author:** ![Sukera](https://avatars.discourse-cdn.com/v4/letter/s/ce7236/32.png) [@Sukera](https://discourse.julialang.org/u/Sukera)\
**Post date:** [August 7, 2023, 11:39pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/109 "2023-08-07T23:39:16Z")

</div>

> [@Benny](#):
>
> We got typed globals and `const` fields in mutable types in 1.8, we got native code caching and an interactive thread pool in 1.9, we’re scheduled to get multithreaded GC in 1.10. It made sense these big things had priority.

New features are cool and all, they do make good marketing material for all the ways Julia can do even more things better now. I’m really not sure that’s what’s needed at this point though - Yuris blogpost has had such an impact outside of our community that it’s an inevitable conversation topic when someone asks about the language. Not multithreaded GC performance or whether you have an additional bad performance impact from not typing your globals.

The fact that this discussion got started precisely because this is still the way Julia is viewed outside our bubble and the fact that barely anything has happened to mitigate that is just testament to where the priorities lie - and that’s squarely on chasing shiny features.

I mean I get it, it’s not glamorous to have a bugfix release, but come on, the more features we pile on without fixing these kinds of longstanding issues, the worse the existing perception will get.

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [August 7, 2023, 11:59pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/110 "2023-08-07T23:59:48Z")

</div>

That isn’t chasing shiny new features, uninferrable globals performance and latency due to compilation, especially the unsaved work, are among the most frequent complaints about Julia. Many newcomers see these two particular issues as why Julia doesn’t really live up to its claim to solving the “two-language problem”. Just the last few versions made a massive change to that, though I bet many still won’t be sold until executables are easy to make and as small as possible.

Yuri’s blog raised many valid issues, his frustration is valid, and it’s his right to prefer not dealing with them anymore. But it’s just not spectacular for any language and its third-party libraries to have bugs that users have to raise; many of the examples in the blog were fixed long before the blog was written (which I think is a positive, not a negative), and many examples were fixed after his blog drew attention to them. The biggest longstanding issue is how `AbstractArray` code has 1-based assumptions that resulted in bugs for the OffsetArrays package (it’s bigger than that, there’s missing implementations too). Some fixes happened, but that’s a pretty big project and will need time to complete. But comparatively, not many use OffsetArrays, but everyone needs to import packages and compile methods. It’s not strange the latter got more work done sooner.

---

<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 8, 2023, 12:14am UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/111 "2023-08-08T00:14:12Z")

</div>

> [@Benny](#):
>
> For another, that’s really something you have to see and judge for yourself. CPython is pretty popular

I described a pretty low bar, I can’t think of anything failing it in Python. Obviously there are bugs, but imho incorrect results in basic functions are a different species of problem.

Here’s another example, from the ecosystem, where string formatting is flagrantly incorrect, in a package with [677 dependents](https://juliahub.com/ui/Packages/Formatting/vCa4N/0.4.2). I find it hard to imagine this happening in Python.

> <https://github.com/JuliaIO/Formatting.jl/issues/108>
>
> \`\`\`
> julia\> using Formatting
> julia\> Formatting.fmt(".1e", 0.0003)
> "2.10e-04"
> …\`\`\`

> [@Sukera](#):
>
> New features are cool and all, they do make good marketing material for all the ways Julia can do even more things better now.

My impression is those performance features come from companies that need them paying to get them in rather than being motivated by advertising/coolness. That is just to say I don’t know what the solution to the correctness problem is if funders aren’t paying for it.

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [August 8, 2023, 12:34am UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/112 "2023-08-08T00:34:17Z")

</div>

> [@jar1](#):
>
> I described a pretty low bar, I can’t think of anything failing it in Python. Obviously there are bugs, but imho incorrect results in basic functions are a different species of problem.

I think I’m not really grasping your point. I already linked a page listing many CPython issues about incorrect results in basic standard library functions, and I can’t do more to help you vet your opinion.

> [@jar1](#):
>
> Here’s another example, from the ecosystem, where string formatting is flagrantly incorrect

I’m not surprised about that from a third party package whose latest v0 release came in 2020. It’s not hard to find a package that deserves more developer attention in any language’s ecosystem, and it seems this example is getting it in the Format.jl fork.

I’m not disputing that Julia has issues, it’s just nothing said so far seems particular to Julia. So far I’ve just seen this recurrent anxiety that This Issue will drive any newcomers away from Julia, and This Issue changes depending on who you ask. I don’t think it’s unusual for more widespread issues to have been given more priority. I do find unusual the argument that less widespread issues, as much fun as I’ve had learning about them, would be more important, critical in fact, to Julia’s reputation.

---

<div class="post-metadata">

**Author:** ![Ininterrompue](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ininterrompue/32/5594_2.png) [@Ininterrompue](https://discourse.julialang.org/u/Ininterrompue)\
**Post date:** [August 8, 2023, 1:59am UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/113 "2023-08-08T01:59:52Z")

</div>

I believe what you say about CPython. In fact a simple glance at Numpy shows over a thousand outstanding issues. But that doesn’t make Julia’s position any better, nor will it convince anyone on edge about the topic at hand. I think one advantage of having huge monolith packages is the need to not worry about how the package interacts with the rest of the ecosystem as much.

I guess one of the examples I point to was something first discussed years ago: incorrect gradient bugs in certain Julia ML packages. There were multiple stories of people spending months trying to debug, until finally they realized that their code was silently giving wrong results. See [here](https://discourse.julialang.org/t/state-of-machine-learning-in-julia/74385/4) and [here](https://discourse.julialang.org/t/state-of-machine-learning-in-julia/74385/13) for examples. If an AI startup ran into something like this, well, their competitors are potentially months ahead in development now because they used Python. I can’t recommend Julia for ML in part because of this. Do incorrect gradient bugs occur like this in Python, or C++? Seems particular to Julia to me.

The overarching theme remains: it is the attitude to which these bugs are approached that is the issue (the “culture”). In a post above, it was mentioned most bugs tagged with correctness aren’t release blocking, and it begs the question, why? I don’t buy the reason that they’re corner cases few run into…after 10 years bugs that show up better be corner cases, right? Maybe it’s a communication issue on what the priorities are or how they’re determined - I have no knowledge of the inner workings of the repo and neither do most other end users - but it seems odd that priority isn’t given to issues that silently give incorrect results. To me correctness is far and away the most important issue, not improved performance, and it doesn’t seem like everyone agrees.

I watched the state of Julia talk given this year and I saw 0 mentions of correctness issues. Maybe I missed something, but it seemed like the perfect opportunity to address an elephant in the room.

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [August 8, 2023, 3:05am UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/114 "2023-08-08T03:05:03Z")

</div>

> [@Ininterrompue](#):
>
> Do incorrect gradient bugs occur like this in Python

Just searching the string “incorrect gradient” in the issues of pytorch, jax, and tensorflow, apparently yes, some silent, some not. However, I’ve never done ML so I can’t say how important or prevalent these issues are, let alone make comparisons to Zygote.jl’s. I can only take the word of people who have used all these tools thoroughly in their work.

> [@Ininterrompue](#):
>
> most bugs tagged with correctness aren’t release blocking, and it begs the question, why?

It’d be very strange to block a release that fixes some issues and adds demanded features just because other issues and features aren’t resolved yet. You mentioned Numpy’s outstanding issues, obviously releases kept coming. Developers need to agree to block a release to fix an issue or include a feature, it’s not a default decision.

> [@Ininterrompue](#):
>
> I watched the state of Julia talk given this year and I saw 0 mentions of correctness issues. Maybe I missed something, but it seemed like the perfect opportunity to address an elephant in the room.

Like I said before, correctness isn’t One Thing, some nebulous force threatening the future of the language. It’s just a fact of life that software has bugs that get patched incrementally and routinely. It’s so mundane that every big feature had to resolve their fair share of correctness issues at some point, there’s even a state of Julia slide about the progress on threading that casually lists “features/correctness” topics (each topic can have multiple issues).

---

<div class="post-metadata">

**Author:** ![Alec\_Loudenback](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/alec_loudenback/32/278_2.png) [@Alec\_Loudenback](https://discourse.julialang.org/u/Alec_Loudenback)\
**Post date:** [August 8, 2023, 4:17am UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/115 "2023-08-08T04:17:08Z")

</div>

Legitimate question: are Julia’s bugs seen as of a different character than other peer projects? E.g. the same kinds of issues seem to be present in other projects, e.g.:

> **[Issues · numpy/numpy](https://github.com/numpy/numpy/issues?page=2&q=is%3Aissue%2Bis%3Aopen%2Bbug%2Bincorrect)**
>
> The fundamental package for scientific computing with Python. - Issues · numpy/numpy

> **[Issues · rust-lang/rust](https://github.com/rust-lang/rust/issues?q=is%3Aissue%2Bis%3Aopen%2Bbug%2Bincorrect%2B)**
>
> Empowering everyone to build reliable and efficient software. - Issues · rust-lang/rust

E.g just some cursory searching finds incorrect results when using [modulo arithmetic in rust](https://github.com/rust-lang/rust/issues/111405) or odd edge cases in Numpy related to mutability, complex-number types, unsigned integer behavior.

To my uninformed eye, these problems seem similar to those that have been identified in Julia?

Also, at the time of writing Julia has fewer open issues matching “bug incorrect” than Numpy does, though I admit not enough understanding of the nuances here to comment whether that metric is meaningful.

---

<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 8, 2023, 4:24am UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/116 "2023-08-08T04:24:43Z")

</div>

I think the nature of coding in Julia leads one to encounter “edge” cases more frequently than other languages, so it is more painful when these are wrong.

As an evocative but probably not-quite-right example, in Python if you have object types `A` and `B` and you want them to interact, one might first transform them into a very safe/robust/well-tested form, like a vector of floats or a dictionary etc., then perform the needed operations.

In Julia, one might call `foo(::A, ::B)` directly and just hope that each type is satisfying its interface well enough for `foo` to remain correct without any transformations to a “safe” type needed at all

---

<div class="post-metadata">

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

</div>

> [@algunion](#):
>
> It would be nice to see this kind of message delivered by the core developers

Every single open-source project I know is basically starved for personpower. We’re volunteers too, and while we do occasionally beg for contributions, you shouldn’t need us to do that in order to realize you can help.

That doesn’t mean your PR will be reviewed instantly because of the issues pointed out so nicely in [Did Julia community do something to improve its correctness? - #103 by gdalle](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/103), but hopefully someone will do it justice eventually.

---

<div class="post-metadata">

**Author:** ![algunion](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/algunion/32/51630_2.png) [@algunion](https://discourse.julialang.org/u/algunion)\
**Post date:** [August 8, 2023, 1:34pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/118 "2023-08-08T13:34:55Z")

</div>

> [@tim.holy](#):
>
> … while we do occasionally beg for contributions, you shouldn’t need us to do that in order to realize you can help.

It didn’t cross my mind to link the _begging for contributions_ to being able to assess that _I can help_.

I am not sure to what extent others feel the same, but when it comes to evaluating _what one can do_, I am pretty confident when doing that evaluation for the projects I am working on as opposed to contributing to Julia-repo.

I know that there is always the _make a PR, and let us tell you if it is garbage_ solution - but that feels more like _fighting my way in_ approach. The same “_…we’re volunteers too_” applies here - and both the following were valid for a while now:

- I really love Julia and I want it to thrive
- I have (can make) time to contribute

In fact, I wanted to contribute in some way and [after this topic cooled down](https://discourse.julialang.org/t/a-kind-of-two-language-problem-in-julia-ecosystem/100445) I started to be more active here, on discourse.

I know that general true statements about what contributing to open-source projects means can be invoked and applied to Julia (and it is not like I am ignorant about those _rules_): however, I think we can at least entertain the idea that in a less technical way than, now mitigated, TTFX, Julia might have a time-to-first-PR issue (and is less relevant that other open-source projects might have this issue as well).

It was a clear TTFPR issue when [I reported the following bug after I actually delved into Julia’s source code, detected the exact issue, and proposed the fix](https://github.com/JuliaLang/julia/issues/50646).

So why didn’t I PR the thing and only open an issue? Good question: I cannot pinpoint a single reason.

Maybe it was about a mix of various factors. But my honest answer is that I wanted to contribute, I had the time (and actually I had the local fix because the bug was really annoying) and still no PR.

If my case is singular and this _I want + I can + I don’t_ mix is not a real issue that goes past my sole experience, then I think we can just let this go: I learned my lesson.

However, if there are things that can be done in the Julia community to reduce yet another _TTF- something_, then let’s use this opportunity and maybe lower the _perceived_ bar for Julia-repo contributions.

---

<div class="post-metadata">

**Author:** ![tim.holy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tim.holy/32/52_2.png) [@tim.holy](https://discourse.julialang.org/u/tim.holy)\
**Post date:** [August 8, 2023, 1:52pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/119 "2023-08-08T13:52:50Z")

</div>

I know that many people don’t contribute who perhaps should, but also that many who do submit PRs can have a frustrating experience waiting for reviews. I don’t know how to fix that. The fundamental tradeoff is that time spent reviewing PRs (and it takes a lot of time) means time not spent on other activities like fixing _really_ hard problems. So we persist in an awkward balance where good stuff gets done but perhaps more slowly than ideal.

Anyway, this is a bit off-topic from this main thread, I’ll stop now. If you have ideas about how to fix it perhaps another topic?

---

<div class="post-metadata">

**Author:** ![algunion](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/algunion/32/51630_2.png) [@algunion](https://discourse.julialang.org/u/algunion)\
**Post date:** [August 8, 2023, 1:57pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/120 "2023-08-08T13:57:38Z")

</div>

I agree we should stop here for now. I’ll think about this.

Also - thank you for the hard work you put into the Julia ecosystem. Sometimes it is hard to point out some issues without sounding ungrateful/demanding: so again, thank you!

---

<div class="post-metadata">

**Author:** ![mschauer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mschauer/32/13946_2.png) [@mschauer](https://discourse.julialang.org/u/mschauer)\
**Post date:** [August 8, 2023, 2:24pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/121 "2023-08-08T14:24:03Z")

</div>

So here is a many page discussion about the reverse-zip bug I was about to fix, but when I saw from the lack of enthusiasm that the fix would mean having a PR lingering around for years again I left it be [Iterators.reverse gives unexpected results when zipping iterators of different lengths · Issue #25583 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/25583#issuecomment-367436289) (I had already with #24978 a PR that took 3 years and with #29927 one that took 2 years)

---

<div class="post-metadata">

**Author:** ![ToucheSir](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/touchesir/32/14411_2.png) [@ToucheSir](https://discourse.julialang.org/u/ToucheSir)\
**Post date:** [August 8, 2023, 3:55pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/122 "2023-08-08T15:55:47Z")

</div>

> [@Ininterrompue](#):
>
> I guess one of the examples I point to was something first discussed years ago: incorrect gradient bugs in certain Julia ML packages. There were multiple stories of people spending months trying to debug, until finally they realized that their code was silently giving wrong results. See [here](https://discourse.julialang.org/t/state-of-machine-learning-in-julia/74385/4) and [here](https://discourse.julialang.org/t/state-of-machine-learning-in-julia/74385/13) for examples. If an AI startup ran into something like this, well, their competitors are potentially months ahead in development now because they used Python. I can’t recommend Julia for ML in part because of this. Do incorrect gradient bugs occur like this in Python, or C++? Seems particular to Julia to me.

If you’re interested in discussing this specifically I’d recommend starting a new topic or reading over some of the previous discussions, but yes this specific example is probably the poster child of the hype and shiny features over correctness culture being decried.

However (and note this is coming from someone who has complained _at length_ about the aforementioned issues), it does feel like one of the more extreme examples and not representative of the ecosystem as a whole. Case in point, ForwardDiff.jl has been quite solid for years now in the AD space. The reason this is a big deal despite only involving 2-3 libraries comes down to a) interest in ML as shown by anecdata and successive Julia Community Surveys, b) some of the packages being promoted as flagship libraries in the past such that everyone and their dog knows about them, and c) excessive hype about the capabilities of this specific corner of the ecosystem during early development which didn’t pan out for a variety of reasons.

> [@Benny](#):
>
> Just searching the string “incorrect gradient” in the issues of pytorch, jax, and tensorflow, apparently yes, some silent, some not. However, I’ve never done ML so I can’t say how important or prevalent these issues are, let alone make comparisons to Zygote.jl’s. I can only take the word of people who have used all these tools thoroughly in their work.

I think you’re right to be skeptical about number of issues being a good metric here. Suffice it to say Zygote has/had a greater number of significant issues and issues in commonly-used code paths than the Python ADs being compared against, even if the absolute or relative number of issues is similar. It does seem like some lessons were learned from this, but unfortunately not before the Julia ecosystem experienced a reverse-mode AD “winter” which has only recently begun to thaw (again, a discussion for another thread).

---

<div class="post-metadata">

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

</div>

It seems this thread has come to an awkward end. Can I take credit for that?

---

<div class="post-metadata">

**Author:** ![ctrebbau](https://avatars.discourse-cdn.com/v4/letter/c/5f9b8f/32.png) [@ctrebbau](https://discourse.julialang.org/u/ctrebbau)\
**Post date:** [August 13, 2023, 7:46pm UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/124 "2023-08-13T19:46:31Z")

</div>

![image](https://global.discourse-cdn.com/julialang/original/3X/e/8/e8b1c2176bb54985697490ad78242d00e46daafc.jpeg)

---

<div class="post-metadata">

**Author:** ![gdalle](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gdalle/32/224680_2.png) [@gdalle](https://discourse.julialang.org/u/gdalle)\
**Post date:** [August 14, 2023, 6:53am UTC](https://discourse.julialang.org/t/did-julia-community-do-something-to-improve-its-correctness/102515/125 "2023-08-14T06:53:03Z")

</div>

See [What’s the aliasing story in Julia](https://discourse.julialang.org/t/whats-the-aliasing-story-in-julia/102564)

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

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