3 ms·

I would add that Kotlin has excellent compatibility with Java and you can use thousands if not millions existing libraries. Other JVM languages such as Scala or

• airless_bar 11y ago
  Scala tried to do the thing Kotlin invented for years. The effort was abandoned, because it just doesn't work. Mutable collections plus readonly interfaces gives you the worst of all imaginable worlds.
  • jkot 11y ago
    And Scala immutable collections are memory hog and GC nightmare. I find good compromise with Kotlins read-only interfaces and Eclipse Collections optionally immutable collections
    • airless_bar 11y ago
      That doesn't make any sense. Did you have a look at how they are implemented in Scala? Nothing is a worse memory hog and GC nightmare than mutable collection behind immutable interfaces. - They cannot be implemented efficiently. - They give you zero guarantees. You got a "readonly" collection? Let's start praying that everyone got the readonly thing, too, and not the mutable instance instead. - Operations cause full-scale copies (talk about a GC nightmare). - Collections cannot share structure. - And the API is a lying mess in Eclipse collections, e. g.: https://github.com/eclipse/eclipse-collections/blob/master/eclipse-collections/src/main/java/org/eclipse/collections/impl/collection/immutable/AbstractImmutableCollection.java#L65 https://github.com/eclipse/eclipse-collections/blob/master/e... People have already tried to get these things working for years. It just doesn't work. Please explain what's different this time around.
      • jkot 11y ago
        For example Scala Map uses Brie. On each update it creates new tree, while old tree still hogs memory. Immutable EC collections are way more optimized. EC immutable API is a mess because it implements mutable java.util.Collection. I like Kotlin because it removes this mess.
        • airless_bar 11y ago
          Please, really read the code. What you are claiming is wrong, and makes you look like as if you have no clue what you are talking about. While Kotlin addresses the last point I made, it still suffers from: - They cannot be implemented efficiently. - They give you zero guarantees. You got a "readonly" collection? Let's start praying that everyone got the readonly thing, too, and not the mutable instance instead. - Operations cause full-scale copies (talk about a GC nightmare). - Collections cannot share structure.
          • jkot 11y ago
            Read my profile. I literally design and implement memory efficient java collections for living. I also worked with Scala for 7 years, including compiler and IDE. First I agree that Collections.immutableMap(map) has many problems. EC immutable collections are usually implemented using single array and are very memory efficient, There are also primitive versions, specialized Sets etc.. http://www.goldmansachs.com/gs-collections/presentations/GSC_Memory_Tests.pdf http://www.goldmansachs.com/gs-collections/presentations/GSC... EC immutable collections are not just wrappers. They are different implementations and can not be modified. Modification API is there for compatibility and throws an exception. Full stack copies are necessary. But from GC perspective there is a huge difference between single array and complex tree of references. Array allocation and array copy is pretty effective on JVM. Also Scala collection creates long lived garbage, while defensive copy creates short lived garbage. Second case is much easier on GC. In EC collections can share referenced immutable objects (Strings, numbers..). That is probably 90% data, array itself is pretty memory efficient and does not have to be shared.
            • 11y ago