Send me all the Kotlin questions you were too afraid to ask

jmfayard profile image Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄ ・1 min read

The inspiration for this post comes from this request:

I actually enjoy the challenge to try to explain useful things with simple words. Everyone can say complex sentences filled with buzzwords. Cloud-ready serverless blockchain-based something something. The real test is whether you can explain it with simple words. As a great french writer once said:

(français) Ce que l'on conçoit bien s'énonce clairement, Et les mots pour le dire arrivent aisément
(english) Whatever is well conceived can be clearly said. And the words to say it flow with ease.

So don't hesitate, if you have any Kotlin-related questions you were too afraid to ask, reply to this post.


markdown guide

Isn't Kotlin just another iteration of languages like Groovy?

In other words, groovy didn't really replace Java in the end, although it found niche applications being gradle the most popular... I think. Maybe I'm wrong but... seems to me groovy will eventually fade away completely.

Do you think Kotlin might also face the same destiny? If not, why?



Hello I don't really want to get into comparing Kotlin with other JVM languages that are interesting in their own right and that I don't know so well.

But on the core of your question, yes, I do think Kotlin can be seen as a replacement for Java. It certainly did it in the Android world, which is now Kotlin first. And the reasons why it did apply elsewhere too. In most cases where Java is a good solution, Kotlin is a great solution. Because of the effortless interopability, you can start adding a bit of Kotlin in your existing Java codebase, and then notice it's better, and eventually replace it completely. I don't want to write in Java anymore and I think that usually I won't have to very often. Writing a JVM library is the counter example that comes to mind. Here it could make sense to use Java so that people don't have a transitive dependency to the Kotlin standard library. But even that I think could become no more problematic than adding a dependency to guava if Kotlin continues to grows.

Of course Java (or JavaScript) are huge enough that they will never disappear. But I do think that for most new projects, using Kotlin (or typescript) will be seen as a practical solution that improve developer productivity, so why not using it?


Thank you for your response. This makes sense.

Three weeks ago I started a side project in Kotlin that could potentially replace a legacy Java code I created a couple of years ago. I'm very curious on how easy it'll be to integrate it in the whole solution, as well as how the classic GoF patterns will be applied in Kotlin.

Cheers and thanks for sharing.

Hey, builder pattern is interesting....

I'm trying to understand this expression:

fun dialog(init: DialogBuilder.() -> Unit): Dialog =

The part that is kind of weird to me is: DialogBuilder.()

Is that related to the extension functions?

So actually the builder pattern is integrated in Kotlin itself.

Given data class User(val id: Int = 1, val name: String = "")
Then this do the same as the builder pattern would do in Java
val user = User(name = "Alejandro", id =42)

The dialog function is a building block for building a DSL.
It takes as parameter a function init that you could define as having a parameter DialogBuilder and returning Unit. But instead you define the parameter as an extension function of DialogBuilder.



What Problem(s) does solve Kotlin better than other languages?

  • Kotlin is the child of JetBrains, a company that produces some of the best IDE, especially for Java.
  • So JetBrains obsession since its creation has been to understand how it can help programmers writing better software, to discover detect and fix all the common errors that programmers do. They have been very good at it, but at some point you reach the limit of what you can do in the IDE.
  • Why not integrate all this learning in the programming language itself? Well improving Java itself is seriously difficult, most of the things you should improve, you cannot for backwards compatibility reasons. Or you can reinvent a totally new language, but if you cut yourself from the massively important Java ecosystem, then it's not very attractive.
  • Can we have the best of both worlds? Yes. Jetbrains wrote a new language with a compiler that produces Java bytecode and is effortlessly compatible with the rest of the JVM ecosystem.
  • I think it was C++ inventor who said that you have two kind of languages: the ones people complain about a lot and the ones nobody uses. There is a lot of truth to this: think JavaScript (lots of flaws, very widespread) vs Elm (very nice language, few can use it). But the false dichotomy always made me sad. Can't we have more more well designed language that are also not confined to a niche? Well that's Kotlin.

What does Kotlin better than the others? It's not a single thing, there is no silver bullet as Frederic Brooks pointed out long ago. It's the compound effect of the lessons learned watching programmers do mistake, not being afraid to copy what other programming languages do well and having the expertise to do so (because jetbrains build IDE for many languages), being a practical choice, providing great tooling, being safe and concise, having good documentation, a very interesting community, and fixing a lots of small issues.

No silver bullet - essence and accidents in software engineering