Effective Kotlin

Unpacking 'Effective Kotlin'

Nicola Corti: Hi, everyone. Welcome to another episode of the "GOTO Book Club." Today, I have the honor to be here on stage. My name is Nicola Corti. I'm a software engineer, open source lover. I do all sorts of things on GitHub. You can find me all over the place as Cortinico. But the spotlight of this episode today is Marcin Moskala, author of "Effective Kotlin." Marcin to you.

Marcin Moskala: Thank you. Good. Great to be here.

Nicola Corti: It's awesome because we already know each other. We've been collaborating on all sorts of things, Marcin. It's amazing. Speaking with you is always a pleasure. Yeah, let's start by giving the audience a little bit of introduction to what you do. What do you do in life? Tell us a little bit about your background and your relationship with Kotlin.

Marcin Moskala: My relationship with Kotlin started a long time ago. I counted recently that it was around 11 years ago. Most people do not know Kotlin exists for so long, as most people learned about it, like, two or three years ago. But yeah, Kotlin is actually a pretty old language. It has been developed since 2010 and open source, like, released in 2011. I have used it professionally since 2015. I used it in private projects a little bit earlier. When I was a Kotlin developer, I lacked some resources about Kotlin and I started teaching it, first writing about it, writing blogs, and making some presentations. This is where I got my idea to write my first book. By the way, when I started writing it with Igor, there were practically no books published about Kotlin. There was this Antonio Leiva book that was, I believe, in early access, something like that. When we were writing the book, he published it. I also, if I remember right, the first edition of "Kotlin in Action" was also, not sure if published or just disclosure, announced when we were writing the book. But they were published more or less at the same time. So I guess our book was, like, fared on...

Nicola Corti: One marketer.

Marcin Moskala: ...the market or something like that. But this was a different book. This was "Android Development with Kotlin," which is a little bit misleading title because we wanted it to be called Kotlin for Android Developers because this is what it was. It was about Kotlin and with...

Nicola Corti: Focus..

Marcin Moskala: ...particular spotlight on Android developers. But this title was already taken. So our publisher told us to change the name and suggested this one instead.

Nicola Corti: Got it. From the early days of Kotlin, today you're here with us to spotlight your book, which is "Effective Kotlin." So people in the audience may actually know similar books like "Effective Java." I know that is one of the really popular ones. I'm sure there are other effective star where star is the name of a programming language out there. But yeah, I want to give you the opportunity to introduce this book. So what is it all about? How did you come up with the idea? Give us an elevator pitch of this book.

Marcin Moskala: You are perfectly right. This is a long tradition of books that actually has started with "Effective C++" by Scott Meyers, an amazing book by an amazing developer. I believe this was, like, 42. That's a nice number of specific items on how to improve your C++ programming. And after that, other books followed. And yes, the most popular one in our infosphere is "Effective Java" by Joshua Bloch. But there are others and I read them. Not all of them, but the majority of them. I definitely read "Effective Java" a couple of times. "Effective C++," "Effective Python," "Effective JavaScript," "Effective Python" was fun. And those are not very popular ones. I think one of them was surely self-published. They had some strange parts. I would say controversial parts. I remember, for instance, "Effective Python." I don't know if this is still there, but there was this item that you might use a useless, various argument to enforce everything after that to be called by name, named arguments. And so I was reading them, preparing to write this book.

