3 ms·

> In a production system, Scala is quite frustrating to work with because of the frequent backwards compatibility breaks ... and this gets exponentially worse

> In a production system, Scala is quite frustrating to work with because of the frequent backwards compatibility breaks ... and this gets exponentially worse if you depend on a lot of scala libraries. That's one reason that I absolutely abhor depending on anything Scala in my own Scala projects. Now, I'm not fanatical about it, but if there's an equivalent Java library with a reasonable interface then I'll definitely prefer that. I can understand that maintaining binary compatibility is incredibly difficult for the Scala devs, but they really should have provided an easier way to just BUILD YOUR DEPENDENCIES FROM SOURCE[1] if it cannot find suitably binary-compatible dependencies. This would also ease the adoption of scala.js with its own forks/ecosystem for e.g. scalaz hugely. In practice everything I'm depending on is going to be open source and could just be fetched + built on demand rather than me having to wait for upstream to build + publish a new version. Usually people are considerate enough to not break source-compatibility willy-nilly, but predicting what will break binary compatibility is Dark Magick... which means that few people actually do that in practice. [1] This is one of the very few things the Haskell/Cabal ecosystem got right from the start. It allows the compiler to evolve incredibly fast by just outright ignoring binary compatibility.

lmm 11y ago
Mima is probably the most advanced binary compatibility checker anywhere. Not everyone's using it, but projects that do can provide very good guarantees. Given that many dependencies are Java and there's no agreement on build tooling, it'd be hard to build all dependencies from source (I actually had a client look seriously into doing this). I mean given a maven project, the pom is included in the release and contains all the information (e.g. SCM tag) necessary to rebuild it. But not everyone's using maven.
- lomnakkus 11y ago
  > Mima is probably the most advanced binary compatibility checker anywhere. Not everyone's using it, but projects that do can provide very good guarantees. Certainly, but that's not what I was talking about is it? My point was that there isn't a culture (in the JVM world) of just publishing the source. If there was there would be no problems other than source-incompatibility. The culture in Haskell-land is that either a) you publish the sources or b) you deal with whatever pain may come your way. Mostly, people have followed approach a) when it comes to things like "parse JSON fast/reliably" (aeson), but b) when it comes to "oh, this is our trading platform/strategy". Which is fine... but the ecosystem usually benefits from the a) side of things. (Shout out to Bryan o'Sullivan.)

lmm 11y ago

Mima is probably the most advanced binary compatibility checker anywhere. Not everyone's using it, but projects that do can provide very good guarantees. Given that many dependencies are Java and there's no agreement on build tooling, it'd be hard to build all dependencies from source (I actually had a client look seriously into doing this). I mean given a maven project, the pom is included in the release and contains all the information (e.g. SCM tag) necessary to rebuild it. But not everyone's using maven.

lomnakkus 11y ago
> Mima is probably the most advanced binary compatibility checker anywhere. Not everyone's using it, but projects that do can provide very good guarantees. Certainly, but that's not what I was talking about is it? My point was that there isn't a culture (in the JVM world) of just publishing the source. If there was there would be no problems other than source-incompatibility. The culture in Haskell-land is that either a) you publish the sources or b) you deal with whatever pain may come your way. Mostly, people have followed approach a) when it comes to things like "parse JSON fast/reliably" (aeson), but b) when it comes to "oh, this is our trading platform/strategy". Which is fine... but the ecosystem usually benefits from the a) side of things. (Shout out to Bryan o'Sullivan.)