The Changelog: Software Development, Open Source - The Kotlin Programming Language (Interview)

Episode Date: October 13, 2017

Dmitry Jemerov joined the show to talk about Kotlin - a language created by JetBrains that's designed to be an industrial-strength object-oriented language, and a "better language" than Java. We asked Dmitry "Why invent a new language?", talked through Google announcing official Android support, covered some of Kotlin's characteristics, Kotlin vs Swift, and more.

Bandwidth for Changelog is provided by Fastly. Learn more at fastly.com. And we're hosted on Linode servers. Head to linode.com slash changelog. This episode is brought to you by Hired. Hired matches outstanding people with the world's most innovative tech companies out there. Hired uses an algorithmic job matching tool in combination with a talent advocate who will walk you through the entire process of finding a better job. You might be looking for a more flexible work schedule,

more money, or remote jobs so you can travel and see the world. You might be looking for opportunities at Facebook, Mixpanel, or Squarespace, or the many other top tech companies out there looking for engineers on Hired. You and your skills can be a valuable asset to any of these companies. You just have to take the first step. That first step is Hired.com slash changelog. Go there, learn more. Our listeners get a special $600 hiring bonus when you find your next opportunity on Hired.

Once again, Hired. to The Changelog, a podcast featuring hackers, leaders, and innovators of open source. I'm Adam Stachowiak, editor-in-chief of Changelog. On today's show, we're talking with Dmitry Demirov about Kotlin, a language created by JetBrains that's designed to be an industrial-strength, object-oriented language, and a better language than Java. We asked Dmitry why invent a new language, talked through Google's announcement of official Android support at the most recent Google I.O., and we also covered some of Kotlin's characteristics. Fast compile times, built on the performance and reliability of the JVM,

static typing but with type inference, null safety and more, and as a bonus, we talked through Kotlin versus Swift. So Dimitri, take us back to 2010 at JetBrains with the genesis story of Kotlin and why it even kicked off in the first place. Can you tell us that? Yeah, sure. So the original motivation behind starting to think in that direction was that up until that time, we have been a vendor of tools. And while people can be passionate about the tools they are using, tools are not that hard to replace, like development tools. So people can switch to a different editor, to a different IDE, a different, I don't know, continuous integration

server. And so we felt like our company had somewhat of like an auxiliary role in the marketplace. And we started thinking about ways how we can be more influential. And the way many other companies do that, for example, if you look at Twitter or LinkedIn, they are producing lots and lots of infrastructure software that they promote for other people to use. But for us, this was not really a good path because we were actually building desktop applications and we simply did not have the kind of infrastructural software that we could share with a significant number of other people. So we just thought about different approaches. And the idea of creating a language came to our minds because we felt like we had the expertise required for that because we were building tools for programming in many different other languages.

We had ideas for Java,.NET, Scala, Groovy, Python, PHP, Ruby, JavaScript at that point. And we still did not see any alternative to Java that would be enjoyable for us to use. So we thought that with that expertise, why couldn't we try and build our own language? And as it happens, we find that problems that we have are usually problems that other people in the industry have as well. So we decided that if we feel that unmet need, then there probably are other people

who are in the same situation. So there must be some interest in the language. So that's basically where it started from. So JetBrains makes its living by selling licenses to its many popular IDEs, IntelliJ probably being the most popular. There's also, as you said, WebStorm, RubyMind, PHPStorm, on and on and on.

But you decided that you wanted to be more memorable or more influential amongst the developer community. And so a beloved programming language is, of course, a great way to do that if you can pull it off. But Kotlin has been open source from very early on, all the way back then. And so where's the model there? Is it just for influence? Or is there some sort of like business model eventually around Kotlin? Well, so one thing is that it simply gets people more attached to our products. So even though we do provide plugins for Eclipse and NetBeans, and it's possible to build integrations with just plain text editors like Visual Studio Code.

Like at the core, we invest much more into tooling for Kotlin for IntelliJ. And so we expect that, so if Kotlin gets popular, then it drives the sales of IntelliJ because people want to have like the best idea for Kotlin and they can buy it from us. And of course,

so there's also IntelliJ Community Edition, which is free and open source, and it provides, you can get get constant support in that as well but it does not include the enterprise development tooling so it does not include support for like css javascript databases like web like enterprise development frameworks all the like this heavyweight stuff so if you want that then you need to buy IntelliJ Ultimate. So basically, from the business point, that was the main case. And also, now there is Kotlin Native, which is Kotlin targeting not the JVM, but the native code. And we plan to make tools for

Kotlin Native also commercial, or at least there's a strong possibility. With a whole new language, and there's a world of ecosystem of tooling around that language. And if you are the author of the language and you're a tooling company, you're probably pretty good at making tools for Kotlin. Makes a lot of sense. Yep. So give us a little bit of the history. So this conversation, at least for me, Adam, started with Heroku blog writing on the rise of Kotlin. Of course, we heard the announcement back in May from Google that Kotlin's a first class citizen on Android now.