Why did I decide to write it? I was actually pretty annoyed by what I could see in the Kotlin community, especially once it became an official language of Android and it started popularizing very quickly. We had huge waves of developers from Java that were not enthusiasts, passionate about Kotlin, but rather developers who are just using it as another language. And they were just writing Java in Kotlin, which was quite annoying, not utilizing Kotlin possibilities, capabilities. But what was even more annoying to me, it was that they were naively porting Java practices into Kotlin. You see, most of those guys read "Effective Java." And "Effective Java" is an amazing book. It's great. But many of its items do not apply to Kotlin. Just the opposite. They shouldn't be applied to Kotlin. One simple example is the builder pattern. "Effective Java" suggests you use a builder pattern, which is very useful in Java, because Java does not have named optional arguments. And "Effective Java," Joshua Bloch explicitly wrote in the book, I remember the fragment, I even quoted it in some post, that the reason why we use this pattern in Java is because Java doesn't have named optional arguments, which by the way, I have no idea why. It should have them. It's like one of the most basic features that modern languages have. And that's the only reason to use this pattern. In Kotlin, this pattern practically makes no sense. In simple cases, named optional arguments are enough. In more complex cases, we have better tools like DSLs, which are also builders, but different Kotlin-specific builders. You can consider builder pattern practically excluded, useless in Kotlin, unless you want to design a code that is interoperable with Java. Of course, there are some things that look like builder patterns. If you now think about it, I know that you are also using Compose, and in Compose, we have the modifier, which looks like a builder, but that's not a builder. Those are the decorators that are just implemented in a builder-like style. The classic builder pattern practically has no use in modern Kotlin programming, unless you are doing...

There were many such things, many, many things. People were trying to use static factory functions in Kotlin, which, first of all, is impossible. You need to use a Compound object factory function, which looks similar. But it's a little bit of nonsense because in most cases in Kotlin, it is more appropriate to use other techniques like top-level function, like extension functions, or other patterns. Or for instance, copying constructors. We practically don't do that in Kotlin. We have different practices in Kotlin. There were many, many things that have changed with Kotlin and that made suggestions in "Effective Java" outdated for Kotlin. There were also many practices that just... Kotlin style changed. Maybe they could be applied in a similar way as in Java or as "Effective Java" suggested, but it just wasn't the Kotlin style. It just wasn't what the creators of Kotlin were doing, what was the, let's say, the dominantly assumed good style. And this motivated me to write this book. But that's... Okay, go ahead.

Nicola Corti: It's a really inspiring story. I have to share that I obviously had the pleasure to read your book. I remember I was on vacation.

Marcin Moskala: Review even.

Nicola Corti: Yes, even review some of it. I remember I was on vacation in Sweden and I took my Kindle with me and I was looking through all the various items. Some of them are really inspiring. 

Recommended talk: Should Kotlin Be Your Go-To Language? • Garth Gilmour & Eamonn Boyle • GOTO 2019

Crafting Guidelines for Idiomatic Kotlin

Nicola Corti: I maintain a static analyzer for Kotlin called detekt. I remember we get back to items in your book multiple times as inspiration for rules. So it really helped the Kotlin community to form a consensus on what it means to write idiomatic Kotlin, which is really inspiring for a book. The question that I have for you is more, like, how do you decide if an item makes it inside the book or not? Because at the end of the day, you have this list of items with a number, so it's even easy to get back to them. But how do you decide if a rule or a pattern that you saw in the community actually becomes an item for "Effective Kotlin" or is just like, I don't know, like a rule that someone is following, but it's not worth a top-level item in your book?

Marcin Moskala: That was actually a tough decision because I always wanted to be a voice of community, not a voice of my own. That's why I consulted it quite massively. Thankfully, I had a really nice contact with creators. The Kotlin community when I started was very, very small. And so everyone nearly knew each other. If you go to a conference and there are two presentations about Kotlin, then you immediately go to the other speaker and you get to know each other. And this is how it looked in 2015 and even 2016. And so I had some contact with creators, with Andrey, because Andrey Breslav was there, in charge then. He actually created Kotlin until its stable levels and beyond. But I received even more help from other team members. For instance, there is ." Not sure if I'm pronouncing his nickname right, but he's an amazing developer with a very deep insight. He created Ktor and many, many libraries. And he was very, very helpful on the way. We had quite a few discussions about different suggestions, which was very, very helpful.

