Julia is setup a lot better than Python in these respects for two major reasons.
One is immutability. Especially with the Pkg server, the Julia v1.0 world has large amounts of immutability. What happens in the Python world is that packages tend to roam pretty free, so without constantly keeping up to date you won’t have a working installation. Pip is terrifying. And it can be hard to recreate an environment of 3 years ago.
While upper bounds cause their own problems, one thing that is clear is that there are so many upper bounds in the Julia ecosystem that old things won’t move. In DifferentialEquations.jl, Julia v1.0 will should get the same installation that has been there for a few years now. It won’t have the fancy new neural PDE stuff, but hey, the ODE/SDE/etc. software is still there. When Turing.jl decides to cut compability, that doesn’t mean it will go away, it just means there will be an immutable version that is there for people to rely on essentially indefinitely, unchanged. In those regards, being able to recreate past environments is really strong in Julia, which allows developers of packages to keep moving forward even if users don’t want to, and that separation isn’t bad it’s quite good! What the article is pointing out is that Google explicitly is not allowing that, partially because infrastructure is very different from package ecosystems, but also because of a philosophical difference. The core developers of Pkg have been very clear about this immutability, and it is something that many groups rely on. So upgrade Julia and package versions at your own pace: that’s how it’s designed and it’s okay!
But secondly, because of the pre-1.0 times being hectic in a universe where the competitors were well-established, Julia had to build a lot of infrastructure to help developers to upgrade. Femtocleaner, Compat.jl, @deprecated, etc. I’d estimate that 90% of major version upgrades are automated. Are there still issues that can come up? Yes, they always can and they always will. But, (a) immutability means that if you need something working today, use the old version and that’s okay, and (b) the vast majority of the changes are handled by automated or semi-automated tooling provided by the core development, and are extensible in a way so that package developers also get similar tooling for their users. One of the main issues in the Python 2 → Python 3 change was the lack of such tooling: it was considered the developer’s problem to upgrade, not the language author’s problem. I think everyone on the core team feels it to be part of their duty to ensure that updating versions is as smooth as possible, even during breaking changes like v1.0, and that’s a major philosophical difference (though to finalize the Python 3 change, the philosophy in the Python world had to change too!).
Moral of the story is, there’s still a high velocity in the Julia world, but I feel pretty comfortable. The other day I picked up someone’s blog post from 2017 or 2018 and took their ODE model and it created the same plot. Things move fast and DiffEq/SciML may be moving one of the fastest, but model codes still work.