We'll talk about that and what exactly that means. But it's like you hear whisperings and I'm not very much in the Java community. So I had never tried Kotlin or even researched it much. But you just hear whisperings over the years and then eventually you get louder and louder. And that, I think, who was the fellow who wrote that for Heroku? Joe Cutler. Yeah, Joe did a really good job of explaining

why it's gotten so popular, especially as of late. And I even think the title set it up like, you know, this has been kind of a quick rise. Now for many open source projects, seven years is not fast. But for programming languages, a seven-year-old language is very much, you know, still a baby. You guys hit 1.0 in 2016. So it really has been, it seems like at least from the outside, a meteoric rise from a brand new idea in 2010, six years of toiling to a 1.0 in 2016, to May of 2017, where it's announced as first-class citizen or official language supported on Android, which is the most popular mobile

platform on the world. Can you tell us if it's felt like that from your perspective? Well, it kind of was. So there were actually several community members who have been really influential in spreading the word about Kotlin. So of course, at JetBrains, we promote Kotlin ourselves internally, but there were certain people from the community whose articles had much more weight because they are uninvolved guys promoting the language. Somebody else, right? Yeah. And so probably the main guys responsible for promoting Kotlin were Jake Wharton from Square and Mike Hearn from the Bitcoin community.

So essentially he wrote an article motivating internally for Square why they should start using Kotlin. And then he published it externally and I think I still find people referring to it even today, even though it was published three years ago and it's not entirely up to date. And Mike Hearn also published an article like, Why Kotlin is my next language. And it also got quite lots and lots of quotes and reposts and so on. So I think that was very influential.

And of course, there are many other companies like, for example, Christina Li from Pinterest is like advocating Kotlin quite a lot. And the Gradle partnership is also playing a role. The Spring Framework guys are also now excited about Kotlin. So you see lots of interest all around the community. Let's go back to the beginning there where we started, which is when this idea came to be. And so let's make a programming language that developers will love.

Was that the core design principle or did you have any sort of formalized this is the way Kotlin is going to be? Tell us some of the initial thoughts on what this programming language is supposed to be about. So we obviously wanted to have a statically typed language because it's the only way that we know that we can have a large code base that can be maintained over many years. We also wanted to have great Java interoperability because we had an existing huge Java code base and we wanted to be able to gradually replace Java with Kotlin in that code base.

We could not just abandon it or rewrite it or do something crazy like that. And also we wanted to have a language that is simple and easy to build tools for. And of course, pleasure to develop is also like our key factor so this has been the motto of our company for many years develop with pleasure and this applied to content justice equally as all our other products it's a good motto develop a pleasure that's proven quite a good strategy absolutely we've heard good things about all their IDs. In the GoTime FM channel, we often hear about Gogland,

your other ID for Go language, and obviously you mentioned IntelliJ. And then RubyMine is your original place you started, WebStorm. It seems you're pretty good at this. So what comes out of that characteristically? So obviously you mentioned statically typed, so that's one aspect of it. Of course, if you want to have good tooling,

static typing is, like you said, at this point, a requirement. We haven't quite figured out how to get spectacular tooling around dynamically typed languages, because things swoop in and swoop out underneath it so often. But what else? And especially in light of Java. So as Kotlin began to catch on, it was like, what if Java was less verbose?

Was that an explicit goal right away? Like we could make this like Java, but just remove the verbosity, and that would be a pretty big win? We did not believe that removing verbosity would be enough by itself. So we actually wanted to have some interesting new semantics.

And for example, the idea of nullability, it was like being able to have a null safe language. It was not part of the design from the very beginning, but just when we were starting. So basically when we came up on the idea, so the lead designer of Kotlin is Andrei Breslov. And when we started just discussing these ideas, Andrei was not yet with the company. So we just discussed it between ourselves, like what the language might look like.

Would there be any sense in starting to work on it and so on? And then we just met with Andrei, just had some initial discussions with him, trying to get him interested in the idea of working on the language. And originally, he was unconvinced that it was like a worthwhile endeavor. But then just after like one evening of talking, we got him really interested. And so he came on board and started working on the actual design. And then there were other people who we were talking with in the very beginning, just to get some ideas and feedback for what would be cool to have in the language. And actually the idea of dealing with nullability

came from Roman Yelizarov, who at that time, he was not yet at JetBrains. He joined us like very recently, but at that time he was just a colleague that we knew and respected from another company. And so he came up with the idea of making nulls part of the language. So you mentioned it twice now, null safety and dealing with nullability.

And this is a huge feature inside Kotlin. Can you unpack that for us and talk about what that means and then what that implies for programmers out there? So essentially what that means is like for any variable in your program, Kotlin knows whether this variable can be null or not. And if this variable can be null, then Kotlin does not allow you to do things that can cause null pointer exceptions. So for example, if you have a reference to an object and this reference can be null, then you cannot simply call a method on it. Because if it's null, then you will get a null pointer exception at that time. So Kotlin forces you to check that. There are multiple ways to do that. It's not very difficult to do. So there are various shorthand syntaxes for it. And so the compiler guarantees

