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.
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:
using Julia1
This thing with LinearAlgebra needs not actually be a breaking change (I want to get rid of BigFloats, also redundant with better options, and more too):
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):
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…):
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
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.
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.
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!