3 ms·
No, this is incorrect, you are confusing backwards and forwards compatibility. Running your new code on old Julia versions could break immediately, just like in
by DNF2 6y ago
No, this is incorrect, you are confusing backwards and forwards compatibility. Running your new code on old Julia versions could break immediately, just like in every programming language.
Backwards and forwards compatibility have very different horizons.
Running old code on new Julia versions should not break until the next major version. Packages, on the other hand, are different, and could break your code sooner, but that's the same in any language.
- eigenspace 6y agoYeah, I just feel compelled to echo you. What that person said is very wrong. I guess that in a language without a good version bounding and manifest system like julia, it could be a semi-valid point because you might end up updating your packages and breaking your code that way, but julia has reproducible package environments, so you can get very strong guarantees about backwards compatibility even when you're updating packages.
- enriquto 6y agoDudes, relax, it's just a heuristic, a rough zeroth-order estimate to measure the pace of evolution of a language.
- eigenspace 6y agoEven to zeroth order, this is a bad way to estimate backwards compatability. It's a fine way to estimate pace of language evolution, but that wasn't your claim. For instance, Fortran 2018 has new features that would fail if you tried to use them in Fortran 2015. However, Fortran 2018 is still backwards compatible with Fortran 2015, and indeed is backwards compatible with Fortran 1977. That is, in this example Fortran maintains 42 years of backwards compatability, yet only 3 years of forwards compatability. The two things are effectively decoupled from eachother.