3 ms·

.minor: Scala does this at a Source level IME. Which depending on your background may mean everything or nothing at all I guess. Most Ruby libs would claim to

by ssmoot 13y ago

.minor: Scala does this at a Source level IME. Which depending on your background may mean everything or nothing at all I guess. Most Ruby libs would claim to follow semantic versioning. I think it's also fair to say there are a lot more mis-steps with compatibility on that side of the fence but I've not seen this argument used there that I can recall. I mean, to be fair, your argument was "large enterprises". Which, means Java. And in that regard you're not wrong since binary compatibility there is a given. Still... As long as you can clone and build the source (it's not like you're buying licenses for UI binary libraries built in Scala after all) I fail to understand why this is a bigger deal than say: String interpolation. Partial Functions. Function Lifting. Type Inference. Type Classes. Tuples. Pattern Matching. The list just goes on and on... The question isn't "Is Scala ready to be the basis for closed source, licensed libraries" after all? If it were then a "we must maintain a decade of binary compatibility" might have a point. Otherwise it feels like a really hollow criticism. I mean, what actual Scala users out there actually want to see Scala 2.11's features put to death on the altar of binary compatibility?

alblue 13y ago
> I mean, to be fair, your argument was "large enterprises". > Which, means Java. And in that regard you're not wrong since > binary compatibility there is a given. Exactly, and that's what Scala is up against. Java 8 will allow Java 7 compiled libraries to run without changes, and though there's a world of difference between Java 8 and Scala, in practice Java 8 gives developers some new features that they'll find useful and more performant than Scala (parallel collections, no implicit casting/conversions etc.) It's also worth noting that 'backwardly compatible' and 'new features' aren't in conflict with each other. Java has had new features added (invokedynamic at the JVM, try-with-resources and string switch in the language layer) but they've still remained binary compatible. The problem is that Scala's approach to new features is to break binary compatibility between 2.x and 2.x+1 releases.

by ssmoot 13y ago

alblue 13y ago

> I mean, to be fair, your argument was "large enterprises". > Which, means Java. And in that regard you're not wrong since > binary compatibility there is a given. Exactly, and that's what Scala is up against. Java 8 will allow Java 7 compiled libraries to run without changes, and though there's a world of difference between Java 8 and Scala, in practice Java 8 gives developers some new features that they'll find useful and more performant than Scala (parallel collections, no implicit casting/conversions etc.) It's also worth noting that 'backwardly compatible' and 'new features' aren't in conflict with each other. Java has had new features added (invokedynamic at the JVM, try-with-resources and string switch in the language layer) but they've still remained binary compatible. The problem is that Scala's approach to new features is to break binary compatibility between 2.x and 2.x+1 releases.