that if you are following certain conditions, then you will never get null pointer exceptions in your program. Now, of course, Kotlin interoperates with the Java ecosystem, and in the Java world, this information is not being tracked. So for example, when you take a value returned from a Java method, you do not know whether this can be null or not so kotlin allows you to do anything with it and trusts you to check if you need it and to not check if you don't need it but in this situation you do not get the guarantees that you get in pure constant code so you have to be explicit about a variable that can be nullable. And it's almost like training wheels, but you can pull them off if you need to.

If you know what you're doing, this variable makes sense to be nullable. I'm going to annotate it somehow. I think you guys use a question mark, perhaps, to annotate that a variable is nullable? Yes. I would not actually refer to it as training wheels. So it's just like, it's a core part of programming in Kotlin. So I think getting nullability right implies a much better understanding

of the possible states of your system. Because I see a lot of Java software that is just littered with null checks, like they check every single thing because they are so afraid that there might be an exception. And this shows that they do not really have an idea of what data can be in what state in their program.

And Kotlin essentially forces you to keep this straight. So this is null. If you put a question mark, you realize that you put it explicitly and you know why, and you know what this means and in what situations this can happen. And otherwise,

you want to avoid putting those question marks and this essentially guarantees that the data is there when you expect it to be this is something that also proliferates in ruby code in my experience so you know many languages have this problem of dealing with null or nil or the lack of something and in fact avdi grim a talk, which I believe he turned into a book called Confident Ruby, which talks about all these ways of basically squeezing out nils so that you're not always checking for them.

It's coding confidently because what happens is when something could always be null perhaps, like you said, you have all these checks everywhere, slittered throughout your code, trying to find out whether or not you're dealing with null.

And knowing whether or not that's the case, coming into a function or a block of code means that you don't have to write all those checks all the time. It just cleans everything up and eliminates a huge swath of runtime errors for sure. Yeah, sure. So we find this to be very important. It seemed like you were describing an anxious programmer. You know, as someone who kind of checks all their data like that, in that sense, seems like, you know, you're almost in an anxious state

rather than, as you'd mentioned, which is a good title for his book and talk, Confident Ruby. You know, you're dealing with confidence versus the opposite, which might be anxiousness or am I getting this right? Is this data trustworthy? Could I be confident in it? What you often find is those checks will proliferate over time as a code base is exposed

to the real world. So the developer will begin writing the code without all those checks in it and be kind of naively confident until their software hits a real-world use case at which point

users are doing things that you didn't expect and you end up having bugs here and there. And the fix for a lot of these bugs is, well, if this thing is null, do this, and if it's not null, do the thing that we were already doing otherwise. Over time, you just have more and more of those checks.

Anxious, I think, definitely is the person who's been battle-hardened and knows that this user is going to enter a thing that I don't expect here, so they'll preemptively put those checks in. But over time, you'll just see them in bug fixes. It's just checking for null and returning early or handling it differently. And it really makes for brittle, hard to maintain code over time. Yeah, I think the right way to deal with that is to have a boundary in your system. So there's this user input, which everything that the user can input can be all sorts of wrong.

And then you just have a boundary where you validate all the data and reject the data, which is not satisfactory, which does not meet the requirements that you need and after that like facade you can just deal with correct data in the rest of your system i think it makes everything much easier to reason about no i agree absolutely uh check for it up front have a guard clause or some sort of boundary like you said squeeze out those nils or nulls and then on the internals of your software, you can then code confidently and not have to be checking everywhere because you've already done that check at the perimeter.

Null safety, you mentioned static typing. It's a compiled language, but fast compilation is something that you're after, which is one of the things that people love about Go. So tell us about that, and then some of the other kind of characteristics of Kotlin in the language. Well, as for fast compilation, actually, we are nowhere near Go, unfortunately. So Go is a pretty simple language to compile, and you don't need a lot of sophisticated

logic to analyze a Go program. And Kotlin is quite a bit more involved than that, so compilation performance is still something that we are working on. And we have incremental compilation, which helps a lot, so you can recompile only those files which are affected by the latest bunch of changes that you made since you last compiled. But still, for clean compilation, there is still something to improve for us. What's an average difference in Go programming? Is it minutes? Hours? It's really hard.

So it's not hours, of course. So I don't know. Compiling the entire Kotlin code base takes six minutes, I think. Six, seven minutes on a modern computer. So long enough to get some coffee, basically. Yeah. That's probably hundreds of thousands lines. But this is a fairly

large project, so there's quite a lot of code in there. And if you just make a local change, you don't have to recompile the whole thing, then the incremental compilation kicks in, and you can test your change within a couple of seconds, five seconds, something like that. Perhaps one of the biggest features that you mentioned, a little bit