Outside of that, I did a massive amount of research. I might say I was writing this book, rewriting, rewriting, rewriting. If you collect all the pages that I wrote for this book, I think it would be three times as big and it is already a massive book. I read, as I said, pretty much everything I could find in this topic. I knew that looking only around Java suggestions would be a very... It wouldn't be a good approach. Kotlin was striving or maybe in many ways more similar to more modern languages. That's why I was checking what they write about the best practices for JavaScript, which in many ways is more modern than Java, Python, Scala, Groovy, and other languages. I even found some really, really useful things in C# because C# also had some features that are in Kotlin that are not in JavaScript, like extension functions or named arguments. I think, for instance, that the general rules for when extension function should be defined instead of a member was taken...I mean, I took it from the documentation of Kotlin, but Kotlin nearly literally copy-pasted. It was there in documentation for a very short time and it was quite literally copy-pasted from a documentation of C#. Later, they removed it, but that was my key inspiration for the item. There were also some presentations that Kotlin creators made. There was a presentation, Idiomatic Kotlin by Dmitry Jemerov, that was never really well-recorded. I'm not sure if you can find it right now on YouTube, but back in the days, this presentation had only one recording, which was extremely poor quality and not a very popular one. Dmitry was one of the key creators, one of the first people who joined the Kotlin team. He had a very, very deep insight and he also co-authored with Svetlana, co-authored "Kotlin in Action." His insights were very useful and I included nearly all of them in different items of "Effective Kotlin."

Recommended talk: Facts You May Not Know About Kotlin • Eugene Petrenko • GOTO 2020

Favorite Items: Factory Functions & Composition

Nicola Corti: Awesome. Talking about different items, because now we presented the book, but let's try to make it a little bit more practical for the users. I want to ask you, what is your favorite "Effective Kotlin" item? The one that you always remember or the one that you always quote?

Marcin Moskala: I think to use factory functions would probably be the one, or to avoid or to prefer composition over inheritance. But those are, of course, not originally my items. They are actually present in nearly all effective X formats as they are quite well-established items. However, I must say I'm pretty proud of those two because I think I made those items very Kotlin-ish. In the item to use factory functions, to prefer factory functions instead of secondary constructors. Because, okay, you're stealing the constructor to create an object, you cannot live without a constructor. But the thing is that for creating something outside of a basic way of creating an object, basic in the way that the one that relates, corresponds directly to the shape of this object, instead of making other constructors, it's better to use a factory function. I'm very proud of this item because back then and still on many blog posts, people are just quoting effective Java, which is suggesting to use factory functions, which as I said, sorry, compile an object, factory functions, which are not very Kotlin-ish, which are very strange thing in Kotlin. Whereas I, here, extracted all the basic ways of creating objects, creating different kinds of objects that are used in Kotlin. I think it is a very nice summary that for universal factories of some kind, you are using top-level functions. But if you want to create a copy of an object, or transform, or convert from one type to another, you are using conversion functions or an extension function with these two graphics, two and the other type. And you can use a factory object for a complex object that requires dependency, etc, etc. So I think I made a nice repository of all the different ways we create objects and in what situations we generally use them.

And about using composition over inheritance, I also am very proud of that because Joshua made a very good argument about the problems with inheritance. He directly pointed out what was very shocking and revealing for the community that inheritance breaks encapsulation and can lead to some serious problems in the long run. And that was very insightful, very useful. I think it's amazing. I also included that. But I think he still missed something that is much bigger. He missed something that is much bigger, which is that extracting behavior by inheritance typically complicates our code quite massively. In big part because we can only inherit from one class, but if we could inherit from many classes, it wouldn't help. It would just hurt us in different ways. The point is that if you want to extract some functionality, if you use inheritance, it's first of all implicit, it's hard to find it. So it's hard to navigate our code and understand what's going on. Second of all, it is hard to organize it because then you must put it in the upper class, but you can only inherit from one class. So in the result, we have these massive classes like base activity, or base controller, or base whatever, which has a massive amount of classes. And all these kinds of problems that I could observe over the years that are the result of overusing inheritance for extracting common behavior, I think that's the strongest argument against inheritance. I am very proud to myself that I defined it and I described it there.

Adapting to an Evolving Language

Nicola Corti: Awesome. It's an amazing tool to give you, like, to hear again about those items. Now you make me want to get back to the book and give it another read. And talking about these actually, I'm curious because Kotlin, the language itself is evolving. For folks that are not into it that much, Version 2.1 got released some months ago, weeks ago, and it's containing new language features like guarded one and so on. So I'm wondering, how does "Effective Kotlin" keep up to date with an evolving language? And it's not just a new language feature now. We saw Kotlin getting more and more multi-platform. So I assume there will be items that are more specific to, I don't know, using Kotlin in a multi-platform manner. So in general, how do you keep your book up to date? Are you planning a second edition? How do you evolve it?

