It is discouraged to override internal internal functions, hence, one often only needs to monitor the public API changes of packages as in every other programming language. Updates for packages in my experience rarely had broke stuff like that. Updates in Base somrimes can cause issues like that, but those are thoroughly tested on most popular registered packages before a new Julia version is released.
Interfaces could be good as intermediaries and it is always great to hear JuliaCon talks every year on the best ways to implement them.
> Imagine you try to move a definition from one file to another. Sounds like a trivial piece of organization, right?
In my experience it’s most trivial. I guess your pain points may have come by making each file as a module and then adding methods for your own types in different module and then moving things around is error prone. The remedy here sometimes is to not make internal modules. However the best solution here is to write integration tests which is a good software development practice anyway.
So
In Julia, the (+) function is commonly overloaded
The [] is as well. For things that have no shared interface. (E.g.: Int64[1][1] contains two calls to the [] generic function, which have no interface in common.)
Plenty of definitions of (+) are not commutative. E.g.: for strings.
There is some package which uses the (+) generic function internally, meant to be used on numbers. You call it instead with some kind of symbolic expression type. And it just works. Yay! This is the kind of stuff Julia afficcionados preach.
Then suddenly the package gets updated so that it uses (+) in a way which assumes commutativity.
Your code breaks.
In your world, how would you be notified of a change that some internal use of the (+) function now assumes commutativity?
Or when Julia afficionados preach the amazingness of being able to just throw a differential operator or matrix or symbolic whatever in a place, are they just overselling something and should stop?