4 ms·
No, I meant binary compatibility. Upgrading to a newer version always required recompiling all dependencies. One dependency didn't get an update and you were es
by pkolaczk 3y ago
No, I meant binary compatibility. Upgrading to a newer version always required recompiling all dependencies. One dependency didn't get an update and you were essentially locked on the old version. Some projects took years to upgrade from 2.11 to 2.12 and then 2.12 to 2.13 e.g Spark. This was a real pain for us.
Source compatibility based model would be ok if Java/Scala build systems worked like Cargo/Go/Npm and compiled dependencies from sources. However, that would make compile times orders of magnitude worse, and they were already unacceptable without it. I remember our project that had about 30k lines of Scala and 300k lines of Java took about 7-12 minutes to build from scratch (and the biggest contributor of compile time was scala). And we didn't even use advanced and slow stuff like macros or typelevel programming. I remember we were seriously looking into stuff like keeping the compiler in memory between the runs (thanks Bloop) and that made it much better although it came with it's own set of new problems.
Comparably on the same (now outdated) hardware Rustc is able to compile 500k lines of all dependencies in about 28 seconds (including linking).
- lmm 3y ago> One dependency didn't get an update and you were essentially locked on the old version. Some projects took years to upgrade from 2.11 to 2.12 and then 2.12 to 2.13 e.g Spark. This was a real pain for us. Spark is a special case though - it really was just Spark, and you can't really compare that to something like Rust where as far as I know there's no equivalent. Everything else that was maintained at all put out cross-builds very quickly once the changes between versions got to be small.