Marcin Moskala: Kotlin in its core hasn't really changed much since I published this book. You're right that Kotlin introduced some other capabilities. Throughout this time, coroutines were released, which was a huge thing. I haven't updated "Effective Kotlin" with coroutines because I published a separate book about coroutines “Effective Coroutines”, which is explaining coroutines but also describing best practices for using them. So that's why I feel perfectly fine with not describing coroutines there. If you want to learn about coroutines, if you want to learn how to use coroutines, just check out my other book, which is also extremely popular, about multi-platform capabilities. I overviewed them in the first edition, but back then they were not used too widely. I might open myself for observing if those multi-platform capabilities are changing some aspects of style. Maybe I should consider that. But these capabilities in the... This is still a wild west, so we still need to wait some time to see how this actually influences the result style. We still don't really know how people will be using that. For instance, right now there are already many companies that are extracting some parts into logic and clients into common modules to reuse them between Android, iOS, web. But there is already another approach, which is Compose Multiplatform, which is quite young at the moment, but evolving very quickly, that would completely change this picture. It's very different if you need to design your code for being used in different languages versus if you just write this code in Kotlin and it is just compiled for different platforms. I haven't yet included that too much in the book. I described in detail the Kotlin multi-platform capabilities and the problems or the specificities of different platforms like JVM or JS platform in another book, in the "Advanced Kotlin" book. But yes, I'm not planning to update "Effective Kotlin" about it.

About other things, Kotlin hasn't really changed much. Kotlin 2.0 was just an internal cleanup. The K2 compiler introduced some small improvements and better build time, but essentially it hasn't changed the language. The guards that you mentioned are a very minor thing. Many other things that were introduced, I might consider adding some item related to one or two of them, but most of them are not changing anything. I'm rather updating my other books about Kotlin just to show that those capabilities are possible.

About updating the book, it's actually the third edition right now, I think. But I'm not updating this book because Kotlin is changing. I'm primarily updating this book because I am changing. One thing that has changed over time is that I got more mature in some aspects. I organized some of the rules better in my head. I, for instance, described something and I think it's a good description, but sometime later I figured out that maybe a better example can be used or something else can be described. That was a big source of changes in the book. The second big source of changes in the book is related to efficiency optimization. That was my, let's say, weakest point when I was writing this book. I read a lot about performance optimization, but I wasn't that much of a practitioner in this area when I was writing the initial version of this book. I don't know, it was 2017, something like that. Over the last couple of years, I've been specializing in efficiency optimization. I'm literally working as a consultant for companies and literally helping those companies either deal with some problems, like exceptions that they are dealing with and that are not easy to find or instabilities that they are not sure what is their origin.

I also help optimize services and applications. Over those years, I gained plenty of knowledge about efficiency. I was updating the book. But right now, I feel that this last part, because it is the sixth part, no, fourth or sixth part, one of the parts, is about efficiency. It includes a lot of information, like third part efficiency. It includes a lot of information, but I feel they are not well-organized. I organized them in the same way as "Effective Java" organized them. I started from how memory is allocated, from optimizing memory and stuff and stuff and stuff. But right now, I would organize it in a different way and I plan to organize it in a different way. I hope to make this update next year. I plan to start from measuring things because that's actually how we should start. Beyond all those rules for better memory management and stuff, there is that we should just set up tools to measure things, to see our response time, memory allocation, use, etc., etc. Measuring the bugging and then going down into practices that we use on different levels. Cache that is used on all the levels until the very, very low-level optimizations. Things like optimizing for primitives. It should be one of the last items because it's the last resource practice that we use only in the parts that need to be extremely, extremely efficient.

Recommended talk: 10 Reasons to Try Kotlin Multiplatform • Pamela Hill • GOTO 2023

