Programming with Kotlin: Why, How and Kotlin’s Place in the Future

Listen to this episode on:

Apple Podcasts | Google Podcasts | Spotify | Overcast | Pocket Casts

---

“Developers don’t just like Kotlin, they LOVE it.” Understand why in this discussion with Venkat Subramaniam, author of  “Programming Kotlin: Create Elegant, Expressive, and Performant JVM and Android Applications 1st Edition” and Hadi Hariri, VP of developer advocacy at JetBrains. They give you reasons to learn more about Kotlin, whether you like dynamic or functional languages, and why you should always be learning something new.

---

Preben Thoro: Brilliant. In that case, this is my cue to welcome the two of you. Thanks a lot for joining us today. I'm really looking forward to the magic we will have here. If you're ready, I can see Maria, you already muted yourself. I will mute myself here and that is my cue to pass it on to you, to hand it over to you, Hadi Hariri. Please take it from here.

Hadi Hariri: Venkat.

Venkat Subramaniam: Hey, Hadi. How's it going?

Hadi Hariri: Good. How are you doing?

Venkat Subramaniam: Pleasure seeing you again.

Hadi Hariri: I know it's been... This is the only way we get to see each other now, huh?

Venkat Subramaniam: The last time you and I met was at the train station. You took me to the train station. I was going to go speak in a few cities in Spain. So we had a good lunch. I'd do anything to get that moment back right now.

Hadi Hariri: Yes, it's funny, because I was actually driving past there the other day and I said, "I remember this. This is where we had..." I think it was called Java by the Beach or something like that, the conference you have attended. Yes, it's been so long. But how is life treating you at home, because this is the longest ever I've been stuck at home.  

Venkat Subramaniam: Yes, I came home about what looks like 10 months ago, and I'm in this beautiful basement of mine which is where I spend most of my time these days. But it's great because I get to still interact with the world. Technology is awesome. So reaching out and speaking to developers. So it's what it is and we have to deal with it.

Hadi Hariri: Well, I was going to say awesome background — awesome views in your amazing basement. Because you're actually based out of Colorado, so you've got some nice mountains to begin with anyway, right?

Venkat Subramaniam: Which has been the plus part this summer is doing more hiking now that I'm here in Colorado. Usually, travel keeps me away during the summer but, you know, make the best out of what's available.

Traveling and writing books 

Hadi Hariri: All right. One of the things that has always amazed me about you… Well, there are many things that amaze me about you, but one of the things that I've always found intriguing is how you manage to get so much done when you're always on the road, right? I mean, when we talk with our colleagues across the conference circuit and speakers, and you've got the two broad ends of the spectrum, right? You've got the folks that if they're traveling, they don't even check their email anymore, right? Then you've got somewhere in the middle where you can travel, get stuff done, write some blog posts, etc., whatever. And then you've got Venkat on the other end, which is like, this is just my life, right? I can travel and write hundreds of books while I'm traveling as well. How do you do that? Like what is your secret there?

Venkat Subramaniam: You know, I don't know if it's a feature or a flaw, honestly.

Hadi Hariri: You said that I didn't say that.

Venkat Subramaniam: But in all honesty, it's really the sheer excitement. I think this is a weakness from my childhood. I used to drive my uncles and aunts really crazy by really getting excited about stuff and wanting to do it now. You know, if I think of something, I've got to do it now. I recently came across somebody honestly who is as impulsive as I am, and it was just amazing to watch this. I was like, "Oh, this is how it feels for others when I watch this person." But that's just a weakness from childhood I think. And so when I get excited about something, I've got to do it.

I posted a blog a few years ago and the blog post simply said, "Tell me now or tell me when." And what I mean by that is that we all communicate constantly and we are depending on each other. So I believe that when I see an email, I want to tell now what I'm going to do or tell when I'll do it. So it goes into my calendar "Hey, I'll get back to you next Tuesday." And to follow up with the people on the time. So just being more mindful of the time and other people's time as much as my time as well. And that just kind of became a habit over time is to be focused and get things done. And to say no to certain things because we cannot simply do everything, and just need to prioritize what we do as well.   

Hadi Hariri: Talking about putting your mind to things, I mean, you've written... How many books have you actually written, Venkat?

Venkat Subramaniam: About 11 or so.

Hadi Hariri: Eleven books. Ok, so I'm not going to say I even wrote one book. Ok, I'm done. So you've been writing 11 books. And now that you've been at home for 10 months, how many is that, 25, or 26, or something like that?

Venkat Subramaniam: Well, thankfully no. The most recent book was the one on DSL in Kotlin, so only one this year.