offhand, but we should highlight, is complete interop with everything in Java. Is it with anything that can run on the JVM or specifically Java? So it's Java and languages which are compiled in a similar way. For example, Groovy runs on the JVM, but it's dynamic. So it has its own infrastructure for handling method calls, dispatching method calls. And Kotlin does not really interoperate with that. But if you take normal static type languages like Ceylon or Scala, then Kotlin is able to interoperate with them normally. And people do use mixed Kotlin, Scala,

Java projects, even though it's not a very easy thing to do. I've heard about some projects who do that. So this is a general purpose programming language. It's running on servers. It's, like you said, you have desktop applications. Of course, we know that it's going mobile on Android for a while now. You got Kotlin native going on. What was the first target and maybe the first set of users that you guys got outside of JetBrains to buy in, give it a try? And why was it so attractive to them to hop into the waters? The really first ones I don't actually remember. So I think one of the earliest, like the well-known names, which were the earliest adopters was there's this company called Prezi.

They make like presentations on the the presentations of the web and they started using kotlin on the back and fairly early on so in 2014 or something like that and i don't actually know if they are still using it actively but at that time it was very nice to hear that they are using Kotlin. So is that a typical early-on user, like a web company, or was it people doing desktop stuff? Just trying to get a feel for... I think in the early days, it was like all sorts of stuff. Some JavaFX stuff, some desktop programming, some server-side programming, probably mobile as well.

I don't remember when people started trying to use Kotlin for mobile. Okay. Give us other highlights of the language then we have, I think coroutines is possibly worth talking about. We haven't talked about the syntax very much, but go ahead. Yeah. Yeah. So as for coroutines, this is probably, yeah, this is one of the most exciting things in

Kotlin 1.1 that we released in the beginning of this year. So essentially the idea is that we want to be able to let people write asynchronous software in a sane way without compromising performance. So normally, you can use threads for writing concurrent software. And the problem with that is that every thread is expensive, and you cannot really run a million threads because you just run out of system resources. Or you can do callback style programming like they do in Node.js or there are asynchronous frameworks for all languages that support that. So there's Vertex on the JVM. And the problem with the callback style is that it's very hard to, for example, it's very hard to write a test because everything is in the callback.

And if you like in a test, you want to do some kind of steps and then in the end assert that everything is done. And it's very hard to detect where this end is so that you can finally assert that everything is done. Things like that. And all in all, just it kind of wraps the kind of warps the control flow in such a way that it becomes difficult to understand and difficult to write. And coroutines give you the best of both worlds. So coroutines essentially let you dispatch calls in any way that you want. So they are not tied to any specific architecture. Like you can use a thread pool to execute them, or you can use a single threaded dispatcher,

or you can even run coroutines on other machines possibly. Do you have to specify or will it just use one strategy by default, I suppose? So for running on multiple machines is something that's possible, but not yet implemented. So the machine array allows you to do that. And there are some projects that wanted to explore this direction, but I don't know that anyone actually achieved that. But it's definitely not that hard to do. And essentially, you can just parallelize your software while maintaining a sane programming model, so writing code in a linear fashion.

And we didn't really invent any new concepts there, so the kind of asynchronous programming that we support is very similar to what Python has and what C Sharp has, and the recent versions of JavaScript have similar prep patterns as well. The difference is that we have put as much as possible into the library, so the actual semantics of executing a coroutine, they are not controlled by the language, so the language only gives you the infrastructure of turning a function into something that can be interrupted

and then resumed. And the actual execution logic is part of the library. Actually, we haven't even talked about object-oriented versus functional. Spoiler alert, it's both. You have object orientation, you have first-class functions, you have a lot of, you know, all the stuff you'd expect from a functional language,

like all the collection type of stuff built in. So just trying to think, like, if I was going to characterize Kotlin, you know, of course we had already said it's statically typed, compiled. It does have type inference, so while it's statically typed, it's keeping your syntax short because it's inferring things that it can. You guys have pulled in influence from Java, C Sharp, JavaScript, Scala, Groovy.

It sounds like you really looked around the programming language landscape and pulled in good ideas from everywhere. Was that the MO? When you go about designing a language, I try to think of how do you decide what you're going to do. In your guys' case, it sounds like, well, what do we love from all these different languages? And let's just do those. Yeah, it was a significant part of what we did. So we initially positioned our languages

as a very non-research language. So a lot of programming language design comes from the academia. So people want to write PhDs about how they design the language and essentially want to move the state of the art forward. And we were not particularly interested in moving the research forward. We wanted to build a tool that can be used by actual people who don't have a PhD in computer science, who just want to get things done. And because of that, yeah, we do not pride ourselves on being innovative in any specific area. So we did take a lot of good ideas from other languages. And we are also not being dogmatic. So we are both functional and object-oriented. And we are not hardcore functional. We do not force you to use immutable data for everything, for example. We don't force

