Hi Oleksii, nice article! I don't have any experience of JVM languages (just a bit of super obsolete Java knowledge) but I still enjoyed your article. For the sake of argument and because I love languages can I ask you which other languages are you referring to in comparison to Kotlin?
I'm sure you didn't mention them explicitly to avoid fueling a potential flame but, hopefully it won't happen, I would like to have a reference to render your comparison with the "X language" more complete to me.
Regarding JVM interoperability... that seems absolutely wonderful. If I were a Java programmer I would have already "absorbed" Kotlin (as many Android developers I know have done).
A couple of weeks ago I read the following article here on dev.to
The author's thesis is that Kotlin is interoperable indeed but there are still cases of people rewriting libraries instead of "interoperating", thus creating a sub community that's "incompatible" with the rest of the ecosystem. He writes:
Yet, this is not quite what is happening. I have seen the birth of a Kotlin-first community of developers, preaching things "the Kotlin way". Soon enough, tools, libraries, and frameworks started appearing, having perfectly working equivalents in Java, but written in "idiomatic Kotlin". I started wondering where I had seen this before 🤔.
(Though if I understood correctly those libraries would be usable from Java too, they are just "duplicated" efforts)
A discussion ensued in the comments and I asked why this happens. @jbristow
gave me a nice explanation:
You had to pick one of the worst examples of Java, didn’t you?
URL.toStream sucks and is not intuitive to read 6 months down the line. (And let’s not forget having to add in your own retry policies, header and response code parsing, turning off ssl verification, etc.)
Apache HttpClient is old and feels old. It gets the job done, but at the cost of having to implement anonymous interface implementations whenever you’re trying to mess with settings.
The biggest kotlin http client repo I can find is fuel. This library is... alright. We’re running into trouble debugging problems with it because it tends to barf deep inside HttpClient, which makes me feel like I should have just bit the bullet and gone with using the Apache jar straight up.
Another source of fun problems is java reflection. Specifically bean reflection. This is most noticeable when attempting to use Jackson to serialize the following class:
data classMyDynamoDbTable(valName:String,valVersion:Int,valSomeProperty:String)
Yes, I know that’s not proper kotlin idiom, but it’s non-obvious to me that Jackson would just convert them all from Pascal to camelCase. (The reason is that it’s the bean spec! Use annotations and make your kotlin ugly again! Yes, one of the things driving me to Kotlin is the explosion of Annotatiomania and Lombok. Used sparingly, annotations are good. Using them to code-gen, do too much abstraction, or hack the language are bad.)
Yet another fun one: in Apache Tinkerpop’s gremlin library, there’s a class named __.
If I’m writing a couple lines of interop, then yes, a nice facade will do. Just sweep the mess under the rug so I don’t need to see the FizzBuzzIteratorCheckFactoryBuilderContexts bleeding through every so often.
It’s just that used long enough, the facade takes on a life of its own. Debugging how the facade works and then having to context switch back to 1.6 era Java code when diving through undocumented code is even more taxing!
(And full disclosure, I really wish I had the time to just write all this crappy code in Haskell or Pony instead. Writing Kotlin is better than writing Java, but it’s not truly taking the shackles off)
What do you think?
In the end I do believe there's an advantage in targeting existing ecosystems when creating a new language (see Elixir) but it doesn't always work because not all languages have virtual machines with a bytecode. The other alternative is to write compilers targeting another high level language (see the many languages that compile to JavaScript) or a common binary specification like WebAssembly.
Great languages that I’m talking about are Scala, Clojure, and Groovy. They’ve had the same opportunity as Kotlin, and community or tech reasons steered in a different direction. Which is fine—people wanted to create a very different way to build and design applications.
I think that this phenomenon is not avoidable entirely. It seems that some examples of these libraries emerging are good, because they are attempting to fix real problems, and they are contributing back to the ecosystem.
Not just duplicating effort as "an act of rebellion…" or in pursuit of more complexity for the fun of it…
I much prefer when big libraries and frameworks add more and more Kotlin support natively so that you don’t have to build another library or wrapper. Think Spring-Boot and efforts made by Sebastien Deleuze and others.
And it is the power that we all hold. With the current state of things, most developers can go and create a PR for their favorite library and framework to add more Kotlin-friendly interfaces.
Great languages that I’m talking about are Scala, Clojure, and Groovy. They’ve had the same opportunity as Kotlin, and community or tech reasons steered in a different direction. Which is fine—people wanted to create a very different way to build and design applications.
Oh, got it! I thought you were referring to other recent languages that don't target any previously existing ecosystem.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi Oleksii, nice article! I don't have any experience of JVM languages (just a bit of super obsolete Java knowledge) but I still enjoyed your article. For the sake of argument and because I love languages can I ask you which other languages are you referring to in comparison to Kotlin?
I'm sure you didn't mention them explicitly to avoid fueling a potential flame but, hopefully it won't happen, I would like to have a reference to render your comparison with the "X language" more complete to me.
Regarding JVM interoperability... that seems absolutely wonderful. If I were a Java programmer I would have already "absorbed" Kotlin (as many Android developers I know have done).
A couple of weeks ago I read the following article here on dev.to
Q: How Much of "the Kotlin Way" Is the Right Way?
Preslav Rachev ・ Dec 28 '18 ・ 2 min read
The author's thesis is that Kotlin is interoperable indeed but there are still cases of people rewriting libraries instead of "interoperating", thus creating a sub community that's "incompatible" with the rest of the ecosystem. He writes:
(Though if I understood correctly those libraries would be usable from Java too, they are just "duplicated" efforts)
A discussion ensued in the comments and I asked why this happens. @jbristow gave me a nice explanation:
You had to pick one of the worst examples of Java, didn’t you?
URL.toStream sucks and is not intuitive to read 6 months down the line. (And let’s not forget having to add in your own retry policies, header and response code parsing, turning off ssl verification, etc.)
Apache HttpClient is old and feels old. It gets the job done, but at the cost of having to implement anonymous interface implementations whenever you’re trying to mess with settings.
The biggest kotlin http client repo I can find is fuel. This library is... alright. We’re running into trouble debugging problems with it because it tends to barf deep inside HttpClient, which makes me feel like I should have just bit the bullet and gone with using the Apache jar straight up.
Another source of fun problems is java reflection. Specifically bean reflection. This is most noticeable when attempting to use Jackson to serialize the following class:
outputs:
Yes, I know that’s not proper kotlin idiom, but it’s non-obvious to me that Jackson would just convert them all from Pascal to camelCase. (The reason is that it’s the bean spec! Use annotations and make your kotlin ugly again! Yes, one of the things driving me to Kotlin is the explosion of Annotatiomania and Lombok. Used sparingly, annotations are good. Using them to code-gen, do too much abstraction, or hack the language are bad.)
Yet another fun one: in Apache Tinkerpop’s gremlin library, there’s a class named
__.If I’m writing a couple lines of interop, then yes, a nice facade will do. Just sweep the mess under the rug so I don’t need to see the FizzBuzzIteratorCheckFactoryBuilderContexts bleeding through every so often.
It’s just that used long enough, the facade takes on a life of its own. Debugging how the facade works and then having to context switch back to 1.6 era Java code when diving through undocumented code is even more taxing!
(And full disclosure, I really wish I had the time to just write all this crappy code in Haskell or Pony instead. Writing Kotlin is better than writing Java, but it’s not truly taking the shackles off)
What do you think?
In the end I do believe there's an advantage in targeting existing ecosystems when creating a new language (see Elixir) but it doesn't always work because not all languages have virtual machines with a bytecode. The other alternative is to write compilers targeting another high level language (see the many languages that compile to JavaScript) or a common binary specification like WebAssembly.
Thanks again for the article!
Great languages that I’m talking about are Scala, Clojure, and Groovy. They’ve had the same opportunity as Kotlin, and community or tech reasons steered in a different direction. Which is fine—people wanted to create a very different way to build and design applications.
I think that this phenomenon is not avoidable entirely. It seems that some examples of these libraries emerging are good, because they are attempting to fix real problems, and they are contributing back to the ecosystem.
Not just duplicating effort as "an act of rebellion…" or in pursuit of more complexity for the fun of it…
I much prefer when big libraries and frameworks add more and more Kotlin support natively so that you don’t have to build another library or wrapper. Think Spring-Boot and efforts made by Sebastien Deleuze and others.
And it is the power that we all hold. With the current state of things, most developers can go and create a PR for their favorite library and framework to add more Kotlin-friendly interfaces.
Oh, got it! I thought you were referring to other recent languages that don't target any previously existing ecosystem.