Why a book about Kotlin? 

Hadi Hariri: Yes, and DSL in Kotlin, so that's interesting because you've actually written another book about Kotlin which is "Programming Kotlin." So I've got to ask you… You know, I've got so many things to ask you about this, but let's start with the question that I always ask myself, “why?” Why did you decide to write a book on Kotlin given that you know so many other languages and you've sold books on so many other languages? Why Kotlin?

Venkat Subramaniam: Yes. I ask this question quite often, like why do I want to write any book, Kotlin being one of them? And this happened about maybe 15 years ago, maybe 18 years ago. I went to a good friend of mine who had written quite a number of books and I said, "Hey, I'm thinking of writing a book. What do you think? Should I write a book?" And his question was, "How's your business?" I said, "My business is doing great. I don't have time. I'm busy all the time." And then he said, "Well, then don't write a book because it's going to take time. And one of the reasons you may want to write a book is it's a good marketing tool, it can help you really get business. But if you've got a lot of business already, why do you bother?" And I said, "That's really good advice, thank you so much for that." I dropped the idea of writing the book. And that was before I wrote my first book.

Then a few months went by, and I was sitting down in an airplane and it suddenly occurred to me that I do want to write a book, not because I need to build a business, but I really want to write a book because there's a story to tell. Every single book I've written is based on exactly that, that I have a story to tell. With the Kotlin book, in particular, that is absolutely true. I've known about Kotlin for a while. In fact, I remember, several years ago meeting Andrey Breslav in a conference. I kind of asked the question, "You know Groovy does this, Scala does this, you know, Ruby does this. Why should I really use Kotlin?" And I think he gave me the most brilliant answer, in my opinion. He said, "Maybe then it's not for you." And I said, "Okay, well, that's a good response. Thank you for that." I honestly did not bother much with Kotlin at that time because, to me, Kotlin was doing what I could do in other languages.

Then I kind of started playing with Kotlin after that. There are parts of Kotlin that I was playing with, and one of the things that absolutely intrigues me, and as I know it does you as well, is we don't want to just use a feature because the feature is available. We want to go deeper and understand, you know, how that actually works. That's the part that really intrigued me about Kotlin is I was seeing a few different features in syntax that were remarkably different from what I had been used to. It really bothered me and frustrated me because I want to know, A, how this works, and B, if this is related to something I've seen elsewhere maybe in a different setting. I remember clearly one early morning, sitting and tinkering with Kotlin code and a little lightbulb goes in my head, I'm like, "Whoa, I finally understand how this works. And now I think I have a story to tell."

That was the moment, and I'm like, "Okay, I've got to write a book on this." Obviously, a blog post won't be enough, right? So I really had to write a book on this. And I got absolutely excited about this. 

I have a very unstructured way of writing. And so I threw the content in there into a rough draft and I started really working on it. But I do have to say, in all honesty, had I known how much time it would take to write the Kotlin book or how big it would end up being, I really would not have started it. So there's a bit of a benefit to ignorance here I think as well. And I'm absolutely thrilled that I finished writing it, but it is the biggest book I've ever written.

Hadi Hariri: Wow, really?

Venkat Subramaniam: I don't think my publisher would've let me write it had I told them it would be about 420 pages long because I have been asked not to go beyond 200 pages in the past. So this one just weighs, you know, we went through every stop that we usually face. It was a really exciting journey, but I don't think I would repeat that again.

Do you have to be an expert to write a book?

Hadi Hariri: People talk about when I have a lightbulb moment, you said, "Instead of writing a blog post I wrote a book." People nowadays, they're just like, "Let me just tweet something." And maximum I might make a tweet thread of three tweets. But no, you go and write another book. And this brings up another interesting point which I think is a big myth among people that, and by far, I'm not saying that you are not an expert at all. More than thousands of people combined, but there is this myth that you have to be a very advanced expert to write a book, right? Whereas, in my particular case, I don't know if it's the case for you, but I actually use a couple of books that I wrote as a learning exercise as well. Where do you stand on that?

Venkat Subramaniam: Well, first of all, I would say one of the things I quickly realized is I would never be an expert. I don't actually believe in this theory of the expert because each of us has a certain amount of knowledge and depth in different areas, but the amount of ignorance that we actually have, it's what we don't even know that we don't know. One of the things that absolutely excites me is we're all learners. And what could excite us more as learners than that humbling experience to wake up one morning and say, "I have no clue." I want to go and find out why this works or how this works. Writing a book is such a humbling experience, especially when you have the "experts" who are there to guide you along.

