> Scala defines its own set of collection classes [...]
And that is a huge benefit. Scala collections are really great.
In addition, Scala also has wrappers around Java collections for interop, or you can just use plain Java collections directly.
And that is a huge benefit. Scala collections are really great.
In addition, Scala also has wrappers around Java collections for interop, or you can just use plain Java collections directly.
It doesn't really matter how great they are, it kills JVM interop right there ... and its even worse if it doesn't and you get implicit conversions killing your performance.
This is where there is a bit of bait and switch with the JVM story (applies to a lot of JVM languages) - "language has great feature X" and "use any library from the JVM ecosystem" - often turn out to be mutually exclusive in a practical sense. Groovy is the only JVM language I've found that seems to deliver a real JVM interop story, but that's explicitly because it is designed from the ground up for that.
Have you tried Kotlin yet? If so, what interferes with its JVM interop story in your opinion? I'm happily using Kotlin with several Java libraries, and IIRC, no Kotlin-specific libraries except for the stdlib.
That's extreme. It really doesn't "kill" interop at all. If you want to convert, convert. There are many cases where you are not calling Java in hot paths and where converting is perfectly acceptable. If you don't want to, then don't and use Java collections directly. You have the best of both worlds depending on what kind of code base and libraries you are dealing with
Also, implicit conversions between Scala and Java collections have been discouraged/deprecated for years now. You should use the explicit conversion when needed, with `.asScala` or `.asJava`. This makes it obvious whether you might pay a price in the conversion.
Finally, your position overlooks the fact that there are solid reasons to use and prefer Scala collections instead of Java collections: they are quite feature-rich compared to Java collections, are immutable by default, while providing mutable collections if you want those as well.
> that's explicitly because it is designed from the ground up for that
Scala was designed for Java interop from the get go. I am not sure how you are suggesting making things better, besides saying that Scala should never have had its own collections. That would take away a huge part of what makes Scala great, in my book.
It's not in a "trivial sense". You can call any Java code from Scala, call Scala code from Java (except when dealing with Scala constructs that don't have direct Java equivalents). Even Java and Scala functions are the same since Java 8/Scala 2.12. I am not sure how much more interoperability you could even wish again, besides saying that Scala should be identical to Scala. And I write this having written Scala for 10 years and used dozens of Java libraries in Scala projects.
> because of its insistence on using its own collections
This reads like Scala is somehow doing this stubbornly against all reasonable arguments. That's not the case. Scala collections have benefits. Maybe this means using Hibernate is not straightforward from Scala. Ok. I don't know. But this doesn't invalidate Scala having its own collections.
There are tradeoffs in everything. We are talking about two languages and how they interoperate. As far as language integrations go, the Java-Scala interop is excellent, in my view.