# Could we wrangle breaking changes by moving the old code from core out to a library and let multiple dispatch handle it?

**URL:** <https://discourse.julialang.org/t/could-we-wrangle-breaking-changes-by-moving-the-old-code-from-core-out-to-a-library-and-let-multiple-dispatch-handle-it/132265>\
**Category:** New to Julia\
**Tags:** question\
**Created:** [September 10, 2025, 9:18pm UTC](https://discourse.julialang.org/t/could-we-wrangle-breaking-changes-by-moving-the-old-code-from-core-out-to-a-library-and-let-multiple-dispatch-handle-it/132265 "2025-09-10T21:18:21Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![rnblough](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rnblough/32/22143_2.png) [@rnblough](https://discourse.julialang.org/u/rnblough)\
**Post date:** [September 10, 2025, 9:18pm UTC](https://discourse.julialang.org/t/could-we-wrangle-breaking-changes-by-moving-the-old-code-from-core-out-to-a-library-and-let-multiple-dispatch-handle-it/132265/1 "2025-09-10T21:18:21Z")

</div>

I was reading a blog post [extolling the virtues of multiple dispatch and Pkg.jl](https://viralinstruction.com/posts/goodjulia/#multiple_dispatch_is_correct_everything_else_an_approximation) alongside a post about [what’s bad in Julia](https://viralinstruction.com/posts/badjulia/) from the same place, and a thought occurred to me:

Imagine some library implemented a different solution for core language functionality that was so amazing people wished it was how core worked all along. Why can’t we just sort of . . . swap them out, and use multiple dispatch to cover it for backwards compatibility purposes?

The idea is that any time a breaking change would be introduced, the initial core code that got changed is broken out into OldCoreCodeName.jl; so the new amazing library code gets integrated into core, and the old core code gets spun out into a library, “swapping places,” which is fine because multiple dispatch.

It’s too simple to work, no doubt, and there’d be a fair few other changes to the language release process to account for it, but I can’t pinpoint exactly where it breaks.

---

<div class="post-metadata">

**Author:** ![cjdoris](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cjdoris/32/213133_2.png) [@cjdoris](https://discourse.julialang.org/u/cjdoris)\
**Post date:** [September 10, 2025, 9:44pm UTC](https://discourse.julialang.org/t/could-we-wrangle-breaking-changes-by-moving-the-old-code-from-core-out-to-a-library-and-let-multiple-dispatch-handle-it/132265/2 "2025-09-10T21:44:07Z")

</div>

Can you give an example of what you’re thinking of showing how multiple dispatch would help?

---

<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:** [September 10, 2025, 10:06pm UTC](https://discourse.julialang.org/t/could-we-wrangle-breaking-changes-by-moving-the-old-code-from-core-out-to-a-library-and-let-multiple-dispatch-handle-it/132265/3 "2025-09-10T22:06:48Z")

</div>

> [@rnblough](#):
>
> Imagine some library implemented a different solution for core language functionality

Already possible, e.g. you can use MKL.jl to replace OpenBLAS default, bundled with Julia (libblastrampoline makes it happen, not multiple dispatch I believe though).

I’ve suggested simply dropping OpenBLAS (and thus LinearAlgebra module from Julia; and actually a lot more), since not needed for Julia itself, nor needed by of Julia’s users; to also make Julia somewhat lighter (less memory use on startup at least, that though likely doesn’t cost much, only VIRT mem not delay).

Note if you compare to e.g. Python, Julia has more built-in with LinearAlgebra/OpenBLAS (C++ is also adding BLAS), so more fair to compare to Python plus NumPy, for functionality and bugs. Also not fully fair, since the reverse is true, Python (and C++) has stuff in its stdlibs Julia does not like, by now, ordered dicts by default; Julia has too available from OrderedCollections.jl FYI (Python doesn’t have anything important I know of Julia doesn’t have in packages; from its stdlibs; note also you can use PythonCall.jl).

You might not be asking exactly about this, but if Julia is criticized for bugs, a lot can go and bugs with it (not saying LinearAlgebra has many, on the contrary). Yes, you would be shifting bugs to another repo/package.

My idea for restoring full compatibility if we drop/break intentionally too much is you could recover full compatibility with:

```julia-auto
using Julia1

```

This thing with LinearAlgebra needs not actually be a breaking change (I want to get rid of `BigFloat`s, also redundant with better options, and more too):

> <https://github.com/JuliaLang/julia/pull/50699>
>
> These have been deprecated for a long time, users should instead use
> \`LinearAlg…ebra.BLAS.libblas\` or \`LinearAlgebra.BLAS.liblapack\`.
> 
> This will be necessary once we have lazy JLLs, as it's not desirable to
> recreate the dependency graph in \`Base\`, we already have it in standard
> libraries, and only load libblastrampoline when \`LinearAlgebra\` starts
> doing ccalls.

A lot has been put off, moved into the 2.0 milestone as too breaking (some technically breaking changes have gone through, maybe not enough e.g. this next one should just be implementing since breaking is safer):

> <https://github.com/JuliaLang/julia/issues/56294>
>
> It would be nice if \`=\` was required instead of optional for flags with argument…s. This would make the following behavior error:
> 
> \`\`\`
> x@x:~/test$ julia --trace-compile --banner=no
> \_
> \_ \_ \_(\_)\_ | Documentation: https://docs.julialang.org
> (\_) | (\_) (\_) |
> \_ \_ \_| |\_ \_\_ \_ | Type "?" for help, "\]?" for Pkg help.
> | | | | | | |/ \_\` | |
> | | |\_| | | | (\_| | | Version 1.11.1 (2024-10-16)
> \_/ |\\\_\_'\_|\_|\_|\\\_\_'\_| | Official https://julialang.org/ release
> |\_\_/ |
> 
> julia\> 
> x@x:~/test$ ls
> '--banner=no'
> x@x:~/test$ cat -- --banner=no
> precompile(Tuple{typeof(Base.print), Base.TTY, String})
> \`\`\`
> 
> Motivated by #56285

You can simply avoid using some of the Julia API, which is dangerous (for aliasing, i.e. if you don’t know what that is); another option would be dropping from Julia (not all, but still some of the “correctness bug” labelled could be fixed" that way…):

> <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
> \`\`\`

> [@rnblough](#):
>
> a post about [what’s bad in Julia](https://viralinstruction.com/posts/badjulia/) from the same place

Some or lot of they post may be outdated; AI tells me

> In Julia, an “option type” refers to a way of representing a value that may or may not be present, typically by using a Union{T, Nothing} type alias

---

<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:** [September 10, 2025, 11:18pm UTC](https://discourse.julialang.org/t/could-we-wrangle-breaking-changes-by-moving-the-old-code-from-core-out-to-a-library-and-let-multiple-dispatch-handle-it/132265/4 "2025-09-10T23:18:15Z")

</div>

I think that post is still fairly relevant. `Union{T, Nothing}` is not a good substitute for option types

---

<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:** [September 11, 2025, 1:23am UTC](https://discourse.julialang.org/t/could-we-wrangle-breaking-changes-by-moving-the-old-code-from-core-out-to-a-library-and-let-multiple-dispatch-handle-it/132265/5 "2025-09-11T01:23:03Z")

</div>

No, and you’re likely misunderstanding what a breaking change is or what multiple dispatch can do. A breaking change is about API: public names, functions, types, and their properties. You can freely change the internal implementation without changing the API or affecting existing code e.g. backing `Array` with `Memory`. If the change is so radical that existing code doesn’t have the same properties anymore, then it is by definition a breaking change. Moving the previous implementation into another library fundamentally involves a new and separate API (importing the library at minimum), and needing to rewrite code does not solve breaking changes, it’s just part of it. Multiple dispatch cannot remove that need to rewrite code, it actually facilitates polymorphism over new types.

What people actually do is introduce new standard practices with new API and _deprecate_ the obsolete stuff. Existing code would still work, nothing gets broken, but there’s the reminder to move on to newer better things. Doing this very often makes for a very unstable API, so it’s better to keep this to a minimum and in more expendable dependencies.

---

<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:** [September 11, 2025, 11:44am UTC](https://discourse.julialang.org/t/could-we-wrangle-breaking-changes-by-moving-the-old-code-from-core-out-to-a-library-and-let-multiple-dispatch-handle-it/132265/6 "2025-09-11T11:44:49Z")

</div>

I actually meant to link OptionType.jl from a fuller quote from AI. I’m not sure why it got cut short and I no longer have it exact, it was from Google search), but it said “typically” yes, then pointed to that package in my recollection. New AI search now states the former is “idiomatic” (likely correct, needs not be better though, nor best options, no pun intended, need by in Base can rather be in a package…).

Since you have similar to Rust available, that’s why I meant to say the blog is partially outdated.

---

<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:** [September 11, 2025, 12:20pm UTC](https://discourse.julialang.org/t/could-we-wrangle-breaking-changes-by-moving-the-old-code-from-core-out-to-a-library-and-let-multiple-dispatch-handle-it/132265/7 "2025-09-11T12:20:38Z")

</div>

I don’t know how I’d call a 50 LOC, 1 star, 0 dependents package “idiomatic.” maybe AI isn’t always correct?

the value of option types is not just the existence of an type with an `unwrap` method. it’s the integration into all the various design APIs

---

<div class="post-metadata">

**Author:** ![rnblough](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rnblough/32/22143_2.png) [@rnblough](https://discourse.julialang.org/u/rnblough)\
**Post date:** [September 11, 2025, 12:50pm UTC](https://discourse.julialang.org/t/could-we-wrangle-breaking-changes-by-moving-the-old-code-from-core-out-to-a-library-and-let-multiple-dispatch-handle-it/132265/8 "2025-09-11T12:50:11Z")

</div>

Great response, I think you struck the heart of my confusion! The second you mentioned the API I suddenly questioned how the list of methods the dispatch mechanism considers is built, so it is definitely a case of misunderstanding dispatch _and_ breaking changes.

So now I am off to look into the underlying mechanisms of multiple dispatch, and finally have a sufficiently motivational reason to understand how APIs work. I don’t know why I haven’t done this before, really; everyone knows it’s a fundamental concept to how computing works. Anyhow, thank you!