I'll share with you the most humbling experience with respect to the Kotlin book. I had Andrey Breslav review the book. Eugene, that you recommended as a reviewer, is a phenomenal person. A third person was Tom Adam from Oslo. I had met him when I was teaching courses in Oslo and we were in touch. Then when I realized that he was using Kotlin, I approached and said, "Hey, would you be a reviewer?" And I had a few other excellent reviewers. Every one of them tore the book apart every single page of the book. The things that you recommended that I include in the book, I didn't even know that it existed — it’s such a humbling experience when you're writing a book.

I remember explaining certain concepts, and Eugene was such a patient person. There's so much to learn from this experience. He would very politely say, "Yes, good try, but have you really tried this example? It doesn't really follow what you're describing here." And I'm like, "Oh my goodness, now I've got to go back and rewrite the whole thing." That's the fun part is we learn certain things and we develop certain perceptions of these features, but when somebody else refers to a certain different view, it's absolutely phenomenal to realize there's a whole part of an idea that you sit back and think . You kind of sit back and think about it and say, "Gosh, I could never be an authority on this topic. I could never be an expert." And then we get a very different perception of concepts.

 developers rarely tell me they like Kotlin. They always tell me they love Kotlin.

I was looking at something yesterday and somebody was describing a certain idea. And I could see that there were a lot of details missing in it. Immediately, my thoughts go back to my own writing and a lot of details are missing in it. So I think it makes us a better human in the process as well. To your point, this is exactly what we say about not only writing a book but speaking in a conference as well, you don't need to be an expert to speak on a topic because it's your journey, your experience, your pain and your recovery from it is what people want to learn from. There are people around you to support you and fill in and help you. That is the fun experience of writing the book. Anything I do, I want to come out smarter than I went in. And writing a book is definitely one such experience, no doubt about it.

Hadi Hariri: But it still takes a lot to write it. If you say that someone gives you feedback and that feedback implies somehow that you have to go back and maybe redo some part. It takes a lot to not be demotivated around that, right? Kudos on that, because I’ve gone through that process and all I wanted to do was finish the book. And then when there were reviews and I'm like, "I hope that this won't imply so many changes." How do you cope with that?

Venkat Subramaniam: Oh, Hadi, you're absolutely right. I will definitely be honest about it. I am pretty old right now, over the years having lived in this world for a few decades. We all face challenges in our lives, but if you ask me, of all the things that I've faced so far, what is one of the most painful things I would put at the very top of the line, I would definitely put book writing on it. Especially writing a book, it definitely is. And it's kind of like this experience where you write your first book and you say, "I'm done. I'll never do it."

Hadi Hariri: Never again.

Venkat Subramaniam: Then you come back for the second one and then you say, "I haven't learned from this experience yet. This is the end." And I remember my wife actually telling me, "Well, of all the books you've written, this one has been the most painful for you." And then she says the same thing every time I write a book.

Hadi Hariri: Every time, right? So you've put at the top of the list writing books as one of the most painful experiences and you've done 11 of them. And I'm guessing that you have a few more in the pipeline.

Venkat Subramaniam: One of the motivations really comes from the fact that you have to sit back and rewrite it. But I remember in one of the books I was writing, I had the courage, and this takes a while to get to that kind of maturity I think, and I use the word courage for a reason, I had the courage to delete the chapter entirely and rewrite it four full times.  

Hadi Hariri: Wow. Which chapter was this, if I may ask?

Venkat Subramaniam: It was too painful that I'd erased it from my memory. I think it was a chapter related to where I wanted to show how lambdas can be used for bringing in recursive operations with Tikal optimization. I had written it. It was so complex. Nobody could understand, including myself, after I'd written it. And this happened again in a chapter on test-driven development. I had built up this example showing how to do TDD on this particular concept. Then when you finish writing it you realize the example is not working, the flow is not good, and you delete, and you start over, and you start writing it. Then you come towards the end and you realize, "Oh my gosh, there's a much better example to use." Now, what do you do? You have a choice of saying, "Well, I've got a better example, but I'm going to keep it," or you say, "You know, throw it away and start over." In a way, if you really think about it, writing a book is definitely not to the scale, but writing a book is like making a movie. There are parts of a movie that never get released. They are cut out. There are scenes that were filmed that are redone several times over.

In one of the books I wrote, I'm not even kidding, four chapters were never ever published. I took the time to write those four chapters, and during the editorial process, they said, "We've got to cut this book down. We've got to make this smaller. So you get to pick the chapters you want to throw away." Also, when I was writing the Java book, Brian Goetz, I'm very humbled, was one of the reviewers,  who had created this concept of Spliterators. And here I am, getting absolutely excited about Spliterators, and I spent an entire section writing maybe about seven to eight pages on Spliterators.