you to write pure functions unless you make some special efforts to make them non-pure. So you can just write your code in any way you want, and we give you tools that allow you to do that. And there is not much imposition of paradigms from our side, so to say. Often whenever you have a programming language, and as you mentioned Dalmatic, you often feel like you have to choose that kind of path to sort of set the tone for what the language could be, or as you mentioned Go earlier, comparing the compile times, Go is very small, I guess, in a way where you can keep it mostly in your mind.

It's designed that way for a reason. Do you think that not choosing a path or not being dogmatic or not choosing one or the other as a way programmers should use Kotlin is a good thing or a bad thing? Obviously, you're on that side. It seems maybe it's a good thing. But can you share what the, I guess, potential downsides could be of not being dogmatic about that choice? Well, if you look at the feedback that people have been voicing out after the Google I.O. announcement, you hear a consistent theme.

Like, we do not yet know how to use the language in the right way so with java there is a lot of patterns there are books that tell you how to use java properly like effective java and those books started coming out when java was like many years old and by now there is like a body of experience how java should be used and how java should not be used and with koth and people are concerned like that this body of experience does not yet exist. So there are not that many style guides, not that much guidance in terms of what the right patterns are and what the wrong patterns are. And I'm actually myself trying to address this to a degree. So there is a conference on Kotlin in November in San Francisco, and I will be giving a talk on idiomatic Kotlin.

They are just explaining exactly this sort of stuff. And also, I'm working on a style guide that will also answer some of those questions that people have. So people do want guidance, and we are going to provide it. Does it impact the language, though? Does it, as you implement the language and as you design the language, how does that affect the language itself, choosing a path or not choosing a path? Does it make it more complex, as you mentioned, not needing a PhD in computer science to effectively code in Kotlin? I do not think it makes it more complex in this way.

So it is true that we are adding some features that might seem like hacks to some people that view computer languages as something pure and beautiful in the theoretical sense. And those kinds of hacks are not the kind of things that you need a PhD to understand. They are just there because they solve practical issues that people encounter in real life. But we try to be moderate. We try to add not too many of those and try to keep the language reasonably clean, but still usable for tasks that people are trying to apply it to. And also one other thing

where we can address this problem is through tooling. So even though the language can compile any kind of code, we can and we do build inspections that highlight certain patterns in your IDE and tell you that you should not be doing this, you should be doing something else. And in very many cases, we can automatically correct the code for you so that you just press a keyboard shortcut and it changes the code into something that we find to be the right way to do things. And we have over 100 of those inspections at this time, and we are going to build more and more of them because we get we have so many ideas about like things that we can do to improve our users code i've heard a few

people say that when it comes to tooling and programming languages that uh it's one of those things similar to security where you can't very well bolt on security after the fact, that with tooling, it's very difficult to have a mature, built-up language or ecosystem, and then you add tooling later, but they have to be kind of one and the same. The language and the tool growing up together and maybe even sharing code bases or something like that.

Is that something that Kotlin has benefited from? And is that something that resonates with you? Well, yes, to a degree. So with Kotlin, we were building the language and the tools, like, together from the very beginning. So they share the same logic for parsing code, resolving references, detecting errors. Like, all of this is shared between the compiler and the IDE plugin. But in many cases, you can build tools after the fact. And actually, you mentioned Goglant, and Goglant was a very late entrant to the Go space.

And I think it is still pretty successful, and people seem to enjoy using it. And it was built entirely after the fact without using any of the stuff that the Go team has built before tools, as far as I know. Yeah. That could perhaps be a testament to the simplicity of Go as well. Maybe not necessarily because of it, but I probably helped you guys come in after the fact and build tooling around it. Absolutely true. Up next after the break, we talked with Dimitri about official Android support and what this means for Kotlin.

This was recently announced at Google IO and this is a big deal. If they're trying to be a better language than Java, to be an industrial strength, object oriented language that is a replacement for those Java developers out there. A new modern language. This is the holy grail. This is the blessing that they needed. We're talking about Kotlin versus Swift. And because we can't do a single show without talking about JavaScript,

we also talk through Kotlin.js. All this and more after the break. This episode is brought to you by Digital Ocean, who just launched Spaces, a beautifully simple object storage service that's designed for those who want a simple way to store and serve vast amount of data, such as hosting website assets, storing user-generated content like images and large media files, archiving backups in the cloud, and storing logs. Just like you're using S3, you can use DigitalOcean Spaces. And in fact, you can use S3 and DigitalOcean Spaces at the same time so you don't have a single point of failure. This is a standalone service, no droplet is needed, and pricing is extremely competitive. To make it easy to try for both new and existing DigitalOcean customers, you can get started today with a free 2-month trial of Spaces by going to do.co.changelog.

And by CircleCI. CircleCI is how leading engineering teams deliver value faster. By automating the software development process, using continuous integration and continuous delivery, you are free to focus on what matters most, which is building value for your customers. CircleCI is everything great teams need. Support for any language that builds on Linux, configurable resources, advanced caching options, custom environments, SSH access, security through full-level virtual machine isolation, interactive visual dashboard, first-class Docker support, and more.

