Hacker News Reader

Comment by halfmatthalfcat | Hacker News Reader

I believe Scala's are as well, this seems to be a pretty complete list:

https://www.scala-lang.org/api/2.13.5/scala/jdk/javaapi/Coll...

Kotlin's STDLIB collection types are essentially aliases for the Java types. So while the Scala adapters are low-cost, in Kotlin everything's zero-cost.

One other benefit of that is you maintain object identity. I don't think that Scala's wrappers do that.

Scala has the full suite of Java collections without any conversion or overhead whatsoever.

But it also has Scala collections. With scala collections you get the full power of the Scala type system, as well as a much richer and full featured collections api. So most scala programmers won't bother with java collections unless they have specific java interop requirements.

The Scala adapters are merely ways of converting java collections to scala collections and vice versa.

I think it's a fair complaint that in Scala it is a pain in the ass to deal with Java collections. You have to litter your whole code with `.asScala` and `.asJava`, the java collections don't work with for comprehensions, etc.

It's only a problem if you can't decide which part of your project to write with which language.

If I have to use Java, I put it into a separate sub-project and make sure that I have a nice API to interface between the subprojects. `.asJava` and `.asScala` then only appear at very specific places where the interop happens.

What you're describing is in and of itself a severe cost and barrier to the very thing we're describing: interoperability between Java and Scala collections. On the one hand you have Scala where you either have to constantly `.asScala` and `.asJava`, or go your route of ensuring that in any given module only deals with either Scala or Java collections. This may involve additional abstractions or classes to achieve. On the other hand you have Kotlin which just directly, frictionlessly deals with Kotlin/Java collections the same way (in fact, they literally are the same). We're comparing "some small-to-medium cost" against "zero-cost".

Or an other way of saying it is that your approach of walling off modules as either java-collection or scala-collection is kind of like saying "Java and Scala collections work well together, so long as you don't have to use them together too much. If you minimize how much they need to interoperate, the problem is not so bad."

> Or an other way of saying it is that your approach of walling off modules as either java-collection or scala-collection is kind of like saying "Java and Scala collections work well together, so long as you don't have to use them together too much. If you minimize how much they need to interoperate, the problem is not so bad."

Yes, that's actually a very good way to rephrase it. That being said; I myself wouldn't limit that to just the collections; Java and Scala on the language level have excellent interop. For Scala-the-ecosystem the story is a bit different.

Java is not the primary target for most of the Scala libraries. Not even a secondary one, I dare say. (I'm not even sure how you would model a Java API for a library - say; Cats - that uses implicits for the heavy lifting.)

That of course stems for the fact that Scala makes use of concepts that have no correspondence in neither Java or Kotlin, so there will necessarily be something lost in translation.

No, it's not hard. In Scala, you are completely free to use those java collections and you can do it exactly how kotlin programmers do it. You want a java list, without any need to convert back and forth between Scala and Java? Import `java.util.List`. All of the same methods and iterators and expressions and constructs are still there. You get all of the lack of capabilities and grace that the java collections provide. Literally no different from using the same collections in Kotlin.

The problem is that those java collections suck in comparison to the Scala collections. So Scala programmers prefer to use Scala collections. Scala programmers would never willfully use java collections if they don't have to, and if they absolutely have to, they have minimal overhead conversions back and forth. The minimal conversion overhead is the price they're willing to pay to use better collections while maintaining java interoperability.

Except Kotlin enjoys the compatibility with Java, plus it outfits those java collections with extension methods and some compiler tricks to achieve all the same functionality as the Scala collections (in fact, I would say even more self-consistent and useably than in Scala). Just as in Scala, in Kotlin you can use functional transforations that Scala users are so accustomed to:

Kotlin:

    listOf(1,2,3,4)
        .map{i -> i + 1}
        .filter { it % 2 == 0 }
        .flatMap { listOf(it, it * 2, it * 3) }

Kotlin even has a similar take to Scala's views, which they call sequences:

    listOf(1,2,3,4)
        .asSequence()
        .map{i -> i + 1}
        .filter { it % 2 == 0 }
        .flatMap { listOf(it, it * 2, it * 3) }
        .toList()

Is this really so "lacking in capability and grace" compared to Scala? The only think missing is persistent immutable collections, which are implemented in kotlinx.

> The only think missing is persistent immutable collections, which are implemented in kotlinx.

You said:

> You have to litter your whole code with `.asScala` and `.asJava`, the java collections don't work with for comprehensions, etc.

So how does kotlinx achieve zero-cost compatibility with Java collections without having something like `.asKotlin` and `.asJava`? Because otherwise there is no difference between Scala and Kotlin in this regards.

because the persistentList/Collection/etc in kotlinx implement the appropriate java collection interfaces:

    import java.util.List;

    public class Foo {
        public static void blah(List<Integer> list) {
        }
    }

Kotlin:

    import kotlinx.collections.immutable.persistentListOf

    fun main(): Unit {
        Foo.blah(persistentListOf(1,2,3))
    }

This compiles fine

Reply on news.ycombinator.com