And here is Brian reviewing the book, and he drafts me an email saying, "I want you to remove that section now." And I'm like, "Brian, this is exciting stuff. It's Spliterators. Why would you not want me to add it?" And he's like, "Because nobody in the world should be doing what you're telling." I respect his opinion absolutely. He's the one who created this concept, and it doesn't matter that I took the time to write it, and I deleted it from the book, because it's a concept that shouldn't be really exploited by most programmers out in the world. 

That's kind of what happens when we write the book: we are eager to publish a book, but as we begin to write the book over and over, I would say that's the part of maturity for me is to not be eager to complete it, but to really take the time to make it a really good book based on the feedback both from others and from myself, right, because as you're writing it, you begin to realize how better it could be.

There is a balance here though. Sometimes we have this tendency not to release it and we take, you know, 10 years to complete a book because we want to always make it better. So we have to have a bit of a balance in there. But thankfully, there are other people like development editors who kind of check on us and say, "How's it going? You know, are we going to get done at all." So that's definitely helpful as well.

A short history of Kotlin & key features

Hadi Hariri: Yes, the peer pressure there. You've got the advantage with books as opposed to movies is that you don't have to come up with a complete new plot to make a second part. You could just do second editions, and third editions, and fourth editions, and throw in those examples, right? But it's funny that you say that the Kotlin book has come out as the longest book. I guess that goes against the idea that Kotlin is a concise language, no?

Venkat Subramaniam: I'm glad you mentioned it. If you don't mind, I want to ask you a question before I answer that question or take on the conversation. I want you to educate me and others a little bit about the history of Kotlin. Where did Kotlin come from is a very common question I receive, and I can't think of anybody better to ask the question to. Tell us a little bit about the history of Kotlin and then I'll come back and then take up the conversation that we're having.

Hadi Hariri: What Breslav shared in the past is generally the origin of Kotlin in that we were, as JetBrains is a company that does tooling, the vast majority of our code was based on Java. We were looking for other ways to write code to make it a little bit more concise to have access to certain features such as lambdas, which at the time weren't available. We're talking back in 2009, early 2010 when Kotlin started. We looked at multiple languages. We looked at Scala, but we were doing tooling for Scala, and we realized that tooling Scala is not an easy thing to do. We looked at Groovy, but Groovy was a dynamic language. We're strongly biased towards typing I would say. Then there was this effort to try and work with... The name's completely gone from me. What was the name of that… The language which was at the same time?

Venkat Subramaniam: MPS?

Hadi Hariri: No, no, not MPS. It was very similar to...

Venkat Subramaniam: Oh.

Hadi Hariri: Oh, God, I can't remember. It's been so long. It was always Kotlin and the other one that was now I think by Red Hat, or there they have it. Anyway, we were talking to them to try and use that, but they were not going after the modular system. They were doing their own modular system. They weren't focusing too much on the compatibility with Java. And of course, we wanted a startup that you could say, you know, "Let's throw away 10 years of code and rewrite everything from scratch for us. Interoperability was a must. So we said, "Well, why not? Why don't we try and write our own language and see how it comes out?" I think the first prototypes were called Jet language, the original. Even after two years, I think we still had names bases, package names with a Jet prefix in there, but that eventually got renamed to Kotlin. So that's basically the idea behind it. We needed something for ourselves, which is very much in line with JetBrains of dogfooding the tools that we make and need.

Venkat Subramaniam : It’s really useful to know the history behind the language, the effort to make it more concise and more fluent. That's one of the things that intrigued me about Kotlin is developers rarely tell me they like Kotlin. They always tell me they love Kotlin. That really is exciting to see developers expressing such ideas about a language. And you're able to see languages like... I spent years programming in, you know, different languages. I have this fascination for programming languages. And there was a time when I programmed in one language and I thought I knew everything.

Hadi Hariri: Everything there is to know.

Venkat Subramaniam: Then, of course, I learned my second language and the third language. And today, I probably program in 15 to 20 different languages. What that really made me realize is I'm not good at any one of them, but having experimented with these languages, when I looked into Kotlin, it's funny when I talk to developers, they would say, "Kotlin is like..." and fill in the language. And I always tell them, "Well, that's great, you say that because you know this other language, so you're able to draw the similarity," but Kotlin has features that I've seen in Ruby, and Python, and Scala, and Groovy, and R, and...

