# Correctness and Multiple Dispatch (Help explain to a julia noob)

**URL:** <https://discourse.julialang.org/t/correctness-and-multiple-dispatch-help-explain-to-a-julia-noob/128171>\
**Category:** Community\
**Tags:** question\
**Created:** [April 17, 2025, 11:04pm UTC](https://discourse.julialang.org/t/correctness-and-multiple-dispatch-help-explain-to-a-julia-noob/128171 "2025-04-17T23:04:51Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![damiansimon2](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/damiansimon2/32/213449_2.png) [@damiansimon2](https://discourse.julialang.org/u/damiansimon2)\
**Post date:** [April 17, 2025, 11:04pm UTC](https://discourse.julialang.org/t/correctness-and-multiple-dispatch-help-explain-to-a-julia-noob/128171/1 "2025-04-17T23:04:51Z")

</div>

Hello, i hope this is the right place to ask this and this horse hasnt been beaten to death. I am new to Julia and i love JIT compilation and multiple dispatch.  
I recently read (and tried to understand) Yuri Vishnevsky`s Post about “Why I no longer recommend Julia”.  
But no matter how much i try to understand or research it, i dont understand the root of those correctness issues. How exactly does Julias unique design (multiple dispatch, flexibility) lead to those bugs being more common? Is that even true or is it just that Julias libraries are young and not as rigorously tested? What is the root of that repeating discussion?  
thanks

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [April 17, 2025, 11:31pm UTC](https://discourse.julialang.org/t/correctness-and-multiple-dispatch-help-explain-to-a-julia-noob/128171/2 "2025-04-17T23:31:16Z")

</div>

Welcome! Yes, there have been many long threads on this in the past. Here are two comments that I think speaks to your question at a high level, but there are many good responses there:

> [@Discussion on "Why I no longer recommend Julia" by Yuri Vishnevsky](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151/2):
>
> Unfortunately, I think the author is right. I only have experience with Python, Julia and Rust (and a little Perl), but I’ve never encounted even close to as many bugs in other languages as I do in Julia. Both in packages and in Base. The question is why. I think it’s the combination of: A) An extremely generic language where everything is built upon shared abstractions and generic, extendible functions, and B) No way of specifying or checking abstract interfaces, so no-one really knows what …

> [@Discussion on "Why I no longer recommend Julia" by Yuri Vishnevsky](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151/81):
>
> I’m sympathetic to Yuri’s larger point: Julia as a language and ecosystem is permissive by default. You can easily combine packages in ways that are unlikely to work and get mired in the weeds. For example, I can easily imagine attempting to differentiate a distributed SVD of a BlockedArray filled with Unitful Quaternions. Sure, that’s an absurd example and it’s unlikely to work, but I can imagine how it might work and may even be able to construct the problem statement in a few lines of code.…

I will also add that there’s a wide range of dis/agreement with the various points and so this topic can often spark some lively debates.

---

<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:** [April 17, 2025, 11:58pm UTC](https://discourse.julialang.org/t/correctness-and-multiple-dispatch-help-explain-to-a-julia-noob/128171/3 "2025-04-17T23:58:22Z")

</div>

> [@damiansimon2](#):
>
> this horse hasnt been beaten to death

It has, but if the earlier threads weren’t discoverable or didn’t answer your questions, that’s not your fault and you’re free to ask. Just don’t expect the conversation to go as long this time.

> [@damiansimon2](#):
>
> How exactly does Julias unique design (multiple dispatch, flexibility) lead to those bugs being more common? Is that even true or is it just that Julias libraries are young and not as rigorously tested?

First, there are definitely libraries that are staffed by very disciplined and responsive developers that I wouldn’t turn anybody away from; you’re in as good hands as any. However, Julia as a whole has much fewer users and developers and in fewer domains than some languages, so it’s not surprising that those other languages have more reliable libraries for more purposes. This isn’t down to language design and is partially explained by youth, but it’s mainly resources and logistics. The silver lining is that people are working very hard to improve this situation, and it is.

Second, the bulk of the issues came down to the supertype `AbstractArray` expanding its specification/interface. I know you’re new so I won’t explain all the language details, but suffice to say that a type has documented promises on what it’s like and what we’re allowed to do with it. For a while, `AbstractArray` subtypes in Julia, especially the base `Array` type, used 1-based indexing, so that’s what code was written for. However, a subtype of `AbstractArray` could potentially use 0-based or any other linear range for indexing. A lot of code in the ecosystem was extended to accommodate those subtypes, but there were still holes that assumed 1-based indexing (not obvious if not directly indexing!) and would make sometimes silent mistakes, both in base Julia and pre-existing third-party packages. The package `OffsetArray`s for X-based indexing exposed many of those holes, though that’s not really its fault. It’s worth pointing out that many of the cited issues were fixed by the time the blogpost was written, though it’s understandably frustrating to run into older code that retroactively broke a promise. These weren’t fringe packages either, these were well-respected and used in practice; 1-based indexing was just still so common in practice that the holes were tolerable. Again, it takes time and resources to patch these holes, which goes back to my first point, but this problem is not just down to resources.

Third, a few issues showed an expectation of composability that didn’t match reality. Again, you’re new to the language so I’m omitting the finer details, but composability is the ability of independent packages to work together. If you’ve used other programming languages before, you might notice that this is actually a very common feature, but multiple dispatch just makes it easier and more flexible in some ways. Thing is, composability doesn’t just happen naturally; not only do packages need to honor each other’s promises, their internal code had to uphold their own promises in new contexts. New compositions can either expose some very hidden broken promises that even rigorous tests couldn’t catch, or just show that a package could be a bit more flexible than it originally designed it to be. Formal, strictly decided interfaces were mentioned as a possible solution and many do want them for various benefits, but in my opinion, that won’t prevent this issue. No matter the language or how many formal restrictions it provides, writing a broken promise into internal code is just as easy and usually not as obvious as 1-based indexing of `AbstractArray`s. These and other bugs are routinely discovered and patched, and it never stopped any other language with composability from being successful, often more so than Julia. Incompatible packages often error immediately because they don’t have the necessary types for the interfaces; some bigger dynamic languages don’t even have that safeguard.

There are a few more things, but that should cover most of the discussion and it’s what’d you have to care about as a new user.

---

<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:** [April 18, 2025, 12:05am UTC](https://discourse.julialang.org/t/correctness-and-multiple-dispatch-help-explain-to-a-julia-noob/128171/4 "2025-04-18T00:05:03Z")

</div>

I debated whether or not to comment, as this topic indeed has seen a lot of mileage here. However, I do think there is a big factor for the persistence of such discussions that I don’t tend see emphasized (much) in previous threads, which usually seem to focus on the consequences of overly-broad method signatures, ambiguous interfaces, and flexible compositions.

And that factor is, in my view, the _kinds_ of bugs that do occasionally pop up can be things that feel very fundamental / should be bullet-proof, and they also are often seemingly-random regressions of something that worked for a long time. some select examples of these but there are more

- [1.9.2 breaks `map!(|, ...)` on `BitVector`](https://github.com/JuliaLang/julia/issues/50780)
- [`map!` is very broken with inputs of heterogenous sizes](https://github.com/JuliaLang/julia/issues/36235)
- [a simple function of `mod` and `max` returns `NaN` incorrectly](https://github.com/JuliaLang/julia/issues/57119)
  - to be fair, this one never hit a public release

- [an error is not thrown when a seemingly-unrelated loop is removed](https://github.com/JuliaLang/julia/issues/18313)
- [an `UndefVarError` is not thrown when it should be](https://github.com/JuliaLang/julia/issues/57315)
- [another function returns the wrong value instead of erroring](https://github.com/JuliaLang/julia/issues/53062)

---

<div class="post-metadata">

**Author:** ![xiaoxi](https://avatars.discourse-cdn.com/v4/letter/x/a9adbd/32.png) [@xiaoxi](https://discourse.julialang.org/u/xiaoxi)\
**Post date:** [April 18, 2025, 8:25am UTC](https://discourse.julialang.org/t/correctness-and-multiple-dispatch-help-explain-to-a-julia-noob/128171/5 "2025-04-18T08:25:49Z")

</div>

> [@Benny](#):
>
> if the earlier threads weren’t discoverable or didn’t answer your questions, that’s not your fault and you’re free to ask. Just don’t expect the conversation to go as long this time.

I wonder if a blog post or Q&A section on the Julia-lang website about Julia 2.0 and Yuri’s blog post might reduce the number of message threads on these recurring topics.

For example, the Go developers wrote this about Go 2.0:

> There will not be a Go 2 that breaks Go 1 programs. Instead, we are going to double down on compatibility, which is far more valuable than any possible break with the past. In fact, we believe that prioritizing compatibility was the most important design decision we made for Go 1.

> **[Backward Compatibility, Go 1.21, and Go 2 - The Go Programming Language](https://go.dev/blog/compat#go2)**
>
> Go 1.21 expands Go's commitment to backward compatibility, so that every new Go toolchain is the best possible implementation of older toolchain semantics as well.

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [April 18, 2025, 2:49pm UTC](https://discourse.julialang.org/t/correctness-and-multiple-dispatch-help-explain-to-a-julia-noob/128171/6 "2025-04-18T14:49:45Z")

</div>

In addition to the topics and discussions here, there are indeed multiple blogposts on the topic, including:

- [Why we still recommend Julia](https://www.functionalnoise.com/pages/2022-09-07-why-julia-response/) by Matthijs Cox and Jorge Viera
- [Why I still recommend Julia (for Data Science)](https://huijzer.xyz/posts/recommend/) by Rik Huijzer

---

<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:** [April 18, 2025, 3:49pm UTC](https://discourse.julialang.org/t/correctness-and-multiple-dispatch-help-explain-to-a-julia-noob/128171/7 "2025-04-18T15:49:53Z")

</div>

> [@xiaoxi](#):
>
> I wonder if a blog post or Q&A section on the Julia-lang website about Julia 2.0 and Yuri’s blog

Maybe Julia’s FAQ can address the appropriate expectations for a v2, but it’s not appropriate to officially single out one person’s opinion at one point in time. Yuri wasn’t the only person who publicly declared Julia wasn’t worth trying, and it’s one of the better opinions because despite whatever disagreements persistent users may have over the expectations or conclusion, there were constructive criticisms that developers have been taking seriously before and after the post. Also, whether Julia or a third party library of interest has adequately addressed any of those criticisms or generally reached reliability should be discussed in real-time, not be left to an overgeneralizing statement that is likely to become obsolete within months.

---

<div class="post-metadata">

**Author:** ![Tarny\_GG\_Channie](https://avatars.discourse-cdn.com/v4/letter/t/3bc359/32.png) [@Tarny\_GG\_Channie](https://discourse.julialang.org/u/Tarny_GG_Channie)\
**Post date:** [April 21, 2025, 10:08pm UTC](https://discourse.julialang.org/t/correctness-and-multiple-dispatch-help-explain-to-a-julia-noob/128171/8 "2025-04-21T22:08:06Z")

</div>

I feel there is almost this tendency that a language cannot achieve all three: genericity, accessibility, safety. This is due to generic code having assumptions, and the assumptions are hard to state without some sort of abstract algebra, which is inaccessible. So, with accessibility, you either are not generic or not safe. However, not being generic is not an option. There are simply too many combinations of operations you want to do on something and the things you want to operate on. Out of the systems that can automatically generate methods, Julia is as safe as possible. Using generative AI is the other option, and is even riskier.

---

<div class="post-metadata">

**Author:** ![ShalokShalom](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/shalokshalom/32/52462_2.png) [@ShalokShalom](https://discourse.julialang.org/u/ShalokShalom)\
**Post date:** [April 28, 2025, 6:40am UTC](https://discourse.julialang.org/t/correctness-and-multiple-dispatch-help-explain-to-a-julia-noob/128171/9 "2025-04-28T06:40:59Z")

</div>

> [@Benny](#):
>
> For a while, `AbstractArray` subtypes in Julia, especially the base `Array` type, used 1-based indexing, so that’s what code was written for. However, a subtype of `AbstractArray` could potentially use 0-based or any other linear range for indexing. A lot of code in the ecosystem was extended to accommodate those subtypes, but there were still holes that assumed 1-based indexing (not obvious if not directly indexing!) and would make sometimes silent mistakes, both in base Julia and pre-existing third-party packages

Sorry to be so blunt, but this sounds entirely preventable: How can we expand the ecosystem like that, and not expect everything to break?

Also: As far as I understand causes the composition of certain packages error.

Is it possible to automate CI, that checks whatever or not that may be the case? Are there any saveguards in place, to prevent this from happening in an automated fashion?

How do other languages solve that?

---

<div class="post-metadata">

**Author:** ![ShalokShalom](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/shalokshalom/32/52462_2.png) [@ShalokShalom](https://discourse.julialang.org/u/ShalokShalom)\
**Post date:** [April 28, 2025, 6:54am UTC](https://discourse.julialang.org/t/correctness-and-multiple-dispatch-help-explain-to-a-julia-noob/128171/10 "2025-04-28T06:54:06Z")

</div>

> [@Tarny\_GG\_Channie](#):
>
> I feel there is almost this tendency that a language cannot achieve all three: genericity, accessibility, safety.

I found many such “you can only have two out of three” scenarios, they are almost a cultural staple. 🙂

And again and again, do I find that the culprint behind this is the overextension on the two prominent features:

The solution here seems to relax a bit on genericity, in areas where it doesn’t matter in practice.

I would argue, that the genericity to combine packages who dont work with each other is an anti feature, so reducing the capability to do so, is desirable.

Like it used to be with the well tempered piano, that caused Bach to write his just named work.

In previous times, pianos would sound only fine on one single pitch.

A piano maker discovered a way to tune the instruments in such a way, that made the whole range sound fine.

The catch about this is, that the pitch that sounded perfect before, sounded a little bit worse than before, just a tiny amount.

Perfect is the enemy of the good, and hyper fixating on one feature is just a guaranteed way to fail at the other fields.

So I assume when we automate compatibility checks, there will be a few false negatives and a few false positives.

And it will still be worth 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:** [April 28, 2025, 12:04pm UTC](https://discourse.julialang.org/t/correctness-and-multiple-dispatch-help-explain-to-a-julia-noob/128171/11 "2025-04-28T12:04:57Z")

</div>

Things are already automated, but that doesn’t catch problems if tests don’t tell it how, and tests are harder than people think. Not all of the mentioned bugs are immediately apparent when people tried making two packages work together, some of them only happened if they stumbled into niche situations or inherently bad practices. Some problems like the latter aren’t just something to fix, it’s something to debate; do you add unwanted and often unnecessary overheads to evade or stop rare mistakes, or does the documentation inform users how to handle it when they need to? I agree that prevention and safeguards are good, but getting everything right forever on the first try is impossible. A realistic expectation is useful code that is better understood as more people use it in more contexts and provide feedback, which is exactly what’s happening. In my opinion, the argument that there is something missing in Julia or the culture that will prevent or reduce bugs (lumped into the “correctness problem” concept) is not substantiated by the existence of bugs, and none of the loosely suggested changes to interfaces can do anything about many of the listed bugs. It just seems like we need more people and resources to get the work done faster, there’s no easy way out.

Note that none of this contradicts Yuri’s decision to stop recommending Julia or various parts of its ecosystem. If your work is routinely running into bugs and you don’t have the resources to fix them or wait for fixes, you shouldn’t use the software, Julia or not. Contrary to the repeated argument that persistent users and developers showing any confidence in Julia means that issues are minimized and ignored, people are in fact routinely informed about shortcomings (links to Github “issues”, not Github “everything-is-fine-actually”) and more established alternatives outside of Julia, if not outright encouraged to use them instead.

---

<div class="post-metadata">

**Author:** ![Tarny\_GG\_Channie](https://avatars.discourse-cdn.com/v4/letter/t/3bc359/32.png) [@Tarny\_GG\_Channie](https://discourse.julialang.org/u/Tarny_GG_Channie)\
**Post date:** [April 29, 2025, 1:50am UTC](https://discourse.julialang.org/t/correctness-and-multiple-dispatch-help-explain-to-a-julia-noob/128171/12 "2025-04-29T01:50:17Z")

</div>

> [@ShalokShalom](#):
>
> I would argue, that the genericity to combine packages who dont work with each other is an anti feature, so reducing the capability to do so, is desirable.

The packages don’t necessarily don’t want to not work with each others. They might simply not know each others. For example, I once used Forwarddiff on an opensimplex noise from a library and it worked fine.

Moreover, it is nontrivial at all to make functions safe with overloading or multiple dispatch. Semigroup property is a property useful in some data structures, SIMD map-reduce, and maybe a bunch of other things. However, how can you guarantee such property if the implementation could be overridden? (A+B) + C = A+(B+C) might be true for integers, but if you implemented a new int type and it has bugs or peculiarity, would it hold? And Semigroup property is more nuanced than you might think. For some use cases, it holds well enough for floating point numbers to be used. For those dealing with precision arithmetic, it might not. One problem with overriding and multiple dispatch is that some combinations of argument types can bring the output type to another type with no information on the argument type and unknown properties. For example, float32 can be losslessly converted to float64. The Julia type system sees just 2 types abstract float.

---

<div class="post-metadata">

**Author:** ![ShalokShalom](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/shalokshalom/32/52462_2.png) [@ShalokShalom](https://discourse.julialang.org/u/ShalokShalom)\
**Post date:** [April 29, 2025, 1:10pm UTC](https://discourse.julialang.org/t/correctness-and-multiple-dispatch-help-explain-to-a-julia-noob/128171/13 "2025-04-29T13:10:30Z")

</div>

Thanks for clearing that up!

---

<div class="post-metadata">

**Author:** ![ChenNingCong](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chenningcong/32/214654_2.png) [@ChenNingCong](https://discourse.julialang.org/u/ChenNingCong)\
**Post date:** [April 30, 2025, 12:18am UTC](https://discourse.julialang.org/t/correctness-and-multiple-dispatch-help-explain-to-a-julia-noob/128171/14 "2025-04-30T00:18:26Z")

</div>

I also think that checking generic programs is too difficult and a significant burden for programmers. However, if there’s a way to check specific program instances, this would be sufficient to avoid many errors. I mentioned these points in [my Medium article](https://medium.com/@393069484/impossibility-of-correctness-checking-for-generic-numeric-programs-accc0da88102) .

Specifically, library authors could manually mark certain function instantiations to indicate that these instances have been relatively safely tested or proven. For example:

```julia
# a.jl, some generic array
f(x::AbstractArray) = …
# b.jl, some instances
@instance begin
  f(x::Vector{T}) where T
  f(x::Matrix{Float32})
end

```

Then, when calling these functions, if a specialization is not on this list, a warning would be issued. Of course, users could choose to ignore these warnings. This approach not only reduces the burden on library maintainers and users but also facilitates precompilation and testing.