
Why Kotlin is my next programming language - jaxondu
https://medium.com/@octskyward/why-kotlin-is-my-next-programming-language-c25c001e26e3
======
jkot
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 Clojure have their own libraries and that makes integration harder.

~~~
airless_bar
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
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
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/e...](https://github.com/eclipse/eclipse-
collections/blob/master/eclipse-
collections/src/main/java/org/eclipse/collections/impl/collection/immutable/AbstractImmutableCollection.java#L65)

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
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
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
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...](http://www.goldmansachs.com/gs-
collections/presentations/GSC_Memory_Tests.pdf)

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
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.