Hadi Hariri: Ceylon, Ceylon. Ceylon was the one I forgot. Yes, Ceylon.

Venkat Subramaniam: Ceylon. Yes. And also Haskell and so many languages. This is what really surprised me. Here I was telling myself, "Kotlin is a simple language. Kotlin is a smaller language, a concise language. Oh, I can write a book on it very easily." How wrong one could be.

Hadi Hariri: Were you?

Venkat Subramaniam: Because every little thing you touch on, that's five to six pages at least to spend time on. Kotlin has some beautiful features that either don't exist in other languages or are done much better than in other languages. But one of the challenges is, what do you cover and what do you not cover in a book? 

When it's a language book, you want to give enough for people to be effective with it. You don't want to write a 3,000-page book obviously, but you cannot get away with a 100-page book as well when the language is so rich. For example, you are not just able to write lambdas, but you're able to inline lambdas. That’s absolutely mind-blowing. 

You probably would think twice about talking to me the next time, but I spent my youth programming in C++. And I spent my youth teaching C++ for about 15 years.

I used to spend a lot of time teaching about inlining. So when I saw inlining in Kotlin, I naturally was drawn into the idea. But the inlining in Kotlin is very different from inlining in C++. Not only that, inlining has repercussions in how you actually inline. There's a local return versus non-local return. And the minute you touch that, 15, 20 pages later, you're like, "Oh my gosh." That's how the book ends up being a 420-page book, while Koltin is a simple and elegant and small language for people who don't know it. The minute you start experiencing Kotlin, you are blown away by the sheer richness of the language. That's the fun part of the language itself, in my opinion, is that the language has so much to give for developers.

One of the things also that excites me about Kotlin is Kotlin is a language that treats me as an adult. It doesn't insult me, right? It doesn't tell me, "You need to know better. Here's how you do things." So it's not a highly opinionated language in that sense. Kotlin is a multiplatform, multi-paradigm language. So if I decide that imperative-style code is the right code to write, Kotlin doesn't insult me and say, "Oh, you should be writing functional code." Instead, it makes that journey really enriching. If I decide that I want to write functional-style code, it makes that journey pleasant as well. So it feels like a nice adult, a good friend to work with where they don't treat you [like], "This is the way to do things." Instead, they say, "If that's what you want to do, let's make it even better than what you could do otherwise." That's really the story I wanted to tell in the book is to say, "Hey, this is actually a really powerful language. It's not just another Groovy, or Python, or Ruby, or fill in your language. It is a language that has taken these great ideas, but it really delivers that with a greater fidelity, if you will."

Hadi Hariri: Yes — the whole functional and object-oriented paradigm. When I am giving a talk on Kotlin, I ask the audience "Are you object-oriented programmers by and large?" And if they say, "Yes," I say, "Well, Kotlin is an object-oriented program language with functional programming features." And if it's a functional audience, I say, "Well, Kotlin is a functional programming language with some object-oriented programming features." 

The kid in the candy store

Hadi Hariri: What would you say is [...] the biggest thing that you learned from the book, from writing the book? Like what's the biggest takeaway other than, "Okay, this was a really long book?"

Venkat Subramaniam: It is really taking the time to learn about ideas to a greater depth than what I think or thought I knew. There's a certain amount of learning that happens for no matter which book you write, like we talked about earlier. But with Kotlin, the language is evolving as well. As I came in, it's not just writing about the language itself, it's writing about the different paradigms, it's writing about coroutines is such a beautiful concept. And coming in, I would say probably I knew… If I want to put a number, I would say, okay, if I want to really praise myself I would say maybe I knew 70% of the things in there. But knowing the depth of the things and beginning to realize, seeing things in a different light than I saw them before was the most rewarding experience for me. My job is similar to being a kid in the candy store. That's what I love about what we do, right? You're never old when you're in this field. I am waking up with [the same] excitement today as I did 30, 40 years ago. The reason is it's such a wonderful experience to come in knowing certain things and ending the day knowing a lot more than you did.

Hadi Hariri: Yes, totally.

Venkat Subramaniam: This book was definitely that for me. I came in knowing certain things, but thanks to the reviewers of the book, thanks to experimenting deeper with some of the ideas, I came up with a much better learning of Kotlin than I started with. And to me, there are two reasons I want to write a book. You know, I said I want to write a book for telling a story, but the two real important reasons we want to write a book is you want to learn from that experience. The most rewarding aspect of writing a book is you come back saying, "Wow, I really understand this a lot better than I thought I did." And the second is to help somebody else go through that journey. Somebody reading the book looks back and says, "Whoa, that gave me a different perspective than I started with."