Get started with their free plan, which gives you unlimited projects and 1,500 builds per month. Plenty to get started with head to circleci.com change law podcast So Dimitri, we mentioned the big announcement at Google I.O. of first-class Android support. That had to be huge for JetBrains, huge for the whole Kotlin community. Tell us about the Android support. Obviously, people were building Android stuff before this.

It's not like they added it and you couldn't do it before. But I took it as a blessing from Google. Give us the inside story on that and tell us what it meant for everybody. stuff before this it's not like they added it and you couldn't do it before but it's kind of i took it as like a blessing from google tell us about give us the inside story on that and tell us what it meant for everybody well we actually have been uh in contact with the android team for quite a while so obviously we work together on android studio which is based on the intelligent platform so we we have had contacts for for a long time and And we brought this topic every once in a while, like what would it take to get the Kotlin plugin bundled into Android Studio? And they basically answered like, no, not yet.

Let's talk about this later. And at some point they said that, okay, so we are ready to do it and we are going to do it in a month. And so essentially we had a very short time to set up all the like all the like legal stuff that we needed to take care of before this could happen all the technical stuff to get the plugin bundled and yeah so this was like very stressful right before the io yeah and and but it was like really inspiring for for all of us just to see the to see stephanie presented from the stage and how happy she was presenting it

and how happy all the community was to hear, like, yeah, this is something that we have been waiting for. And we did hear from a lot of people that they are not open to trying Kotlin because it's not blessed, because they were concerned that Google was going to do something that would break Kotlin. And so essentially they would end up with a broken app with no way to fix that.

Even though there was not actually much risk of this happening, because as long as Android was based on the JVM, which is not going to change anytime soon, we could adapt to whatever changes that Google had in mind. But still, people had their concerns, and now their concerns are alleviated. So now they have a guarantee that there is a partnership that is going to keep Kotlin up and running. So maybe that's why we're seeing

such a dramatic shift, Jared, in terms of more articles or talks or just adoption because of that change with Google I.O. And obviously Google blessing it, basically. Yes, and it's interesting that all the growth in adoption and interest, it's not restricted to Android. So the article from Heroku that you mentioned,

it also came out after the Google announcement. And the additional interest they got was also driven by this announcement too. So all sorts of people are starting to take us seriously, not only those who built Android apps. It was definitely a huge win for the whole Kotlin community. And I could definitely see where Android developers, even though they aren't happy with their current circumstance and tooling around building Android apps with Java. Kotlin was a risk for them. Like you said, it really wasn't because of JVM.

It was difficult for Google to somehow block it. But when you're building a business or perhaps you're building client apps or whatever your purpose is, building on unblessed type of things, especially on mobile, where things are a little bit more controlled compared to the web, even on the Google side. I can see where people were just waiting for

something a little more official. It seems like this was exactly what Kotlin needed to get the dramatic uptake that it's gotten since then. So technically, this does not mean all that much. So aside from the collaboration that has been now even more solidly established between us and the Android Studio team. So probably the key thing that changes is that Google is going to provide documentation and samples and templates right out of the box so that when you create a new project in Android Studio, you can choose to use Kotlin from the get-go

and it will just generate Kotlin code for all of the activities and all of the stuff that Studio generates for you by default. Well, that's exactly what I was going to ask, so good job. Yeah, yeah. Yeah, that's what everybody wants to know, like in a practical sense,

you know, what does this mean? I think that makes a lot of sense. So one thing I wanted to ask you about, just talking about Kotlin, people were thinking about Android, thinking about Java, thinking about Kotlin, and then on the iOS side of things, you've got Objective-C and Swift. And I've heard the comparison before. Kotlin is to Java as Swift is to Objective-C. And there's lines to draw there.

There's a lot that's not true about that. But one of the most interesting things for me is, whereas Swift was developed inside of Apple, and it's now going to be the long-term Objective-C replacement over time. Here we have Kotlin, perhaps over time, replacing Java on Android, but it's from a third party. It's open source. Well, Swift is open source, but it's all inside of Apple, whereas this didn't come from Google.

This came from a tooling company. So just curious your thoughts on that comparison and the fact that Kotlin is from an outsider, whereas Swift is from the inside. Yeah, well, one thing is that, like one thing I find very interesting about Kotlin and Swift is how close they are in terms of design. So even though we did not talk to each other at all

until very late. So I once gave a presentation about Kotlin and Apple where Chris Ladner was present, but we didn't really get it. That doesn't really count as joint development or anything like that. So when Swift was open sourced, we saw that we started almost exactly at the same time. So Swift was just 18 longer inside of Apple, and we opened up earlier about what we do, started telling about what we do. And the design is very similar.

And I think it's just more like convergent evolution than any kind of conscious boring from one language to another. And I guess both of the languages reflect the state of the art in language design, like the shared understanding of what it takes to build a modern language. And it kind of reaffirms our decisions to see that Swift does a lot of the things in a similar way. And in terms of outside versus inside, I don't know. So, well, Google has

