DEV Community

Cover image for Kotlin: How Can a Programming Language be so Young And so Mature at The Same Time?

Kotlin: How Can a Programming Language be so Young And so Mature at The Same Time?

Alex Fedorov on January 12, 2019

In this article, we’re going to explore why young programming languages with modern features can’t be adopted quickly. Additionally, we’re going to...
Collapse
 
andreandyp profile image
André Michel Andy

Kotlin is a great language, I hope it will be fully adopted by the Java developers within the next years.

Also, I think Typescript is another language that was developed in the same way as Kotlin: any JS code (from the old ES3 to the ESNext) is a valid TS code. Adding definitions to the previous libraries such as loadash and jQuery was extremely easy.

Collapse
 
waterlink profile image
Alex Fedorov

Indeed it is. That is my hope as well, actually, 😅 What do you think might stand in the way of this happening?

Also, TS has the problem that most JS libraries won’t work until adapted for TS, which is super unfortunate :(

Collapse
 
andreandyp profile image
André Michel Andy

Well, I don't know if some codebases would have problem with Kotlin, I'm talking about Java 5 or older code. In those cases, some refractory will be needed.

I've read something about it, it is necessary a gradual migration from JS code to TS code. It is not obligatory but it's needed if developers want to use types.

Thread Thread
 
waterlink profile image
Alex Fedorov

Of course, such old code will need to be upgraded to recent version of Java anyways.

I did recently a migration from JS to TS, and it is still quite painful. You have to hunt a lot of TS config options to make them just right so that JS + TS can work together and not get into any 'import' errors.

Collapse
 
emlautarom1 profile image
Martín Emanuel

For me the iteroop with Java is one of the main selling points of Kotlin. The ability to use all the mature, tested and known ecosystem allows us to make the switch without much hesitation. Works with Kotlin? Good. It doesn't? Switch back to good old Java.

Collapse
 
waterlink profile image
Alex Fedorov

In your past experience what didn’t work well w/ Kotlin? What did it take to fix the problem if you tried?

Collapse
 
emlautarom1 profile image
Martín Emanuel

Well, out-of-the-box I had some problems with JavaFX. It would throw the classic NullPointerException for no apparent reason, so I didn't bother with it and simply started using TornadoFX.

Besides that, I think I never encountered another compatibility problem.

Collapse
 
vinceramces profile image
Vince Ramces Oliveros

Just as Kotlin is easy to adopt. I am a Dartisan(dart programming language) guy and Dart can be easily adopted too, and that's because Dart's intention was to be familiar for experienced developers. My first programming language was C++ and second was Java. I tried Kotlin in Android Studio because of the announcement Google made during the I/O 2017. I was naive enough to understand the APIs of the android and the syntax of Kotlin. I really wanted to learn Kotlin in Android Studio but I gave up due to the bloated IDE I've been using. My point of learning a programming language is to use for the right tool and not for just learning the syntax itself.

With Flutter today, I am now eager to learn Kotlin just to use Platform Channels to access Android APIs(bluetooth,nfc,battery,connection state, audio, etc.).

I still think Kotlin will become more popular because of the optional semi-colon that most beginners really wanted. Diving deep, and I'll be learning coroutines,data class,non-nullable and much more.

Collapse
 
mburszley profile image
Maximilian Burszley

People don't move to a language just because of the syntax (re: optional semi-colon)

They move there because it solves their problems better (or at least, that should be the motive if it's not for their own education)

Collapse
 
rhymes profile image
rhymes

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 class MyDynamoDbTable(
  val Name:String,
  val Version:Int,
  val SomeProperty:String
)

outputs:

{
  "name": "Jon's Spicy Meatball",
  "version": 2,
  "someProperty": "TBD"
}

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!

Collapse
 
waterlink profile image
Alex Fedorov • Edited

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.

Collapse
 
rhymes profile image
rhymes

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.

Collapse
 
vishnuharidas profile image
Vishnu Haridas

I am writing Kotlin/Android at my daily job. I switched from Java to Kotlin very recently.

First, it was the promise that Kotlin gives us. It solves many problems that a Java developer faces on a daily basis --- Null safety and verbosity being on the top. Next, the interop was another selling point.

I don't have to write a class for every single file that I have. Concurrency using Coroutines are easy to follow. List processors like map, reduce, zip etc are a part of the standard library. I know when something can be NULL. Extensions are fun stuff.

I promote Kotlin among my colleagues that work on JVM. They must try this modern language for sure.

Collapse
 
waterlink profile image
Alex Fedorov

Did you have some success with your colleagues so far? Do they have reservations?

Collapse
 
vishnuharidas profile image
Vishnu Haridas

It is a success. People are getting more interested when they see the real code. Now two of my colleagues are full-time Kotlin, and four are currently learning Kotlin. We have decided that all our upcoming projects in Android will be 100% Kotlin. My colleagues want to switch mainly because they see how easy and efficient to write Kotlin than Java.

Collapse
 
cjbrooks12 profile image
Casey Brooks

Using Kotlin from Java, you almost don't realize how big of a deal it is just how seamless the interop really is. I've been spending a while trying to get comfortable with Kotlin/JS, and it really puts things in perspective. Kotlin/JS works very well in isolation, but getting it to play nicely with existing libraries and tooling just isn't very clean or easy, and it really does feel like a young language in contrast to the maturity of Kotlin/JVM.

Collapse
 
waterlink profile image
Alex Fedorov

Definitely. I feel like, in JS world, a bit different patterns are usually used. When I write front-end code with Kotlin, I actually avoid using libraries at all, so that I can have nice architecture. And Kotlin stdlib gives me a lot already.

Collapse
 
bveenvliet profile image
Brad Veenvliet

Great post. I recently converted a medium size Android Java project to Kotlin and had an almost identical experience as you describe. Do a bit at a time and go slowly at first, you will learn to love Kotlin!

Collapse
 
adipolak profile image
Adi Polak

Kotlin is a great language. Although it may be lacking in performance sometimes.
Of course there is a case by case scenario where it doesn't matter and some scenarios where it can be critical.

Thank you for a great article and a great example of usage by a backend developer.

So one can make an informative decision, can you please share the cons/challenges that the language is facing at the moment?

Thank you again for a great read!

Collapse
 
derek profile image
derek • Edited

How Can a Programming Language be so Young And so Mature at The Same Time?

A lot of iterations in a short amount of time 🤷🏽‍♂️