3 ms·

> (3) Are the features mature enough that I don't anticipate major rewrites for code each year? There is a very good heuristic for that. Write a non-trivial p

> (3) Are the features mature enough that I don't anticipate major rewrites for code each year? There is a very good heuristic for that. Write a non-trivial program using the last version of the language and according to current conventions. Then look how far can you go into past versions of the language so that your program runs correctly. If the oldest version of the language that runs your program is X years old, then you can expect your program to stop running after X years in the future.

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 ago
  Yeah, 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 ago
    Dudes, relax, it's just a heuristic, a rough zeroth-order estimate to measure the pace of evolution of a language.
    - eigenspace 6y ago
      Even 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.

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 ago
Yeah, 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 ago
  Dudes, relax, it's just a heuristic, a rough zeroth-order estimate to measure the pace of evolution of a language.
  - eigenspace 6y ago
    Even 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.