Exploring the ‘Kotlin for Developers' Series

Nicola Corti: Awesome. We touched a lot on a number of different things. I hope we're going to see a revised version of "Effective Kotlin," this year or next year, that we can read through. But you also mentioned other books. You mentioned the "Advanced Kotlin" one, you mentioned the coroutines one. I want to give the audience a bigger picture because in reality, "Effective Kotlin" is part of a series of books. I think it's called “Kotlin for Developers”. Correct me if I'm wrong. I want to give you the opportunity to spotlight which other books you wrote in this series so that there might be people in the audience who are more interested in, as you said, more advanced Kotlin. There is a dedicated book for them. Tell us about this series, which books are inside, and who are they for?

Marcin Moskala: Originally, I published this book with Igor, "Android Development with Kotlin." Then I published "Effective Kotlin" and I felt quite satisfied with that. There was a book about Kotlin for beginners and how to use it well. I felt pretty well. Then coroutines came out. I published a book about coroutines, which is still, I believe, the most popular and well-established book about Kotlin coroutines, "Kotlin Coroutines: Deep Dive." Then I wanted to stop. But one thing was bugging me. I kind of had a feeling that I just haven't covered it all. I wasn't fully satisfied with the first book I published. Honestly, if I were writing my first book right now, I would make it completely different. I did the best work I could do back then. But throughout the years, I was teaching Kotlin. I'm a trainer. I'm conducting workshops. I'm teaching people. I'm also giving consultations. I've seen quite a lot and I've gained a lot of knowledge about how to explain different things. I wasn't happy with this initial book. That's why I decided to kind of rewrite it, but rewrite it in a complete form, like one good form that ends it all. I decided to turn it off into a series. That is a series of five books. That's a complete series right now. It starts from "Kotlin Essentials," which is about essentials of Kotlin.

Nicola Corti: The basics. 

Marcin Moskala: All the basic features. Then there is functional Kotlin, which covers more advanced features. Lambdas, function references, collection processing. I kind of have a feeling that those two books could be one book because they together cover the essentials, let's say. However, it would be a massive book. I just had a lot to say about both of those. So I wanted to cover things about all the different collection processing functions with real life examples and all the other features, like how to define your own DSL, how to use scope functions, yeah, let, with, apply. I had a lot to say. That's why there are two books instead of one, but I think they are divided pretty nicely. The "Kotlin Essentials" is kind of enough for a person who just wants to use something similar as in Java, but in Kotlin. Functional Kotlin is a very good lecture for those who are basic Kotlin users and want to improve their Kotlin skills.

Then in the series, there is coroutines, which is like the next level. Once you know all the basics, you should learn coroutines as they are extremely useful and important in Kotlin, both in Android and in the back-end world. Then there is a book, "Advanced Kotlin," which is actually one of my favorite books. It's a book I really, really wanted to write, even though there is not that much audience for this book because it's a book about, particularly about, advanced Kotlin features. It is describing KSP in nice detail, the compiler plugins. Here is your chapter.

Nicola Corti: About static analyzers. Go check "Advanced Kotlin" for sure.

Marcin Moskala: I actually love this book. I was extremely passionate about writing it. There is about multi-platform development, about the specificities of Kotlin/JS, about interoperability with Java, about generic variance modifiers, about delegation pattern. Only advanced Kotlin features. It's packing the whole book and I think it's amazing, annotation processing. So, a very fun book, but for a very particular audience, for a very small audience of people who are very good at Kotlin and are interested only in advanced things. Then it ends with "Effective Kotlin," which is about the best practices for using Kotlin.

Nicola Corti: Folks in the audience that have the desire to learn Kotlin have plenty of opportunity with your series. You can find it on Amazon, on Leanpub. Go check them out.

Give IT Forward Initiative

Nicola Corti:So as the episode is slowly getting to an end, I actually want to ask you one final question. It's about an initiative that I know you ran some years ago. I think it helps the audience get an understanding of you as a person and as a teacher, as someone that wants to give to the rest of the community. This initiative was called Give IT Forward. I want to leave you the stage to tell us what it was about and use this as a closing note for this episode.

