4 ms·

Back when I used to use Scala, the biggest PITA was how every minor version bump you'd run into binary version incompatibilities that you'd only run into at run

Back when I used to use Scala, the biggest PITA was how every minor version bump you'd run into binary version incompatibilities that you'd only run into at runtime. Has that situation changed? I've always felt that Scala the language was always pretty nice, but Scala the ecosystem/tooling was moderately painful to work with. It was getting better over time, but they lost all the momentum they had.

philipkglass 2y ago
Yes, that's one of the big improvements in Scala 3. https://docs.scala-lang.org/overviews/core/binary-compatibility-of-scala-releases.html#guarantees-and-versioning https://docs.scala-lang.org/overviews/core/binary-compatibil... For Scala 3, the minor version is the second number in a version, e.g., 2 in v3.2.1. The third number is the patch version. The major version is always 3. Scala 3 guarantees both backward and forward compatibility across patch releases within a single minor release (enforcing forward binary compatibility is helpful to maintain source compatibility). In particular, this applies within an entire Long-Term-Support (LTS) series such as Scala 3.3.x. Scala 3 also guarantees backward compatibility across minor releases in the entire 3.x series, but not forward compatibility. This means that libraries compiled with any Scala 3.x version can be used in projects compiled with any Scala 3.y version with y >= x. In addition, Scala 3.x provides backward binary compatibility with respect to Scala 2.13.y. Libraries compiled with Scala 2.13.y can be used in projects using Scala 3.x. This policy does not apply to experimental Scala 2 features, which notably includes macros.
dionian 2y ago
yes, and you can even use 2.13 binaries in 3
jeremyjh 2y ago
It still seems bizarre to me that the Java ecosystem relies upon code-sharing through precompiled binary packages. Compared to for example Rust or Elixir where you only download source and build it locally so that everything is built with the same compiler and environment. This makes it absolutely trivial to debug your dependencies and even fork them when necessary. Most Java programmers wouldn't ever dream of doing that.
- senorrib 2y ago
  That's actually a major drawback on Rust to be adopted in enterprise settings. Any GPL library statically compiled would force the entire codebase to be licensed under GPL as well.
  - jeremyjh 2y ago
    GPL can contaminate you when shared as a dynamic library under certain circumstances. But that doesn't matter, since there are few mainstream libraries in these communities licensed as GPL. Nearly all of it is MIT or Apache.
    - imtringued 2y ago
      There is no such thing as contamination. GPL code doesn't change the license of your code. It only prevents you from using GPL code from your code.
      - jeremyjh 2y ago
        This is a distinction without a difference. If I must use it, I’d have to GPL my code.
  - dtech 2y ago
    Whether it's source or a binary doesn't matter. You aren't allowed to use a compiled GPL library in non free code. LGPL was specifically made for that case.
- rat87 2y ago
  Why? It makes a ton of sense. Its been a while but I'm pretty sure decompilation leads to much higher level/understandable code in java/c#. Good enough to step into and debug libraries. And given how fragile/unreproducible it is you almost never want to modify lines in a dependency. In python I'd make a wrapper or monkey patch it instead of modifying the dependency(Or if you need to actually for the library and add it to the dependenies). Unless it was blocking a one of task that I needed done right away.

philipkglass 2y ago

Yes, that's one of the big improvements in Scala 3. https://docs.scala-lang.org/overviews/core/binary-compatibility-of-scala-releases.html#guarantees-and-versioning https://docs.scala-lang.org/overviews/core/binary-compatibil... For Scala 3, the minor version is the second number in a version, e.g., 2 in v3.2.1. The third number is the patch version. The major version is always 3. Scala 3 guarantees both backward and forward compatibility across patch releases within a single minor release (enforcing forward binary compatibility is helpful to maintain source compatibility). In particular, this applies within an entire Long-Term-Support (LTS) series such as Scala 3.3.x. Scala 3 also guarantees backward compatibility across minor releases in the entire 3.x series, but not forward compatibility. This means that libraries compiled with any Scala 3.x version can be used in projects compiled with any Scala 3.y version with y >= x. In addition, Scala 3.x provides backward binary compatibility with respect to Scala 2.13.y. Libraries compiled with Scala 2.13.y can be used in projects using Scala 3.x. This policy does not apply to experimental Scala 2 features, which notably includes macros.

dionian 2y ago

yes, and you can even use 2.13 binaries in 3

jeremyjh 2y ago

It still seems bizarre to me that the Java ecosystem relies upon code-sharing through precompiled binary packages. Compared to for example Rust or Elixir where you only download source and build it locally so that everything is built with the same compiler and environment. This makes it absolutely trivial to debug your dependencies and even fork them when necessary. Most Java programmers wouldn't ever dream of doing that.

senorrib 2y ago
That's actually a major drawback on Rust to be adopted in enterprise settings. Any GPL library statically compiled would force the entire codebase to be licensed under GPL as well.
- jeremyjh 2y ago
  GPL can contaminate you when shared as a dynamic library under certain circumstances. But that doesn't matter, since there are few mainstream libraries in these communities licensed as GPL. Nearly all of it is MIT or Apache.
  - imtringued 2y ago
    There is no such thing as contamination. GPL code doesn't change the license of your code. It only prevents you from using GPL code from your code.
    - jeremyjh 2y ago
      This is a distinction without a difference. If I must use it, I’d have to GPL my code.
- dtech 2y ago
  Whether it's source or a binary doesn't matter. You aren't allowed to use a compiled GPL library in non free code. LGPL was specifically made for that case.
rat87 2y ago
Why? It makes a ton of sense. Its been a while but I'm pretty sure decompilation leads to much higher level/understandable code in java/c#. Good enough to step into and debug libraries. And given how fragile/unreproducible it is you almost never want to modify lines in a dependency. In python I'd make a wrapper or monkey patch it instead of modifying the dependency(Or if you need to actually for the library and add it to the dependenies). Unless it was blocking a one of task that I needed done right away.