4 ms·

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

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 10y 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.
- airless_bar 10y ago
  Please just read the code. I think it's rather amazing that you claim that Eclipse's immutable collections are memory efficient when they either a) completely lack support for many important operations like appending and prepending, or b) implement operations like drop and take by not reusing anything, but copying everything over. None of the code written by people using immutable data structures would work with this API. It feels like it's an immutable collection API designed by people who have never used immutability before. It has this weird 0th-generation immutable == read-only style to it. Yeah, if you use those collections as if they were arrays, then they might be memory efficient, I give you that. But then why not use arrays in the first place? And then the next question comes up ... why even bother with Java? Use Rust, and do away with the defensive copying altogether. Coding like this is just using the wrong technology for the job.

jkot 10y 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.

airless_bar 10y ago
Please just read the code. I think it's rather amazing that you claim that Eclipse's immutable collections are memory efficient when they either a) completely lack support for many important operations like appending and prepending, or b) implement operations like drop and take by not reusing anything, but copying everything over. None of the code written by people using immutable data structures would work with this API. It feels like it's an immutable collection API designed by people who have never used immutability before. It has this weird 0th-generation immutable == read-only style to it. Yeah, if you use those collections as if they were arrays, then they might be memory efficient, I give you that. But then why not use arrays in the first place? And then the next question comes up ... why even bother with Java? Use Rust, and do away with the defensive copying altogether. Coding like this is just using the wrong technology for the job.