certainly tried to build languages internally, and of them like one of them is very successful another is not so much successful and i guess that they yeah maybe they did not want to make a third try although i'm pretty sure that there's enough expertise inside of google that they could build a great language with like new things and worthwhile things but for them i think it's just it was like given that cotton already existed and already had Mindshare, and they could be pretty secure based on our partnership around Android Studio, that we are not going to screw them. I think this was a very logical step for them to adopt Kotlin. Yeah, absolutely. And it's definitely not about the Oracle lawsuit, as many people think. So Kotlin is not going to address any of the concerns that Oracle might have,

because it's still based on the same JVM and the same Java classes that all the fuss was about. They are still in there. And so it's just totally unrelated. Is that still up for grabs? I was tracking that for a while. Is there an appeal process happening? I don't know the state of the Oracle case.

I've lost track. I don't know what the latest state is. Adam, you tracked that at all? I didn't know the state of the Oracle case. I've lost track. I don't know what the state is. Adam, you track that at all? I didn't even track it at all. Oh, man. I was getting news right now. It's very interesting IP-related stuff with Oracle and Google duking it out in the courts. I think the point, though, with kotlin you know in you know google not doing that

it's it's surprising that given their the reliance on android the future of it as it is to a company as it is to them as a company i'm surprised that as you were jared that it was a third party to introduce change instead of them you know Even though they've had successful languages and successful things, I was surprised that too. The open source totally helps. Actually, when the first version of Android Studio came out,

up to the very point of the release, there was zero lines of contracts signed between us and Google concerning this. It was entirely based on the Apache 2 license that the Intel GJ community was based on. So with Kotlin, they wanted to have some more reassurances, and so there were some more formalities. But with Android Studio, it was just based on pure open source collaboration. And I think it's a great success story that even a company as protected, as defensive and as large as Google could go for something like that

without, just based on the Apache 2 license and without any extra reassurance. Wow. That does say quite a bit. To those out there that are Android developers and they're tired of Java or they have not

heard of Kotlin or they're just hearing about it and they're listening to this show and they're thinking, I've heard about this. Somebody said, listen to this show. Dimitri was on there kind of covering the basis of this language and all the ins and outs. Can you help share or shed some light

to those folks who are looking for a better solution that are developing for Android? Why Kotlin is a better solution for them or why Kotlin would be a great place for them to hang out at? Well, so one thing is just that you will get less runtime exceptions in your program. So it's very annoying when you run an application on Android

and it crashes and this application has been closed. I don't remember what the exact wording of the dialogue is. You will just get less of those. And another thing is that you will be in a much more pleasant, it will be much more pleasant to develop software. It will be less annoying, less fussy, less worrying about stuff that is just boilerplate. And you can just be more productive. And also you still have the same tools that you had access to with Java. So linters work and annotation processors work

and you can use any frameworks that Android developers use, like, I don't know, Dagger and data binding and all of this stuff is just there. And there's quite a lot of material now. So the Kotlin tag on Stack Overflow is very active and there are two books covering Kotlin for android and there are several more being

written and so there is a lot of material that you can use to learn kotlin and the learning curve is not actually that high so you can get productive like you can learn to read kotlin code in a few hours and write it in a few days and then of course it takes a while to become really fluent and proficient but it's that with every language. Well, I was at a recent event, the Sustain Conference. I was talking with a listener and he said, Jared, almost every one of your shows has something to do with JavaScript. And I said, well, that's just kind of the state of the industry right now. So we couldn't get out of here without asking about JavaScript. And there's a thing

called Kotlin.js. It looks like, from my reading, that perhaps JavaScript is just like a second compile target, like you can do the JVM or JavaScript. Do I have that right, or does it work somehow differently? Yes, that's basically exactly the case. So you can compile Kotlin to the Java bytecode and run it on JVM on Android. You can compile it to JavaScript and run it in your browser, or you compile it to native code and run it on, I don't know, Raspberry Pi or iOS. And our key goal actually is to support code reuse between the back end and the front end so that you will be able to implement your business logic just once and use the same classes on your back-end and on your front-end. And Kotlin will take care of

serialization of transporting the data between the server and the client. So it's like this part of the story is something that we're still working on. It's not fully public yet, but it's definitely something that we want to cover. And so you can very easily share just the same business logic between all the tiers of your application. Backend with the JVM, web frontend with the JS, Android with Kotlin for Android, and iOS with Kotlin native. So that's kind of the play that we are aiming for. So that it's just a single image for all tiers of your application.

And the same idea for all. Now there was a day in the past where you used to have to convince people that it was worth a build step. It was worth a compilation step in their front-end development workflow to use a different language. Nowadays, even people who are writing plain old JavaScript,

maybe they're writing ES6 or ES7, and we still have build steps, even for JavaScript to JavaScript. So that's probably not something that you necessarily are going to have too much of a battle with people winning them over, is, hey, you've got to compile your Kotlin to your JavaScript.