Marcin Moskala: I would love to resume it again with other books, but I just wanted to spread some knowledge about programming in the wider community among non-developers. My reflection was that there are plenty of great materials for learning programming. You can use YouTube, you can use free courses. There are plenty of ways for learn that. The problem of people is that they do not know how to start. I decided to write a book about programming from scratch. I wanted it to present the basic concepts of a language and make it fun, interesting, entertaining so that someone can just read it, feel that programming is fun and learning about programming is fun. Then a very big part of this book, there is a part with practical application, I will explain it in a moment, and then a very big part of this book is what to do next. There is a chapter, hey, if you want to learn next, there are plenty of ways. There is a chapter, hey, this is what you can do, then there is a chapter on how you can learn. You can find YouTube courses and some examples of YouTube courses. You can use some free courses and some examples. You can even use games to learn programming. You can use applications for that, etc., etc., etc. That was the idea. I wanted to inspire as many people as possible.

I decided to not write about Kotlin because as much as Kotlin is an amazing language and it is extremely important in the Android community, it is still a little bit of a niche in the wider community. If someone asks me how to most easily find a job as a programmer, I'm not telling that person to learn Kotlin. I'm telling that person to learn JavaScript or Python. Those are much, much easier ways to start with programming, at least at the moment at the market. I published the first book about JavaScript. I was describing all the basics of JavaScript. There was a chapter when we were making a game. JavaScript, there was a ping game and there were all the things, how to learn JavaScript further. I paid for 1,500 books, I think, with the label, Give IT Forward. There was an instruction, do not keep it, read it or not and give it to another person who might benefit from that. You just gave it away. Some of them physically to a person, many of them were sent to some schools, to some foundations, to some hospitals, even to prisons, to different places. I know they are going around. I'm still sometimes receiving some information that someone sends, "Hey, I received this book and it's amazing that you did that." A year later, I made another book which was about Python, which was even bigger because Python has plenty of usages, so I added a part about different practical usages. There was a short chapter, how to write a backend application, how to analyze data in Python, how to make a script or something like that. That was, of course, a game. Can you guess what game was made in Python?

Nicola Corti: Snake?

Marcin Moskala: Snake, yes. That's exactly that. We were making Snake in the book about Python. I also paid for, I think, 1,000 books, but I believe 1,500 was sponsored by Allegro, by the company. We also gave them away. I'm not sure right now if they sponsored JavaScript or Python because it was before the pandemic, but one of them, I believe, they sponsored Python. I really want to resume that and publish other books in this formula and give them away. Of course, those books are also available in the market, but I intentionally made them really cheap. They are much, much cheaper than other books in the market about that. Also, I might add that I'm from Poland, so those books were published in Polish, but once the war started, we also made an edition in Ukrainian. We found people who wanted to translate this book into Ukrainian. They translated it and we also had correctors and we also bought some bundles and we gave it away. Many of them were actually sent to universities in Ukraine.

Nicola Corti: That's amazing. The whole idea of having those books that people can share around and keep on learning. It's an amazing initiative. I remember seeing a picture of you with the books in hand. Like, "Please take one." Okay, so we reached the end of the episode. Amazing wisdom, as always, Marcin.

Marcin Moskala: It's always nice to meet you.

Nicola Corti: It's always a pleasure, really. I want to give you one last opportunity to share with the audience where people can find you online if they want to connect with you or ask you question.

Marcin Moskala: Hey, asking questions is easiest on Twitter or X. I'm using it. You can also send me something on LinkedIn, but I'm checking it less often. You can also probably quite easily find my email in different places. If you are interested in workshops, then I'm making regular workshops, open workshops, teaching Kotlin. You can find them on kt.academy. It's from Kotlin Academy. I also organize company workshops. If you have a budget and you can organize a workshop in your company, then I'm sure we can set it up.

Nicola Corti: Amazing. With this, I want to thank you very much for being on stage with us today, Marcin Moskala.

Marcin Moskala: Thank you. My pleasure.

Nicola Corti: I also want to thank everyone for listening in the audience. Well, I hope you enjoyed the episode. Well, have a great day.