[theLiminator]

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]

Yes, that's one of the big improvements in Scala 3.

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.

[jeremyjh]

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.

[phendrenad2]

Give it another look, it's actually quite nice. The issue you find with it doesn't come up that often in practice. Most of the time (99.9+%) you can find the source code to a specific JAR easily. Want to fork or modify? No problem, just edit he code, compile a new JAR, drop it somewhere. Done. It's like if the intermediate code to your favorite language's JIT were shippable (I'm actually surprised more languages don't do this).

[senorrib]

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.

[dtech]

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.

[jeremyjh]

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]

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]

This is a distinction without a difference. If I must use it, I’d have to GPL my code.

[rat87]

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.

[Kwpolska]

Java IDEs can debug third-party code just fine with decompilation. C# IDEs can get the original source code (https://www.jetbrains.com/help/rider/Debugging_External_Code...). Having to build all dependencies would be slower with no significant benefit, especially since the code compiles to bytecode, not native code. Forking is also doable, e.g. with an internal package feed (and you don’t need to integrate your build stuff with theirs).

[dingi]

Isn't this due to inherent limitations of native binaries? Java has very few native dependencies, so its trivial to do binary dependencies. Besides, most packages in maven central have their sources in there as well. You can easily download the source package and let the debugger use that.

[jeremyjh]

No, had nothing to do with native dependencies, they are even more rare in Elixir than Java. It’s simply a different choice in the design.

I know that I can step into a source package with the debugger, but editing that source and rebuilding doesn’t compile the change into my build does it? The last step of debugging is fixing the code, its much more convenient to first try this in the same project where you encountered it.

[dionian]

yes, and you can even use 2.13 binaries in 3