But perhaps they might be concerned about debugging and performance and kind of the overall quality of the compiled JavaScript. Is that something you guys are addressing as well? Yes. So for debugging, you basically get source maps. So you can use like the Chrome debugger, like debugging tools in Chrome or Firefox,

or you can use WebStorm, which also has an integrated debugger, or rather not WebStorm, but IntelliJ Ultimate, that has an integrated debugger that can attach to your browser and you can step through the code inside your IDE, even though the code is running in the browser. For code size,

this is something that we are actively working on. So we have essentially built our own minifier that understands the logic of the Kotlin code. And so you can intelligently dream the size of your code so that there's just nothing extra there. And in terms of performance, it's pretty straightforward. So we don't do anything fancy. And there is no extra overhead for dispatching calls

or something like that. So the performance should be very similar to what regular JavaScript gives you. Very cool. Well, for those people out there hoping for that, what is it? Isomorphic is the term application where just one language on the front and the back. If you love Kotlin and you got to write a JavaScript frontend, you can just keep on Kotlin the whole time. It's pretty cool. Yes, and we also integrate with the native frontend tooling.

So we have a webpack loader for Kotlin. So if you are using webpack, you can just integrate Kotlin directly into your build process. You can install NPM modules and use them together with Kotlin code. So you can also use type definitions from definitely typed. You can convert those TypeScript files into Kotlin and use them to get static types for your, for like for JavaScript frameworks that you want to use from your Kotlin code. So we have put and still putting a lot of effort into the integration with the JavaScript ecosystem, even though it's evolving very quickly

and it's hard to keep up with, but we are trying. Let's talk about what's coming up here, I guess. You've got KotlinConf coming up later this year. You mentioned, I believe it's Andre, is that how you pronounce it, or is it Andre? Andre. Andre?

Brezlav, he's the creator of this language, I guess, right? Is he one of or many of creators of this? Was it his idea, I guess, or not? Just set that case. Like he came, as I said, he came on board when we already had the idea that we are going to build

a language. But the actual design of the language, like the features and the specific details, it's basically all his work. And he's still doing the majority of the design work on Kotlin, or almost all of it. Okay, so just to give some context, I wanted to kind of share who that person was

and what his involvement was. So he's giving a keynote along with Eric and others. You've got this conference coming up. You've got, as you mentioned with Google I.O., that happening, a lot of new attention is being put on Kotlin and the community is growing. So help us kind of understand not only this conference coming up, but other things happening out there. Where's community taking place at for Kotlin? Where is it taking place?

Yeah, like is it at conferences? Is it meetups? Where are things generally happening at? Where can people hang out at to kind of catch up or get involved? So we have a public Slack, which is probably one of the biggest focuses of the community. I think we crossed 10,000 people. Let me check. Yeah, 10,000 plus is still a lot. And there's plenty, lots and lots of user groups and meetups.

And there are plenty, lots and lots of user groups and meetups, and there are also local events. So there is something called Kotlin Night, which is essentially an event that the community can hold in their own city. And we will support it, and we will send swag, and maybe help them monetarily if it's needed. And so there are lots of these events all over the world. And there is a surprisingly large community in Japan, for example.

And there are communities in the US, all over the place, in the UK, and in Europe, and Brazil. On your talks page, is that map on your talks page, is that representative pretty well of where Kotlin is being adopted? I mean, obviously, that would make sense if they're giving talks there. It would seem like there's some sort of adoption taking place.

I think so, yes. So we are actually putting a lot of effort into gathering all the talks that we can find about Kotlin and there are so many of them. Gotcha. So kotlinlang.org slash community is a good place to start. There's four different tabs. Community overview, user groups, Kotlin Nights, as you just mentioned, and the various talks you're gathering is a great place to sort of step in. Obviously, this podcast, too, but you're already listening to it to hear what I'm saying. So check on that box. So if you're someone local and you're trying to form a group,

you can form one, Kotlin Knights, and you all will support that. Yes, yes, definitely. Awesome. Well, Dimitri, it's been a blast. Thanks so much for joining us. Thank you. I really enjoyed being on the podcast as well, and thanks for inviting me. Alright, thank you for tuning in to the show this week. If you enjoyed the show, share it with a friend, rate us on Apple Podcasts, and thank you to our sponsors, Hired, DigitalOcean, and CircleCI. Also, thanks to Fastly, our bandwidth partner.

Head to Fastly.com to learn more. And we host everything we do on Linode cloud servers. Head to Linode.com slash changelog. Check them out. Support this show. The changelog is hosted by myself, Adam Stachowiak, and Jared Santo. It's edited by Jonathan Youngblood. And the awesome music you're listening to right now is produced by the Mysterious Brickmaster Cylinder.

You can find more shows just like this at changelog.com or wherever you get your podcasts. Thanks for tuning in, and we'll see you next week. Thank you.